Kmario19

Gracias por compartir tu modificación, recomiendo remover los logs del .js para los entornos live. Y una idea para futuras versiones, crear un array con todas las settings de cada input y así hacer funciones generales para manejar las validaciones, errores y el dom, algo como esto: var inputs = [ nick: { el: '#nickname', validations: { required: { val: true, msg: 'El campo es requerido' }, regex: { val: /[^a-zA-Z0-9_]/, msg: 'Solo letras, numeros y guiones bajos.' }, length: { min: 4, max: 16, msg: 'Debe contener entre 4 y 16.' }, server: { route: 'registro-check-nick.php', msg: 'Ya existe un usuario registrado con este nickname' }, ... } }, ... ];

Hola a todos, soy Kmario19. Tal vez me recuerden de mods como la portada de los posts, o secciones como las de juegos y las comunidades. Esta vez vengo con un fix para aquellos sitios que tengan millones de visitas y la tabla w_visitas esté afectando la carga de un post ya que es la tabla que más registros genera. Junto a @Rengo estuvimos analizando por qué los posts cargaba tan lento, después de un rato noté que una consulta en particular era la culpable: db_exec(array(__FILE__, __LINE__), 'query', 'UPDATE `w_visitas` SET `date` = \''.time().'\', ip = \''.$tsCore->getIP().'\' WHERE `for` = \''.(int)$post_id.'\' && `type` = \'2\' && `user` = \''.$tsUser->uid.'\' LIMIT 1'); Esta línea está en c.posts.php en la función getPost. (esta consulta actualiza la fecha de visita del usuario logueado al post) El problema es que después de que el sitio tenga suficiente tiempo online o muchísimas visitas, esta tabla w_visitas llega a tener millones de registros y cuando una tabla así no está indexada tiende a hacer una consulta "FULL SCAN" por lo que básicamente tiene que recorrer todos los registros para poder finalizar su tarea, y en el caso del sitio de pruebas tiene más de 2 millones de registros. Entonces, para todos aquellos que quieran evitar este pequeño problema de rendimiento a futuro cuando tengan muchas visitas o si ya se les presenta el caso, la solución es ir a su base de datos y ejecutar la siguiente consulta: ALTER TABLE `w_visitas` ADD INDEX (`for`, `type`, `user`); Y listo, eso soluciona el problema. Para que se hagan una idea de los resultados, esta es una consulta antes de agregar el indice: Y esta es la misma consulta después de agregar el índice: Estamos hablando de una absurda reducción de 91150% de acuerdo al tiempo de ejecución de MySQL pero realmente pasamos a un tiempo de carga del sitio de unos 6 segundos aprox. a menos de 1 segundo. Bueno, es un índice que debería ir por defecto en el .sql con el que se instala el script para evitar ese inconveniente a futuro. Seguramente algunas otras secciones críticas del script con el pasar del tiempo y vayan creciendo necesitarán de estos índices para mejorar los tiempos de consulta de la base de datos. Bueno no siendo más, me despido. Hasta otra ocasión... espero no tan tardía xD

Se ve bien tu htaccess, puede ser que la extensión mod_rewrite esté deshabilitada. Tendrías que revisar esto en php.ini (si tienes acceso) o decirle a tu proveedor que te habilite el módulo para tu sitio. Saludos.

Hola, hace rato no pasaba por acá, solo me dio algo de nostalgia ver por dónde empecé y recordar viejos tiempos! Saludos

Muy bien! como en la documentación dice que la solicitud se hace vía post por eso usé curl, pero así va de lujo.

Debe ser por el https. En c.core.php busca: $current_url = "http://".$current_url_domain.$current_url_path; Reemplaza por: $current_url = "https://".$current_url_domain.$current_url_path; Prueba con eso.

Que no funciona exactamente?

Ve al archivo moderacion.php que está en inc/php y al lado de: $action == 'fotos' Agrega: || $action == 'temas' || $action == 'comunidades' Esto debe solucionar tu problema ya que este paso me hizo falta indicarlo en las instrucciones de la instalación.

Buen aporte. Eso "Live" si funciona? es decir, sin recargar la página? Es que no veo en el código qué parte hace eso ya que por lo general se hace por ajax. Ah otra cosita, en el paso dos está mal escrito exit (exti) xD

En la versión 2.3

Seguramente el theme no es compatible con la sección al 100%. No tengo cómo comprobar el diseño ya que no tengo ni el theme ni las secciones instaladas, si puedes subir alguna demo para verificar, sería genial. Por el momento puedes utilizar la función inspeccionar de tu navegador en los botones del editor al agregar posts para ver desde qué archivo se está cargando el diseño (estilos.css o agregar.css, etc.) y verificar que en las comunidades ese mismo archivo esté cargado.

Hola. Para los posts basta con ir al archivo c.posts.php y buscar la función getAutor, luego un par de líneas debajo, más o menos en la línea 412, puedes agregar u.user_vips al lado de cualquiera de los otros atributos separados por comas, por ejemplo u.user_rango. Para usarlo en la plantilla, ve al archivo templates/modules/m.posts_autor.tpl y aquí usarías la variable $tsAutor.user_vips para el condicional (nótese que en este caso no es $tsInfo). Para la hovercard, en el archivo c.users.php busca la funcion getVCard y un poco más abajo en la línea 352 aprox, podrás agregar u.user_vips al lado de u.user_name (o cualquier otro respetando la coma). Ahora irás al archivo templates/t.php_files/p.live_vcard.tpl y acá la variable a usar para el condicional sería $tsData.user_vips. Espero te sirva. Saludos.

El proceso de instalación esta detallado al inicio del hilo. Funciona en ambas plataformas, de cierta manera es responsive pero es el diseño exclusivo para dispositivos móviles, es decir, al entrar desde una pc se vera como lo tengas actualmente en tu sitio y no así como está en este post.