Solucion de problemas FAQ

El problema: necesitas el módulo, pero no sus recursos en todas las páginas

Hay muchas situaciones en las que quieres mantener un módulo de PrestaShop instalado y activo pero evitar que cargue sus archivos CSS o JavaScript en páginas específicas, o incluso en todas las páginas. Quizás tienes un módulo cuya funcionalidad necesitas pero cuyo estilo entra en conflicto con tu tema. Quizás un módulo carga una biblioteca JavaScript pesada que ya has incluido a través de tu tema. Quizás quieres reemplazar los estilos predeterminados de un módulo con tu propio CSS personalizado sin que los estilos originales interfieran. O quizás has identificado mediante una auditoría de rendimiento que un módulo carga recursos en páginas donde no tiene salida visible, y quieres eliminar ese desperdicio.

Desinstalar el módulo no es una opción porque necesitas su funcionalidad principal: sus hooks, sus tablas de base de datos, su configuración, sus funciones del back office. Solo necesitas eliminar quirúrgicamente archivos CSS o JavaScript específicos de la salida del front office. PrestaShop proporciona varios mecanismos para lograr esto, y este artículo cubre todos ellos en detalle, desde el más sencillo hasta el más potente.

Método 1: Usar Theme.yml para eliminar recursos de módulos

La forma más sencilla y mantenible de eliminar el CSS o JavaScript de un módulo en PrestaShop 1.7 y posteriores es a través del archivo de configuración del tema, theme.yml. Este archivo, ubicado en la raíz del directorio de tu tema, controla qué recursos carga el tema y qué recursos de módulos elimina.

Abre tu archivo theme.yml y busca la sección assets. Si no existe, puedes crearla. Dentro de la sección assets, puedes especificar archivos CSS y JavaScript a eliminar por su ID de recurso. Cada recurso registrado a través de registerStylesheet o registerJavascript tiene un ID, que típicamente es el nombre del módulo seguido de un sufijo descriptivo.

Para encontrar los IDs de recurso utilizados por un módulo, inspecciona el código fuente de tu página y busca las etiquetas link de hojas de estilo y los elementos de scripts. PrestaShop añade un atributo id a estos elementos en modo de depuración, o puedes encontrar los IDs en el código fuente del módulo donde llama a registerStylesheet o registerJavascript.

En tu archivo theme.yml, añade una sección bajo assets, luego css, luego all. Añade una entrada con el ID del recurso y establécelo en false. Por ejemplo, si un módulo registra una hoja de estilos con el ID modulename-style, añadirías modulename-style con un valor de false bajo la sección css all. Haz lo mismo para los archivos JavaScript bajo la sección js all.

Después de modificar theme.yml, necesitas limpiar la caché de PrestaShop desde Parámetros Avanzados, Rendimiento. Los cambios de theme.yml surten efecto después de que se reconstruya la caché. Este enfoque persiste a través de las actualizaciones del módulo porque la eliminación está definida en tu tema, no en el propio módulo. Sin embargo, elimina los recursos de todas las páginas. Si necesitas los recursos en algunas páginas pero no en otras, necesitarás un enfoque más selectivo.

Método 2: Media::unregisterStylesheet y Media::unregisterJavascript

PrestaShop 1.7 introdujo los métodos de la clase Media unregisterStylesheet y unregisterJavascript, que te permiten eliminar programáticamente recursos específicos que fueron registrados por otros módulos. Estos métodos son potentes porque puedes llamarlos condicionalmente, eliminando recursos solo en páginas específicas mientras los mantienes en otras.

Para usar este enfoque, necesitas un módulo personalizado o una modificación a un módulo existente. En el método hookActionFrontControllerSetMedia de tu módulo, llama a Media::unregisterStylesheet con el ID del recurso del archivo CSS que quieres eliminar. De la misma forma, llama a Media::unregisterJavascript con el ID del recurso del archivo JavaScript. Puedes envolver estas llamadas en lógica condicional para eliminar recursos solo en tipos de página específicos.

Por ejemplo, si quieres eliminar los recursos de un módulo de slider de todas las páginas excepto la de inicio, verificarías si el controlador actual es IndexController. Si no es la página de inicio, llamas a los métodos de eliminación del registro. Si es la página de inicio, no haces nada y dejas que los recursos se carguen normalmente.

La consideración clave con este enfoque es el orden de ejecución de los hooks. El hookActionFrontControllerSetMedia de tu módulo debe ejecutarse después del módulo cuyos recursos quieres eliminar. PrestaShop ejecuta las llamadas de hook en el orden en que los módulos están registrados en el hook, lo cual puedes controlar a través de la página Diseño, Posiciones en el back office. Mueve tu módulo personalizado debajo del módulo objetivo en el hook actionFrontControllerSetMedia para asegurar que tus llamadas de eliminación del registro ocurran después de que el módulo objetivo registre sus recursos.

Si el módulo infractor usa los métodos antiguos addCSS y addJS en lugar de registerStylesheet y registerJavascript, los métodos de eliminación del registro podrían no funcionar porque los métodos antiguos no usan el mismo sistema de gestión de recursos. En ese caso, necesitas un enfoque diferente.

Método 3: Módulo personalizado para bloquear recursos específicos

Cuando necesitas un control detallado sobre qué recursos se cargan en qué páginas, crear un módulo dedicado de gestión de recursos es la solución más flexible. Este módulo actúa como un lugar central donde defines reglas para bloquear o permitir recursos específicos de módulos.

Crea un nuevo módulo con un método hookActionFrontControllerSetMedia. Dentro de este método, define un array de reglas de recursos. Cada regla especifica un nombre de módulo, los IDs de recursos a bloquear y las condiciones bajo las cuales bloquearlos. Las condiciones pueden basarse en el nombre del controlador, el tipo de página o cualquier otro criterio disponible en el contexto de PrestaShop.

Tu módulo itera a través de las reglas en cada carga de página, verifica las condiciones y llama a Media::unregisterStylesheet o Media::unregisterJavascript para cada recurso que deba bloquearse en la página actual. Este enfoque centralizado es mucho más fácil de mantener que dispersar la lógica de eliminación de recursos en múltiples módulos o archivos de tema.

Puedes mejorar este módulo con una página de configuración en el back office que te permita gestionar las reglas a través de la interfaz de administración de PrestaShop en lugar de editar código. Un formulario simple con campos para el nombre del módulo, el ID del recurso y un multiselect para los tipos de página donde el recurso debería bloquearse te da una forma amigable de gestionar la carga de recursos sin tocar ningún código después de la configuración inicial.

Este enfoque funciona tanto con el nuevo sistema registerStylesheet como con el antiguo sistema addCSS, aunque podrías necesitar usar técnicas diferentes para cada uno. Para recursos registrados con el nuevo sistema, usa los métodos Media::unregister. Para recursos añadidos con el sistema antiguo, puedes manipular directamente los arrays css_files y js_files del controlador en el método hookActionFrontControllerSetMedia.

Método 4: El enfoque de desvincular hooks

Un enfoque más agresivo pero a veces necesario es desvincular completamente un módulo de los hooks donde registra sus recursos. Ve a Diseño y luego a Posiciones en tu back office. Encuentra el módulo en el hook displayHeader o actionFrontControllerSetMedia. Haz clic en el botón de eliminar o desvincular para quitar el módulo de ese hook por completo.

Esto evita que el módulo cargue cualquier recurso en cualquier página. Los otros hooks del módulo, como displayProductAdditionalInfo o displayFooter, continúan funcionando normalmente. Sin embargo, la salida del front office del módulo puede romperse si depende de su CSS para el estilo o de su JavaScript para el comportamiento interactivo.

Este enfoque es más útil cuando planeas reemplazar completamente el estilo del módulo con tu propio CSS personalizado. Desvinculas el módulo de displayHeader para evitar que se cargue su CSS, y luego escribes tus propios estilos en el archivo CSS personalizado de tu tema apuntando a los elementos HTML del módulo. Esto te da control total sobre la apariencia del módulo sin ningún conflicto entre los estilos originales y tus personalizaciones.

Para JavaScript, desvincular es más arriesgado. Si el módulo depende de su JavaScript para funcionalidades principales como llamadas AJAX, validación de formularios o carga dinámica de contenido, eliminar el JavaScript romperá esas funcionalidades. Solo desvincula el JavaScript si estás seguro de que la salida del front office del módulo no depende de él, o si estás proporcionando una implementación de reemplazo a través de tu tema.

Una advertencia importante: si actualizas el módulo, el proceso de actualización puede volver a registrar el módulo en los hooks de los que lo eliminaste. Después de cada actualización de módulo, comprueba Diseño, Posiciones para verificar que tu desvinculación sigue en efecto. Algunos módulos registran explícitamente sus hooks durante el proceso de actualización, lo cual anula tu desvinculación manual.

Método 5: Anular los recursos del módulo a través de tu tema

El sistema de temas de PrestaShop te permite anular los archivos de plantilla de un módulo colocándolos en el directorio modules de tu tema. Aunque esto se usa principalmente para anular plantillas, también puedes usarlo para controlar la carga de recursos indirectamente.

Si un módulo carga sus recursos a través de sus archivos de plantilla usando funciones Smarty como etiquetas de archivos directamente en los archivos TPL en lugar de mediante hooks PHP, puedes anular esas plantillas en tu tema y eliminar las referencias a los recursos. Copia el archivo de plantilla del módulo al directorio modules de tu tema, manteniendo la misma estructura de directorios, y edita la copia para eliminar las referencias a CSS o JavaScript no deseadas.

Este enfoque es específico del tema, lo que significa que solo afecta al tema actual. Si cambias de tema, las anulaciones no se transfieren. También requiere mantenimiento: cuando el módulo actualiza sus plantillas, necesitas actualizar tus anulaciones para reflejar cualquier cambio estructural mientras mantienes tus modificaciones de eliminación de recursos.

Para módulos que cargan recursos a través de hooks PHP en lugar de plantillas, las anulaciones de plantillas del tema no ayudan con el bloqueo de recursos. En ese caso, usa uno de los otros métodos descritos en este artículo.

PrestaShop 1.7 vs 8.x: diferencias en el enfoque

PrestaShop 8.x perfeccionó el sistema de gestión de recursos introducido en 1.7, pero los enfoques fundamentales siguen siendo los mismos. Las principales diferencias están en la implementación interna y algunas funcionalidades adicionales.

En PrestaShop 1.7, el sistema de gestión de recursos usa registerStylesheet y registerJavascript con un sistema de prioridad. Los métodos Media::unregisterStylesheet y Media::unregisterJavascript funcionan de forma fiable para recursos registrados a través de este sistema. Sin embargo, los módulos que aún usan los métodos heredados addCSS y addJS (que están obsoletos pero siguen siendo funcionales) no pasan por el nuevo sistema de gestión de recursos, lo que hace más difícil eliminarlos limpiamente.

PrestaShop 8.x mejoró la compatibilidad hacia atrás para que incluso los recursos añadidos a través de los métodos heredados se procesen a través del nuevo pipeline de recursos. Esto significa que los métodos Media::unregister funcionan de forma más consistente en todos los módulos, independientemente de qué método de registro utilicen. Si estás ejecutando PrestaShop 8.x, el enfoque de eliminación del registro es el método más fiable para todos los módulos.

PrestaShop 8.x también introdujo mejor invalidación de caché para los recursos, lo que significa que cuando eliminas o modificas recursos, los cambios surten efecto inmediatamente después de limpiar la caché, sin que los clientes vean versiones almacenadas en caché obsoletas. En PrestaShop 1.7, a veces necesitabas limpiar tanto la caché de PrestaShop como la caché del navegador, o esperar a que el sistema Combinar, Comprimir, Cachear (CCC) regenerara los archivos combinados.

Ambas versiones soportan el enfoque theme.yml para la eliminación de recursos, y la sintaxis es idéntica. Si estás escribiendo un módulo personalizado para la gestión de recursos, el mismo código funciona tanto en 1.7 como en 8.x con diferencias mínimas.

Midiendo las mejoras de rendimiento después de desactivar recursos

Después de desactivar los recursos de un módulo, deberías medir la mejora de rendimiento para confirmar que tus cambios tuvieron el efecto esperado. Usa una combinación de herramientas para una medición completa.

Comienza con la pestaña Red de Chrome DevTools. Compara el número total de peticiones y el tamaño total transferido antes y después de tus cambios. Filtra por CSS y JS para ver la reducción específica en el número y tamaño de archivos de hojas de estilo y JavaScript. Una optimización significativa debería mostrar una reducción clara tanto en el número de peticiones como en el tamaño total.

Ejecuta una auditoría de rendimiento de Lighthouse antes y después. Céntrate en las métricas más afectadas por la carga de CSS y JavaScript: First Contentful Paint se ve afectado por el CSS que bloquea el renderizado, Largest Contentful Paint se ve afectado por la carga general de recursos, y Total Blocking Time se ve afectado por el análisis y ejecución de JavaScript. Registra estas métricas de al menos tres ejecuciones y compara los promedios.

Usa la pestaña Coverage en Chrome DevTools para medir el uso de CSS y JavaScript. Abre la pestaña Coverage desde el menú de tres puntos en Más herramientas, luego recarga la página. La pestaña Coverage te muestra cuánto de cada archivo CSS y JavaScript se utiliza realmente en la página actual. Los archivos con alto porcentaje de código no utilizado (mostrados en rojo) son candidatos para eliminación o carga condicional. Después de desactivar los recursos del módulo, los archivos restantes deberían mostrar porcentajes de uso más altos, indicando que has eliminado el desperdicio con éxito.

También considera las métricas del mundo real de tu plataforma de analítica. Si usas Google Analytics o una herramienta similar, compara los tiempos de carga de página durante una semana antes y después de tu optimización. Los datos del mundo real de visitantes reales en diferentes dispositivos y condiciones de red te dan la imagen más precisa de la mejora de rendimiento.

Riesgos y consideraciones de compatibilidad

Desactivar los recursos de un módulo conlleva riesgos que necesitas entender y gestionar. El riesgo más común es la rotura visual. Cuando eliminas el CSS de un módulo, sus elementos HTML pierden su estilo y pueden mostrarse incorrectamente. Esto puede ir desde problemas cosméticos menores como colores o espaciados incorrectos hasta problemas de diseño graves como elementos superpuestos o contenido invisible.

La eliminación de JavaScript conlleva un riesgo mayor. Los módulos modernos a menudo dependen de su JavaScript para funcionalidades principales. Eliminar el JavaScript puede hacer que las funcionalidades dejen de funcionar por completo: botones que no responden a los clics, formularios que no se envían, popups que no se abren, contenido AJAX que no se carga. Siempre prueba cada funcionalidad de un módulo después de eliminar su JavaScript.

También existe un riesgo de compatibilidad con las actualizaciones de módulos. Cuando un módulo se actualiza, el desarrollador puede añadir nuevos archivos CSS o JavaScript con diferentes IDs de recurso. Tus reglas de eliminación, ya sea en theme.yml o en un módulo personalizado, podrían no capturar los nuevos recursos porque apuntan a los IDs antiguos. Después de cada actualización de módulo, verifica que tu bloqueo de recursos sigue funcionando correctamente y actualiza tus reglas si es necesario.

Algunos módulos realizan detección de funcionalidades en su JavaScript y se comportan de forma diferente cuando su CSS no está cargado. Un módulo podría verificar la existencia de clases CSS específicas o estilos computados antes de inicializar su funcionalidad JavaScript. Eliminar el CSS en este caso no solo cambia la apariencia sino que también rompe el comportamiento del JavaScript que depende de esos estados definidos por CSS.

Finalmente, ten en cuenta las dependencias entre módulos. El Módulo A podría cargar una biblioteca JavaScript como un plugin de lightbox que el Módulo B también usa pero no carga por sí mismo porque asume que el Módulo A lo proporciona. Eliminar los archivos JavaScript del Módulo A rompería ambos módulos en este escenario. Verifica las dependencias compartidas antes de eliminar cualquier recurso.

Un flujo de trabajo práctico para la eliminación segura de recursos

Sigue este flujo de trabajo para desactivar de forma segura los recursos de un módulo sin romper tu tienda. Primero, documenta tu estado actual. Toma capturas de pantalla de cada tipo de página donde el módulo muestra contenido. Registra las puntuaciones de Lighthouse y las estadísticas de la pestaña Red. Esto te da una referencia para comparar y una guía de cómo debería verse y funcionar el módulo.

Segundo, identifica los recursos específicos que quieres eliminar. Usa DevTools para encontrar los nombres exactos de archivos y los IDs de recursos. Determina qué páginas necesitan los recursos y cuáles no.

Tercero, implementa la eliminación usando el método más apropiado de este artículo. Para eliminación global simple, usa theme.yml. Para eliminación condicional basada en tipo de página, crea un módulo personalizado con llamadas a Media::unregister. Para reemplazo completo de recursos, desvincula el módulo y proporciona tus propios estilos.

Cuarto, prueba exhaustivamente. Comprueba cada tipo de página donde el módulo debería mostrar contenido. Verifica que la apariencia visual del módulo es correcta y que todas las funcionalidades interactivas funcionan. Comprueba las páginas donde eliminaste los recursos para confirmar que ya no se están cargando. Prueba en múltiples navegadores y dispositivos.

Quinto, mide la mejora de rendimiento. Ejecuta auditorías de Lighthouse y compara con tu referencia. Comprueba la pestaña Red para verificar la reducción en el número de peticiones y tamaños. Si la mejora es significativa, tu optimización fue exitosa. Si la mejora es mínima, los recursos que eliminaste podrían no haber sido el principal cuello de botella de rendimiento, y deberías investigar otras oportunidades de optimización.

Sexto, documenta tus cambios. Registra qué recursos eliminaste, qué método usaste y qué páginas están afectadas. Esta documentación es esencial para resolver problemas futuros, especialmente después de actualizaciones de módulos, y para la transferencia de conocimiento si otra persona mantiene la tienda.

Siguiendo este enfoque sistemático, puedes reducir de forma segura el peso de página de tu tienda y mejorar los tiempos de carga sin sacrificar la funcionalidad del módulo de la que depende tu tienda. La clave es siempre probar y medir: nunca asumas que eliminar un recurso es seguro, y siempre verifica los resultados con datos concretos.

Leer respuesta completa

Comprender memory_limit de PHP

La directiva memory_limit de PHP controla cuánta RAM puede consumir un único proceso PHP antes de que el motor lo termine con un error fatal. Cuando ves el mensaje "Allowed memory size of X bytes exhausted" en PrestaShop, significa que una solicitud PHP específica intentó usar más memoria de la que permite el límite configurado.

Cada carga de página en PrestaShop ejecuta código PHP que carga el framework, se conecta a la base de datos, procesa datos, renderiza plantillas y envía HTML al navegador. Cada uno de estos pasos consume memoria. El memory_limit actúa como una red de seguridad: impide que un proceso descontrolado consuma toda la RAM disponible del servidor, lo que causaría la caída de otros procesos y potencialmente la del servidor completo.

El memory_limit predeterminado en PHP es típicamente 128M (128 megabytes). PrestaShop recomienda oficialmente al menos 256M, y muchas tiendas requieren 512M o más dependiendo del tamaño del catálogo, los módulos instalados y el tráfico. Comprender qué impulsa el consumo de memoria te ayuda a determinar el valor correcto para tu tienda en lugar de aumentar el límite a ciegas.

Cómo Verificar Tu Límite de Memoria Actual

Hay varias formas de verificar qué límite de memoria está usando actualmente tu instalación de PrestaShop.

Desde el Back Office de PrestaShop

Navega a Parámetros Avanzados > Información. Esta página muestra la configuración PHP de tu servidor, incluido el valor actual de memory_limit. PrestaShop también mostrará advertencias si el valor está por debajo del mínimo recomendado.

Usando phpinfo()

Crea un archivo temporal llamado info.php en el directorio raíz de PrestaShop con este contenido:

<?php phpinfo(); ?>

Accede a él a través de tu navegador en tudominio.com/info.php. Busca en la página "memory_limit" para ver tanto el Valor Local (lo que está realmente activo) como el Valor Master (lo que está configurado en php.ini). El valor local puede diferir del valor master si un .htaccess, .user.ini o la aplicación misma lo sobreescribe.

Importante: Elimina este archivo inmediatamente después de verificar. Una página phpinfo() expone la configuración detallada del servidor que los atacantes pueden explotar.

Vía Línea de Comandos

Si tienes acceso SSH, ejecuta:

php -i | grep memory_limit

Ten en cuenta que la configuración PHP de CLI puede diferir de la configuración del servidor web. Para verificar el valor web-facing, usa el método phpinfo() o el back office de PrestaShop.

Causas Comunes de Errores de Límite de Memoria

Importaciones de Productos Masivas

La importación de productos mediante CSV es una de las operaciones más intensivas en memoria de PrestaShop. Cada fila del archivo de importación se carga en memoria, se procesa, se valida y se inserta en la base de datos. Un archivo CSV con 10.000 productos, cada uno con múltiples combinaciones, imágenes y descripciones, puede requerir fácilmente 512MB o más de memoria.

La herramienta de importación de PrestaShop procesa productos en lotes, pero el tamaño del lote y la cantidad de datos por producto determinan la huella de memoria total. Los campos de texto grandes (descripciones con HTML), muchas columnas y archivos codificados en UTF-8 con caracteres especiales aumentan el uso de memoria por fila.

Para reducir el consumo de memoria durante las importaciones:

Divide los archivos CSV grandes en porciones más pequeñas (1.000-2.000 filas cada una)
Importa primero los productos sin imágenes, luego importa las imágenes por separado
Desactiva los módulos no esenciales durante la importación (estadísticas, indexación de búsqueda)
Usa la importación por línea de comandos si está disponible, que evita los límites de tiempo del servidor web

Productos con Muchas Combinaciones

Los productos con muchos atributos (talla, color, material) generan combinaciones de forma exponencial. Un producto con 5 tallas, 10 colores y 3 materiales crea 150 combinaciones. Cada combinación es un registro separado en la base de datos con su propio precio, referencia, stock y asociaciones de imágenes. Cuando PrestaShop carga una página de producto para edición en el back office, carga todas las combinaciones en memoria simultáneamente.

Los productos con 500+ combinaciones son un punto problemático conocido. Con 1.000+ combinaciones, casi con seguridad alcanzarás los límites de memoria con la configuración predeterminada. Las soluciones incluyen:

Aumentar memory_limit a 512M o 1G para el back office
Reestructurar los productos para reducir el número de combinaciones (productos separados en lugar de mega-combinaciones)
Usar módulos que gestionen las combinaciones de forma más eficiente mediante paginación

Módulos Sobrecargados o Mal Codificados

Los módulos de terceros son una fuente frecuente de problemas de memoria. Los problemas comunes incluyen:

Cargar tablas enteras de la base de datos en arrays PHP: Un módulo que ejecuta SELECT * FROM ps_orders sin una cláusula LIMIT carga en memoria cada pedido jamás realizado. Para una tienda con 100.000 pedidos, esto puede consumir cientos de megabytes.
Fugas de memoria en bucles: Módulos que procesan elementos en un bucle pero acumulan objetos sin liberarlos. El recolector de basura de PHP maneja los casos simples, pero las referencias circulares y las referencias almacenadas pueden impedir la limpieza.
Registro excesivo: Registro de depuración que escribe arrays u objetos grandes en archivos de log, usando var_export() o print_r() en objetos complejos de PrestaShop, puede consumir cantidades enormes de memoria.
Procesamiento de imágenes no optimizado: Módulos que redimensionan o aplican marcas de agua a las imágenes usando GD o ImageMagick cargan la imagen completa sin comprimir en memoria. Una imagen de 5000x5000 píxeles con profundidad de color de 24 bits requiere aproximadamente 75MB de RAM solo para los datos de los píxeles.

Para identificar qué módulo está causando problemas de memoria, verifica cuidadosamente el mensaje de error. Generalmente incluye una ruta de archivo que apunta al módulo responsable. También puedes habilitar el modo de depuración de PrestaShop para obtener trazas de pila más detalladas.

Catálogos Grandes y Consultas Complejas

Las tiendas con decenas de miles de productos, muchas categorías y estructuras de atributos complejas ejercen más presión sobre la memoria durante la operación normal. Las páginas de categorías con navegación por capas (búsqueda facetada) son particularmente exigentes porque el motor de filtros debe calcular los valores de atributos disponibles a través de miles de productos.

El listado de productos del back office, el listado de pedidos y el listado de clientes cargan datos en memoria para su visualización. Con conjuntos de datos muy grandes, incluso la vista básica de lista puede alcanzar los límites de memoria, especialmente cuando los módulos añaden columnas o cálculos adicionales a estos listados.

Compilación de Plantillas Smarty

PrestaShop utiliza el motor de plantillas Smarty, que compila las plantillas en archivos PHP para un renderizado más rápido. El proceso de compilación en sí consume memoria, y las plantillas complejas con muchos includes, bucles y bloques condicionales requieren más memoria para compilarse. Después de la primera compilación se utilizan las versiones en caché, por lo que esto es principalmente un problema cuando se vacía la caché o durante el desarrollo.

Cómo Aumentar el Límite de Memoria

Método 1: php.ini

El método más fiable es editar directamente el archivo de configuración PHP. La ubicación depende de tu configuración:

Debian/Ubuntu: /etc/php/8.x/fpm/php.ini (PHP-FPM) o /etc/php/8.x/apache2/php.ini (mod_php)
CentOS/RHEL: /etc/php.ini o /etc/php.d/
cPanel: MultiPHP INI Editor en WHM o cPanel

Encuentra la línea memory_limit y cámbiala:

memory_limit = 512M

Después de guardar, reinicia PHP-FPM o Apache:

# PHP-FPM
sudo systemctl restart php8.2-fpm

# Apache con mod_php
sudo systemctl restart apache2

Método 2: .htaccess (Solo Apache con mod_php)

Añade esta línea al archivo .htaccess en el directorio raíz de PrestaShop:

php_value memory_limit 512M

Este método solo funciona con Apache ejecutando mod_php. Si usas PHP-FPM (que es más común en configuraciones modernas), esta directiva se ignora silenciosamente o puede causar un error 500. Para verificar qué handler PHP estás usando, mira la línea Server API en la salida de phpinfo().

Método 3: .user.ini (PHP-FPM)

Crea o edita un archivo llamado .user.ini en el directorio raíz de PrestaShop:

memory_limit = 512M

PHP-FPM lee archivos .user.ini desde la raíz del documento. Ten en cuenta que los cambios surten efecto después del período user_ini.cache_ttl (predeterminado 300 segundos / 5 minutos), por lo que es posible que necesites esperar o reiniciar PHP-FPM para que el cambio tenga efecto inmediatamente.

Método 4: Dentro del Código de PrestaShop

PrestaShop establece su propio límite de memoria en el archivo config/defines.inc.php. Busca una línea como:

@ini_set('memory_limit', '256M');

Puedes aumentar este valor directamente en el código. Sin embargo, este enfoque tiene una limitación: la función ini_set() solo puede aumentar el límite de memoria hasta el valor establecido en php.ini. Si php.ini establece memory_limit = 128M y tu código intenta establecerlo en 512M, el límite real permanecerá en 128M (a menos que el valor master permita sobreescrituras, lo que depende de la clasificación PHP_INI_ALL vs PHP_INI_SYSTEM).

Método 5: Configuración Por Pool (PHP-FPM)

Si gestionas tu propio servidor, puedes establecer límites de memoria por pool de PHP-FPM. Edita el archivo de configuración del pool (ej. /etc/php/8.2/fpm/pool.d/www.conf) y añade:

php_admin_value[memory_limit] = 512M

Usando php_admin_value esta configuración se vuelve inmutable — no puede ser sobreescrita por .user.ini o ini_set(). Esto es útil para aplicar límites en entornos multi-tenant.

Memoria Por Proceso vs Memoria Compartida

Es importante entender que memory_limit se aplica a cada proceso PHP individual, no a PHP en su conjunto. Si estableces memory_limit = 512M y tu servidor ejecuta 20 procesos PHP concurrentes, el consumo máximo teórico de memoria por parte de PHP es de 10GB (20 x 512MB).

Por esto, aumentar ciegamente el límite de memoria puede causar problemas. En un servidor con 4GB de RAM, establecer memory_limit = 1G con 10 workers PHP-FPM significa que PHP solo podría intentar usar 10GB, causando un intenso intercambio del sistema o activando el OOM killer de Linux, que termina procesos forzosamente para liberar memoria.

El enfoque correcto es equilibrar el límite de memoria con el número de workers PHP:

RAM disponible para PHP = RAM total - overhead SO - memoria MySQL - memoria servidor web - otros servicios
Workers PHP máximos = RAM disponible para PHP / memory_limit

Por ejemplo, en un VPS de 4GB: 4GB totales - 0,5GB SO - 1GB MySQL - 0,25GB Nginx = 2,25GB para PHP. Con memory_limit = 256M, puedes ejecutar de forma segura 8-9 workers PHP-FPM. Con memory_limit = 512M, solo puedes ejecutar 4 workers, lo que significa que se pueden atender menos solicitudes concurrentes.

Configura el pool PHP-FPM en consecuencia:

pm = dynamic
pm.max_children = 8
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5

Diagnosticar Fugas de Memoria y Uso Excesivo

Si aumentar el límite de memoria solo retrasa el error en lugar de solucionarlo, probablemente tienes una fuga de memoria o un proceso ineficiente. Aquí te mostramos cómo diagnosticar la causa raíz.

Habilitar el Modo Debug de PrestaShop

Edita config/defines.inc.php y establece:

define('_PS_MODE_DEV_', true);

Esto habilita la información detallada de errores, incluyendo el archivo exacto y el número de línea donde se excedió el límite de memoria. La traza de pila muestra la cadena de llamadas a funciones que llevaron al error, ayudándote a identificar el módulo o la función core responsable.

Monitorear el Uso de Memoria en el Código

Puedes añadir monitoreo de memoria a secciones específicas del código para identificar dónde ocurren los picos de memoria:

error_log('Memoria antes de la operación: ' . memory_get_usage(true) / 1024 / 1024 . ' MB');
// ... operación ...
error_log('Memoria después de la operación: ' . memory_get_usage(true) / 1024 / 1024 . ' MB');
error_log('Pico de memoria: ' . memory_get_peak_usage(true) / 1024 / 1024 . ' MB');

La función memory_get_usage(true) devuelve la cantidad real de memoria asignada por el SO a PHP, mientras que memory_get_peak_usage(true) devuelve la cantidad máxima asignada en cualquier punto durante la solicitud.

Usar el Profiling de Xdebug

El profiler de Xdebug genera informes detallados de llamadas a funciones, tiempo de ejecución y consumo de memoria. Habilítalo temporalmente en tu configuración PHP:

xdebug.mode = profile
xdebug.output_dir = /tmp/xdebug

Abre los archivos cachegrind generados en una herramienta como KCacheGrind o Webgrind para visualizar qué funciones consumen más memoria. Este es el enfoque diagnóstico más exhaustivo, pero solo debería usarse en servidores de desarrollo debido a la significativa sobrecarga de rendimiento.

Verificar Consultas Lentas y MySQL

A veces lo que parece ser un problema de memoria PHP es en realidad un problema de MySQL. Una consulta lenta que devuelve millones de filas hará que PHP asigne memoria para todo el conjunto de resultados. Verifica el log de consultas lentas de MySQL:

sudo tail -100 /var/log/mysql/slow-query.log

Si ves consultas con conjuntos de resultados grandes, añade cláusulas LIMIT apropiadas o implementa paginación en el módulo responsable.

Memoria OPcache

OPcache es una extensión PHP que almacena en caché el bytecode PHP compilado en memoria compartida, eliminando la necesidad de analizar y compilar los archivos PHP en cada solicitud. OPcache tiene su propia asignación de memoria, separada de memory_limit.

La memoria predeterminada de OPcache (opcache.memory_consumption) es 128MB. PrestaShop con varios módulos instalados puede superar fácilmente esto. Cuando OPcache se queda sin memoria, comienza a expulsar entradas en caché y recompilar archivos en cada solicitud, causando una degradación significativa del rendimiento.

Verifica el estado de OPcache desde la línea de comandos:

php -r "print_r(opcache_get_status());"

O mira la sección opcache en tu salida de phpinfo(). Valores clave a monitorear:

opcache.memory_consumption: Memoria total asignada para OPcache (aumenta a 256M para PrestaShop)
opcache.max_accelerated_files: Número máximo de archivos que OPcache puede almacenar en caché (aumenta a 20000 para PrestaShop)
Memoria usada vs Memoria libre: Si la memoria libre está cerca de cero, aumenta memory_consumption
Tasa de aciertos de caché: Debería ser superior al 99%. Por debajo del 95% indica presión de memoria o invalidación frecuente de caché

Configuración de OPcache recomendada para PrestaShop:

opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 0
opcache.interned_strings_buffer = 16

Ten en cuenta que la memoria de OPcache es compartida entre todos los procesos PHP, a diferencia de memory_limit que es por proceso. Aumentar la memoria de OPcache no se multiplica por el número de workers.

Configuración de Memoria MySQL

MySQL tiene su propia configuración de memoria que afecta indirectamente al rendimiento de PrestaShop y puede contribuir a la presión general de memoria del servidor. Las principales configuraciones de memoria de MySQL incluyen:

innodb_buffer_pool_size: El buffer de memoria principal para las tablas InnoDB. Establece al 50-70% de la RAM disponible en un servidor de base de datos dedicado, o al 25-50% en un servidor compartido que ejecuta tanto PHP como MySQL. Esta es la configuración de rendimiento de MySQL más importante.
sort_buffer_size y join_buffer_size: Buffers por conexión para ordenamiento y uniones. Mantén estos en sus valores predeterminados a menos que tengas consultas lentas específicas que se beneficien de buffers más grandes. Establecerlos demasiado altos desperdicia memoria porque se asignan por conexión.
query_cache_size: Obsoleto en MySQL 8.0 y eliminado completamente. Si todavía estás en MySQL 5.7, una caché de consultas pequeña (64M) puede ayudar, pero cachés grandes causan contención y reducen el rendimiento.

Si MySQL consume demasiada memoria, queda menos para PHP, lo que potencialmente te obliga a reducir los workers PHP-FPM o el límite de memoria. Usa mysqladmin status o SHOW GLOBAL STATUS para monitorear el consumo de memoria de MySQL.

Cuándo Actualizar Tu Hosting

A veces aumentar el límite de memoria y optimizar el código no es suficiente. Aquí están las señales de que necesitas un servidor más potente:

Constantemente alcanzas el límite de memoria máximo: Si tus procesos utilizan regularmente el 90%+ de la memoria asignada, incluso después de la optimización, necesitas más RAM.
El servidor intercambia frecuentemente: Verifica con free -h o vmstat 1. Si el uso de swap es consistentemente alto, no tienes suficiente RAM física.
Reducir los workers PHP está perjudicando el rendimiento: Si tuviste que reducir los workers PHP-FPM a 3-4 para acomodar el límite de memoria, tu sitio no puede manejar visitantes concurrentes efectivamente.
Tu catálogo sigue creciendo: Una tienda que funcionaba bien con 1.000 productos puede tener dificultades con 10.000. Las necesidades de memoria escalan con el tamaño del catálogo, especialmente para la indexación de búsqueda, el listado de categorías y las operaciones del back office.
Necesitas memory_limit superior a 1G: Si un único proceso PHP necesita más de 1GB de memoria para operaciones normales (no importaciones), algo está fundamentalmente mal en tu código o en la capacidad de tu hosting. Investiga la causa raíz antes de continuar aumentando el límite.

Al actualizar, prioriza más RAM sobre más núcleos de CPU para PrestaShop. Un servidor con 8GB de RAM y 2 núcleos servirá mejor a PrestaShop que uno con 4GB de RAM y 4 núcleos. También considera separar MySQL en su propio servidor o usar un servicio de base de datos gestionado, lo que libera completamente la RAM del servidor de aplicaciones para PHP.

Referencia Rápida: Configuraciones Recomendadas por Tamaño de Tienda

Las siguientes recomendaciones sirven como puntos de partida. Monitorea tu uso real y ajusta en consecuencia.

Tienda pequeña (menos de 1.000 productos, pocos módulos): memory_limit = 256M, 2GB RAM, 4-6 workers PHP
Tienda mediana (1.000-10.000 productos, 20+ módulos): memory_limit = 512M, 4GB RAM, 6-8 workers PHP
Tienda grande (10.000+ productos, muchas combinaciones): memory_limit = 512M-1G, 8GB+ RAM, 8-16 workers PHP, servidor de base de datos separado
Durante importaciones: Aumenta temporalmente a 1G o 2G, luego restaura el valor normal

Recuerda que el límite de memoria es un techo de seguridad, no un objetivo. Una tienda PrestaShop bien optimizada debería rara vez usar más de 128-256MB por solicitud durante las cargas de página normales. Si las operaciones normales necesitan constantemente 512MB o más, investiga y soluciona la causa subyacente en lugar de continuar aumentando el límite.

Leer respuesta completa

Comprender max_input_vars en PrestaShop

Si alguna vez has intentado guardar un producto con docenas o cientos de combinaciones en PrestaShop y has experimentado un fallo silencioso, un guardado parcial o un error críptico, el culpable es casi con seguridad la directiva PHP max_input_vars. Esta configuración controla cuántos campos de formulario individuales aceptará PHP en una única solicitud POST. Cuando PrestaShop envía un formulario de producto que excede este límite, cada campo más allá del umbral se descarta silenciosamente, lo que lleva a guardados incompletos, combinaciones faltantes o datos que simplemente desaparecen sin ningún mensaje de error visible.

Por defecto, la mayoría de las instalaciones PHP vienen con max_input_vars establecido en 1000. Para un simple blog o sitio informativo, esto es más que suficiente. Para PrestaShop, sin embargo, las páginas de edición de productos pueden generar miles de campos de formulario, especialmente cuando están involucradas combinaciones, campos multilingües y características personalizadas. Comprender esta directiva, saber cómo calcular el valor que tu tienda realmente necesita y aplicar la corrección correctamente te ahorrará horas de depuración.

Por Qué PrestaShop Necesita Valores max_input_vars Altos

El formulario de edición de productos de PrestaShop es uno de los formularios más complejos de cualquier plataforma de comercio electrónico. Cada combinación de un producto genera múltiples campos de entrada: uno para el impacto en el precio, uno para el impacto en el peso, uno para la cantidad, uno para la referencia, uno para el EAN-13, uno para el UPC, uno para el MPN, uno para la cantidad mínima, uno para el umbral de stock bajo, uno para la fecha de disponibilidad y varios más dependiendo de tu configuración. Una sola combinación puede producir fácilmente de 15 a 25 campos de formulario.

Ahora multiplica eso por el número de combinaciones. Una camiseta disponible en 5 tallas y 10 colores tiene 50 combinaciones. A 20 campos por combinación, eso ya son 1.000 campos solo para la pestaña de combinaciones. Añade los campos del producto base, los campos SEO para cada idioma, los valores de características, los precios específicos y otras pestañas, y puedes alcanzar fácilmente 1.500 a 2.000 campos para un producto moderadamente complejo.

Para las tiendas que venden productos con conjuntos extensos de atributos, como electrónica con diferentes capacidades de almacenamiento, colores, opciones de RAM y variantes regionales, un solo producto puede tener 200 o más combinaciones, generando más de 4.000 campos de formulario. El límite predeterminado de 1.000 ni siquiera se acerca a ser suficiente.

Síntomas de max_input_vars Demasiado Bajo

El aspecto más frustrante de alcanzar el límite max_input_vars es que PHP no genera un error. Trunca silenciosamente los datos de entrada. Esto significa que verás una variedad de síntomas confusos sin ninguna indicación clara de qué salió mal.

El síntoma más común es que las combinaciones desaparecen después de guardar. Creas 80 combinaciones, haces clic en guardar y cuando la página se recarga solo hay 40 presentes. El formulario envió las 80, pero PHP solo procesó la primera porción de los datos POST antes de alcanzar el límite, por lo que las combinaciones restantes nunca fueron recibidas por el servidor.

Otro síntoma común es que los datos del producto se guardan parcialmente. La pestaña de información básica se guarda correctamente, pero los datos de precios, SEO o combinaciones se pierden. Esto sucede porque los campos del formulario se envían en un orden específico, y cualquier campo que viene después del punto de corte se descarta.

También puedes experimentar que la página del producto simplemente se recarga sin guardar, o PrestaShop muestra un error genérico como "Se produjo un error al actualizar el producto". En PrestaShop 1.7 y 8.x, la página de producto basada en Symfony puede mostrar errores de validación para campos obligatorios que en realidad estaban completados pero fueron truncados por PHP.

Un síntoma menos obvio afecta a las tiendas multilingües. Si tu tienda soporta 5 idiomas, cada campo de texto se multiplica por 5. Un producto que se guarda bien en una tienda monolingüe falla en una multilingüe porque los campos adicionales de idiomas empujan el total más allá del límite.

Cómo Verificar Tu Valor Actual de max_input_vars

Antes de hacer cambios, verifica tu configuración actual. Crea un archivo PHP en el directorio raíz de PrestaShop (recuerda eliminarlo después por seguridad):

<?php phpinfo(); ?>

Accede a este archivo a través de tu navegador y busca max_input_vars. Verás tanto el Valor Local (lo que está actualmente activo) como el Valor Master (el predeterminado de php.ini). Presta atención al Valor Local, ya que puede diferir del Valor Master si un .htaccess o una configuración por directorio lo sobreescribe.

Alternativamente, puedes verificar desde el back office de PrestaShop. Navega a Parámetros Avanzados, luego Información. La sección de configuración PHP muestra las configuraciones PHP clave incluyendo max_input_vars. PrestaShop 1.7.7 y versiones posteriores también muestran una advertencia en esta página si el valor se considera demasiado bajo.

Calcular el Valor max_input_vars Que Necesitas

En lugar de establecer ciegamente un número alto, puedes estimar el valor que tu tienda requiere. Usa esta fórmula como punto de partida:

Valor requerido = (número de combinaciones x campos por combinación) + campos de producto base + (campos de texto x número de idiomas) + margen de seguridad

Para un ejemplo práctico, considera una tienda con 3 idiomas y un producto con 100 combinaciones. El cálculo sería: 100 combinaciones multiplicadas por 20 campos cada una equivalen a 2.000. Los campos de producto base a través de todas las pestañas contribuyen con aproximadamente 200. Los campos de texto (nombre, descripción, meta título, meta descripción, enlace reescrito y otros) multiplicados por 3 idiomas añaden otros 150. Añadiendo un margen de seguridad del 20% el total llega a aproximadamente 2.820.

Para la mayoría de las tiendas PrestaShop, establecer max_input_vars en 10000 proporciona un margen amplio. Las tiendas con productos que tienen 300+ combinaciones o que operan en 5+ idiomas deberían considerar 20000 o incluso 50000. La sobrecarga de memoria de un valor más alto es insignificante en servidores modernos.

Cómo Aumentar max_input_vars

Método 1: php.ini (Recomendado)

Si tienes acceso a la configuración PHP de tu servidor, editar php.ini es el enfoque más limpio. Localiza tu archivo php.ini (la salida de phpinfo() te dice exactamente qué archivo se carga) y encuentra o añade la siguiente línea:

max_input_vars = 10000

Después de guardar el archivo, reinicia tu servidor web o el servicio PHP-FPM para que el cambio tenga efecto. En Apache con mod_php, reinicia Apache. En Nginx con PHP-FPM, reinicia el servicio php-fpm. El comando exacto depende de tu sistema operativo y versión de PHP.

Método 2: .htaccess (Apache con mod_php o mod_fcgid)

Si no tienes acceso a php.ini, como en hosting compartido, puedes intentar añadir la directiva al archivo .htaccess en el directorio raíz de PrestaShop:

php_value max_input_vars 10000

Este método solo funciona si PHP se ejecuta como módulo Apache (mod_php). Si tu host usa PHP-FPM o CGI, esta directiva causará un error 500 Internal Server Error. En ese caso, elimina la línea inmediatamente e prueba el siguiente método.

Método 3: .user.ini (PHP-FPM / CGI)

Para servidores que ejecutan PHP-FPM, crea o edita un archivo .user.ini en el directorio raíz de PrestaShop:

max_input_vars = 10000

Ten en cuenta que los cambios en .user.ini no son inmediatos. PHP almacena en caché este archivo por un período definido por user_ini.cache_ttl, que por defecto es de 300 segundos (5 minutos). Espera al menos 5 minutos después de guardar el archivo antes de probar.

Método 4: Panel de Control del Hosting

Muchos proveedores de hosting exponen las configuraciones PHP a través de su panel de control. En cPanel, navega a "Select PHP Version" o "MultiPHP INI Editor" y busca max_input_vars. En Plesk, ve a Configuración PHP para tu dominio. DirectAdmin y otros paneles tienen opciones similares. Este es a menudo el método más fácil en hosting compartido.

La Complicación del Parche Suhosin

Suhosin es un parche de seguridad PHP que era común en servidores más antiguos, particularmente los que ejecutaban PHP 5.x. Impone su propio conjunto de límites de entrada que sobreescriben la configuración estándar max_input_vars. Incluso si aumentas max_input_vars a 10000, Suhosin puede seguir imponiendo un límite inferior a través de sus propias directivas.

Las configuraciones específicas de Suhosin que necesitas ajustar son:

suhosin.post.max_vars = 10000
suhosin.request.max_vars = 10000

Estas deben establecerse además del max_input_vars estándar. Si tu salida de phpinfo() muestra una sección Suhosin, estás afectado y debes ajustar los tres valores. Las configuraciones de Suhosin típicamente solo pueden cambiarse en php.ini, no en .htaccess o .user.ini.

En instalaciones modernas de PHP 7.x y 8.x, Suhosin está raramente presente. Si estás ejecutando una versión reciente de PHP, casi con seguridad no necesitas preocuparte por ello. Sin embargo, si estás en una cuenta de hosting compartido más antigua que no ha sido actualizada, vale la pena verificar.

Enfoques Alternativos para Productos con 500+ Combinaciones

Mientras que aumentar max_input_vars resuelve el problema inmediato, las tiendas con números extremadamente altos de combinaciones por producto deberían considerar enfoques alternativos que reduzcan el conteo de campos del formulario o eviten la limitación por completo.

Importar Combinaciones mediante CSV

La funcionalidad de importación integrada de PrestaShop procesa las combinaciones a través de la carga de archivos en lugar del envío de formularios, evitando completamente el límite max_input_vars. Prepara un archivo CSV con los datos de tus combinaciones e impórtalo a través del back office en Parámetros Avanzados, Importar. Este es a menudo el enfoque más práctico para productos con cientos de combinaciones.

Usar la API Webservice de PrestaShop

La API webservice de PrestaShop permite crear y actualizar combinaciones programáticamente. Las solicitudes API no están sujetas a max_input_vars porque usan payloads estructurados en XML o JSON en lugar de datos POST codificados como formulario. Este enfoque requiere conocimientos técnicos pero escala a cualquier número de combinaciones.

Dividir Productos Grandes

En algunos casos, tiene más sentido comercial dividir un producto con 500+ combinaciones en múltiples productos. Un producto con 5 tallas y 100 colores podría dividirse en 5 productos, uno por talla, cada uno con 100 opciones de color. Esto no solo evita la limitación técnica sino que a menudo mejora también la experiencia del cliente.

Gestionar Combinaciones en Lotes

Si debes usar el formulario del back office, crea combinaciones en lotes más pequeños. Genera 50 combinaciones a la vez, guarda, luego genera las siguientes 50. Esto es tedioso pero evita alcanzar el límite sin requerir cambios en la configuración del servidor.

Verificar la Corrección

Después de aumentar max_input_vars, verifica que el cambio haya tenido efecto. Comprueba phpinfo() de nuevo y confirma que el Valor Local coincide con lo que estableciste. Luego prueba editando tu producto más complejo, haciendo un pequeño cambio y guardando. Todas las combinaciones y datos deberían preservarse.

Si el problema persiste después de aumentar el valor, verifica estas posibilidades adicionales. Tu proveedor de hosting puede estar sobreescribiendo tus configuraciones con una configuración global. La instancia PHP que sirve tu sitio web puede ser diferente de la mostrada en un phpinfo() de CLI. Puede haber un límite del servidor web como LimitRequestBody de Apache o client_max_body_size de Nginx que también está truncando la solicitud. Algunos firewalls de aplicaciones web (WAF) o plugins de seguridad (como ModSecurity) imponen sus propios límites en el tamaño de datos POST y el número de parámetros.

Configuraciones PHP Relacionadas a Verificar

Mientras ajustas max_input_vars, revisa estas configuraciones relacionadas que también pueden causar problemas con formularios de productos grandes:

post_max_size: Establece el tamaño máximo de datos POST en bytes. Si los datos de tu formulario exceden este límite (típicamente cuando los productos tienen muchos campos de texto grandes en múltiples idiomas), el POST completo se descarta. Establece esto en al menos 32M para PrestaShop.

memory_limit: El procesamiento de miles de campos de formulario requiere memoria. Si PHP se queda sin memoria al analizar la entrada, la solicitud falla. Se recomienda un valor de 256M o 512M para PrestaShop.

max_execution_time: Guardar un producto con muchas combinaciones implica numerosas consultas a la base de datos. Si la operación de guardado tarda más que el tiempo de ejecución permitido, será terminada a mitad del proceso, llevando a guardados parciales. Establece esto en al menos 300 segundos para tiendas con productos complejos.

max_input_nesting_level: PrestaShop usa arrays anidados en los datos del formulario (por ejemplo, los campos multilingües usan arrays como name[1], name[2]). El nivel de anidamiento predeterminado de 64 es generalmente suficiente, pero si encuentras problemas con estructuras de formulario profundamente anidadas, aumenta a 128 o 256.

Notas Específicas por Versión de PrestaShop

En PrestaShop 1.6, la página del producto es completamente PHP legacy con un envío de formulario tradicional. El problema de max_input_vars afecta a todas las operaciones en la página del producto. No hay solución alternativa más que aumentar el límite o usar importaciones.

PrestaShop 1.7 introdujo una página de producto parcialmente basada en Symfony. Aunque la arquitectura cambió, el envío del formulario subyacente sigue usando datos POST y sigue estando sujeto a los mismos límites PHP. El componente de formularios de Symfony puede mostrar mensajes de error más informativos cuando faltan campos, pero la causa raíz es la misma.

PrestaShop 8.x presenta una página de producto completamente rediseñada con una nueva estructura de formulario Symfony. La gestión de combinaciones fue significativamente reelaborada, con las combinaciones ahora gestionadas a través de una interfaz dedicada que carga y guarda datos mediante AJAX en lotes más pequeños. Este cambio arquitectónico reduce naturalmente el impacto de max_input_vars para los datos de combinaciones, aunque el formulario principal del producto aún puede verse afectado en tiendas multilingües con muchas características.

PrestaShop 9.x continúa la tendencia hacia el manejo de datos basado en AJAX, reduciendo aún más la dependencia de envíos masivos de formularios. Sin embargo, max_input_vars sigue siendo relevante para operaciones masivas y módulos legacy que todavía usan envíos de formularios tradicionales.

Prevenir Problemas Futuros

Establece max_input_vars en un valor generoso durante la instalación inicial de PrestaShop en lugar de esperar a que aparezcan los problemas. Un valor de 20000 es seguro para prácticamente todos los escenarios y no tiene un impacto significativo en el rendimiento. Documenta la configuración en tus notas de configuración del servidor para que las futuras migraciones la preserven.

Si eres un proveedor de hosting o administrador de sistemas que gestiona múltiples instalaciones de PrestaShop, considera establecer max_input_vars = 20000 como predeterminado en tus plantillas de configuración PHP. Este único cambio elimina una de las solicitudes de soporte más comunes relacionadas con la gestión de productos de PrestaShop.

Monitorea tus registros de errores después de hacer los cambios. Aunque el truncamiento de max_input_vars en sí no genera errores PHP, algunas versiones de PrestaShop registran advertencias cuando detectan que los datos recibidos no coinciden con los datos esperados. Estas entradas de registro pueden ayudarte a identificar si el límite aún se está alcanzando a pesar de tu aumento.

Leer respuesta completa

Por Qué Aparecen Páginas en Blanco Después de las Actualizaciones de PrestaShop

Una página blanca vacía, a menudo llamada White Screen of Death (WSOD) o pantalla blanca de la muerte, es uno de los problemas más comunes y alarmantes que enfrentan los propietarios de tiendas PrestaShop después de actualizar el software core. Inicias una actualización de la versión 1.7.8.7 a la 1.7.8.8, o de la 8.1.0 a la 8.1.5, el proceso parece completarse, y luego toda tu tienda, tanto el front office como el back office, muestra nada más que una pantalla blanca. Sin mensajes de error, sin contenido parcial, solo vacío.

Comprender por qué ocurre esto requiere entender lo que hace una actualización del core de PrestaShop. El proceso de actualización reemplaza cientos de archivos PHP, modifica tablas de la base de datos, regenera índices de clases, vacía cachés y potencialmente ejecuta consultas de migración. Cualquier fallo en cualquier punto de esta cadena puede dejar la tienda en un estado inconsistente donde PHP encuentra un error fatal pero no tiene forma de mostrarlo porque la notificación de errores está deshabilitada en modo producción.

Las causas más comunes se agrupan en varias categorías: módulos incompatibles que hacen referencia a clases core eliminadas o modificadas, incompatibilidades de versión PHP entre la versión antigua y la nueva de PrestaShop, conflictos de archivos override donde las personalizaciones colisionan con archivos core modificados, recursos de servidor insuficientes que causan que el proceso de actualización termine a mitad del proceso, y fallos de migración de base de datos que dejan las tablas en un estado inconsistente.

Paso 1: Habilitar el Modo Debug

La primera acción cuando te enfrentas a una página en blanco es hacer visibles los errores. PrestaShop suprime la salida de errores en modo producción para evitar exponer información sensible a los visitantes. Necesitas habilitar temporalmente el modo debug para ver qué está realmente fallando.

El método más rápido es editar el archivo /config/defines.inc.php. Busca la línea que define _PS_MODE_DEV_ y cámbiala:

define('_PS_MODE_DEV_', true);

Si no puedes acceder a los archivos vía FTP o SSH porque tu panel de hosting también es inaccesible, algunos proveedores de hosting ofrecen un administrador de archivos a través de su panel de control (cPanel, Plesk, DirectAdmin) que opera independientemente de tu instalación de PrestaShop.

En PrestaShop 8.x, también puedes habilitar el modo debug a través del archivo .env en el directorio raíz. Cambia APP_ENV=prod a APP_ENV=dev y establece APP_DEBUG=1. Esto activa la barra de herramientas de depuración de Symfony y las páginas de error detalladas.

Después de habilitar el modo debug, recarga la página. En lugar de una pantalla blanca, ahora deberías ver un mensaje de error detallado con una ruta de archivo, número de línea y traza de pila. Este mensaje de error es la clave para diagnosticar y resolver el problema.

Paso 2: Verificar los Registros de Errores

Si habilitar el modo debug sigue mostrando una página en blanco (lo que puede ocurrir si el error sucede antes de que PHP cargue el framework de PrestaShop), verifica directamente los registros de errores del servidor.

En servidores Apache, el registro de errores se encuentra típicamente en /var/log/apache2/error.log o /var/log/httpd/error_log. En Nginx con PHP-FPM, verifica /var/log/nginx/error.log y /var/log/php-fpm/error.log (o /var/log/php8.1-fpm.log dependiendo de tu versión de PHP). En hosting compartido, los registros de errores generalmente son accesibles a través del panel de control del hosting o en un directorio logs dentro de tu cuenta de hosting.

PrestaShop también mantiene sus propios archivos de registro en el directorio /var/logs/ (PrestaShop 1.7) o /var/log/ (PrestaShop 8.x). Busca archivos con la fecha actual. Estos registros basados en Symfony pueden contener información detallada sobre lo que salió mal durante el proceso de actualización.

Además, verifica el directorio /log/ en el directorio raíz de PrestaShop para cualquier archivo de registro de errores. Algunas versiones de PrestaShop escriben errores críticos aquí cuando no pueden mostrarlos en pantalla.

Causa Común 1: Módulos Incompatibles

Los módulos son la causa más frecuente de páginas en blanco después de las actualizaciones. Un módulo que funcionaba perfectamente en PrestaShop 1.7.8.7 puede hacer que toda la tienda se caiga en la 1.7.8.8 si utiliza clases o métodos core internos que cambiaron en la actualización.

El mensaje de error típicamente aparece como: Fatal error: Class 'NombreClase' not found o Fatal error: Call to undefined method NombreClase::nombreMetodo() o Fatal error: Declaration of ClaseModulo::hookMethod() must be compatible with ClaseCore::hookMethod().

Para solucionarlo, necesitas identificar y desactivar el módulo problemático. Si puedes acceder al back office (a veces solo el front office se cae), ve a Módulos y desactiva los módulos recientemente instalados o actualizados uno por uno hasta que el problema se resuelva.

Si el back office también es inaccesible, desactiva los módulos a través de la base de datos. Conéctate a tu base de datos usando phpMyAdmin o un cliente MySQL y ejecuta:

UPDATE ps_module SET active = 0 WHERE name = 'nombre_modulo_problematico';

Si no sabes qué módulo está causando el problema, puedes desactivar todos los módulos de terceros a la vez estableciendo su columna active en 0. Primero, identifica qué módulos son de terceros verificando el directorio /modules/ para módulos no nativos de PrestaShop. Luego desactívalos selectivamente.

Un enfoque más agresivo es renombrar el directorio del módulo. Por ejemplo, renombra /modules/algunmodulo/ a /modules/algunmodulo_desactivado/. PrestaShop no puede cargar un módulo cuyo directorio no coincide con su nombre registrado, desactivándolo efectivamente sin tocar la base de datos.

Causa Común 2: Incompatibilidad de Versión PHP

Cada versión de PrestaShop requiere un rango específico de versiones PHP. PrestaShop 1.7.6 y anteriores requieren PHP 7.1 a 7.3. PrestaShop 1.7.7 a 1.7.8 soportan PHP 7.2 a 8.0. PrestaShop 8.0 requiere PHP 7.2 a 8.1. PrestaShop 8.1 requiere PHP 8.0 a 8.2. PrestaShop 9.0 requiere PHP 8.1 o superior.

Si tu entorno de hosting cambió las versiones de PHP durante o junto con la actualización de PrestaShop, puedes encontrar errores de sintaxis o llamadas a funciones obsoletas. Los errores comunes de compatibilidad PHP incluyen: Deprecated: Function create_function() is deprecated (PHP 7.2+ con código escrito para PHP 5.x), Fatal error: Uncaught Error: Call to undefined function mysql_connect() (PHP 7.0+ eliminó la extensión mysql), y Fatal error: Array and string offset access syntax with curly braces is no longer supported (PHP 8.0+).

Verifica tu versión PHP actual mirando la salida de phpinfo() o ejecutando php -v en la línea de comandos. Si la versión está fuera del rango soportado para tu versión de PrestaShop, cambia a una versión PHP compatible a través de tu panel de control de hosting.

Causa Común 3: Conflictos de Override

El sistema de override de PrestaShop permite a módulos y desarrolladores modificar el comportamiento core colocando archivos de clase modificados en el directorio /override/. Durante una actualización, las clases core cambian, pero los archivos de override permanecen. Si un override hace referencia a una firma de método que cambió, una propiedad que fue eliminada o una clase que fue renombrada, el override causa un error fatal.

El archivo de índice de clases en /var/cache/prod/class_index.php (o /cache/class_index.php en versiones anteriores) mapea los nombres de clases a sus ubicaciones de archivo, incluyendo los overrides. Un índice de clases obsoleto o corrupto puede cargar el archivo equivocado para una clase, causando caídas inmediatas.

Para probar si los overrides son el problema, desactiva temporalmente el sistema de override. Edita /config/defines.inc.php y añade o modifica:

define('_PS_HOST_MODE_', false);

Luego elimina el archivo de índice de clases para forzar a PrestaShop a regenerarlo sin overrides. Si la tienda carga después de este cambio, el problema está en uno de tus archivos de override.

Para identificar el override problemático específico, mira en los directorios /override/classes/ y /override/controllers/. Elimina los archivos de override uno a la vez, eliminando el índice de clases después de cada eliminación, hasta que encuentres el que causa la caída. Una vez identificado, actualiza el override para que sea compatible con la nueva versión core o elimínalo completamente si ya no es necesario.

Causa Común 4: Caché y Archivos Compilados

PrestaShop genera plantillas Smarty compiladas, cachés de contenedores Symfony, mapas de clases y varios otros archivos en caché que se vuelven inválidos después de una actualización. Si el proceso de actualización no vació correctamente estas cachés, la tienda intenta usar archivos en caché que hacen referencia a la estructura de código anterior.

Vacía todas las cachés manualmente eliminando el contenido de estos directorios (elimina el contenido, no los directorios mismos):

/var/cache/prod/ y /var/cache/dev/ para la caché de Symfony. Elimina todo dentro de estos directorios. PrestaShop los regenerará en la próxima carga de página.

/cache/smarty/compile/ y /cache/smarty/cache/ para las cachés de plantillas Smarty. Las plantillas compiladas obsoletas son una causa muy común de páginas en blanco después de las actualizaciones.

/var/cache/prod/class_index.php (o /cache/class_index.php) para el mapa de clases. Este archivo debe ser regenerado después de cualquier actualización.

En configuraciones PHP-FPM, también restablece OPcache. OPcache almacena bytecode PHP compilado en memoria y puede servir el código antiguo incluso después de que los archivos hayan sido reemplazados. Reinicia el servicio PHP-FPM o, si no puedes hacerlo, crea un pequeño archivo PHP que llame a opcache_reset() y accede a él a través de tu navegador.

Causa Común 5: Fallos en la Migración de la Base de Datos

Las actualizaciones de PrestaShop a menudo incluyen cambios en el esquema de la base de datos: nuevas columnas, índices modificados, nuevas tablas o migraciones de datos. Si el proceso de actualización fue interrumpido (timeout, límite de memoria, caída de conexión), la base de datos puede estar en un estado de migración parcial.

Verifica la base de datos de PrestaShop para la tabla ps_configuration y busca el valor PS_VERSION_DB. Si este valor no coincide con la versión de los archivos en disco, la actualización no se completó correctamente. PrestaShop puede intentar re-ejecutar las migraciones en la próxima carga, o simplemente puede fallar.

Los fallos de migración de base de datos son los más difíciles de recuperar sin un respaldo. Si tienes un respaldo de la base de datos de antes de la actualización, restaurarlo y re-ejecutar la actualización es a menudo el camino más seguro. Si no tienes un respaldo, es posible que necesites aplicar manualmente los archivos de migración SQL faltantes encontrados en el directorio /install/upgrade/sql/.

Procedimiento de Recuperación Paso a Paso

Sigue esta secuencia cuando te recuperes de una página en blanco después de una actualización core. El orden importa porque cada paso o resuelve el problema o elimina una posible causa.

Paso 1: Habilita el modo debug en /config/defines.inc.php estableciendo _PS_MODE_DEV_ a true. Recarga la página y lee el mensaje de error.

Paso 2: Elimina el contenido de /var/cache/prod/, /var/cache/dev/, /cache/smarty/compile/ y /cache/smarty/cache/. Elimina class_index.php. Recarga la página.

Paso 3: Si el error apunta a un módulo específico, desactiva ese módulo renombrando su directorio o estableciendo active = 0 en la tabla de base de datos ps_module. Recarga la página.

Paso 4: Si el error apunta a un archivo de override, mueve el contenido del directorio /override/ a una ubicación de respaldo temporal. Elimina class_index.php nuevamente. Recarga la página.

Paso 5: Verifica que tu versión PHP sea compatible con la versión de PrestaShop a la que actualizaste. Verifica phpinfo() o php -v. Cambia la versión de PHP si es necesario.

Paso 6: Verifica los permisos de archivos. El proceso de actualización puede haber creado archivos con propiedad incorrecta. Todos los archivos de PrestaShop deben ser legibles por el usuario del servidor web, y los directorios /var/, /cache/, /img/, /upload/, /download/, /translations/, /themes/ y /modules/ deben ser escribibles.

Paso 7: Si ninguno de los pasos anteriores resuelve el problema y tienes un respaldo de la base de datos, restaura la base de datos y los archivos del respaldo, luego intenta la actualización nuevamente después de abordar cualquier problema que identificaste durante el diagnóstico.

Procedimiento de Actualización Seguro para Futuras Actualizaciones

La prevención es mucho mejor que la recuperación. Sigue este procedimiento para cada actualización del core de PrestaShop para minimizar el riesgo de páginas en blanco y pérdida de datos.

Antes de la actualización: Crea un respaldo completo tanto de la base de datos como de todos los archivos. No solo la base de datos, no solo los archivos, sino ambos. Almacena estos respaldos en una ubicación fuera de tu cuenta de hosting si es posible. Verifica que puedas realmente restaurar desde estos respaldos antes de proceder.

Desactiva todos los módulos de terceros. Este es el paso más efectivo que puedes tomar para prevenir páginas en blanco. Los módulos core (los que vienen con PrestaShop) están diseñados para ser compatibles con la actualización, pero los módulos de terceros no tienen garantía. Desactívalos antes de la actualización y reactívalos uno por uno después, probando la tienda después de cada reactivación.

Desactiva el sistema de override. Si tienes overrides personalizados, desactívalos antes de la actualización. Re-evalúa cada override después de la actualización para determinar si sigue siendo compatible y si todavía es necesario.

Revisa las notas de la versión. Cada lanzamiento de PrestaShop incluye notas sobre requisitos de compatibilidad, problemas conocidos y cambios que rompen compatibilidad. Léelas antes de actualizar, no después de que algo se rompa.

Pon la tienda en modo mantenimiento. Esto evita que los clientes hagan pedidos durante la actualización y encuentren errores. Navega a Parámetros de la Tienda, General, Mantenimiento en el back office y habilita el modo mantenimiento.

Durante la actualización: Monitorea el proceso de actualización. No cierres la pestaña del navegador ni navegues a otro lugar. Si la actualización tarda más de lo esperado, verifica los registros de errores del servidor para errores de timeout o memoria. Si el proceso parece atascado, espera al menos 10 minutos antes de tomar cualquier acción, ya que las tiendas grandes pueden tener migraciones de base de datos significativas que procesar.

Después de la actualización: Vacía todas las cachés. Verifica que el back office carga correctamente. Verifica el front office. Reactiva los módulos uno por uno, verificando la tienda después de cada uno. Reactiva los overrides uno por uno si aplica. Desactiva el modo mantenimiento. Monitorea los registros de errores durante las siguientes 24 horas.

Estrategias de Rollback

Cuando la recuperación no es posible o consume demasiado tiempo, volver a la versión anterior puede ser la mejor opción. Sin embargo, PrestaShop no tiene un mecanismo de rollback integrado, por lo que necesitas planificar esta posibilidad antes de iniciar la actualización.

Rollback completo desde respaldo: Restaura tanto la base de datos como los archivos desde tu respaldo pre-actualización. Este es el enfoque más limpio pero requiere que hayas hecho un respaldo completo antes de la actualización. Después de restaurar, verifica que la tienda funcione correctamente y que ningún pedido o dato de cliente creado durante el período de actualización fallida se haya perdido (si la tienda estaba en modo mantenimiento, nada debería haber cambiado).

Rollback parcial de archivos: Si solo los archivos están corruptos pero la base de datos está bien, puedes reemplazar los archivos de PrestaShop con la versión anterior manteniendo la base de datos actual. Descarga la versión anterior exacta de PrestaShop del archivo oficial de lanzamientos, extráela y sobrescribe los archivos en tu servidor. Mantén tus módulos personalizados, temas y archivos de configuración. Este enfoque es arriesgado porque la base de datos puede haber sido parcialmente migrada, creando una inconsistencia entre los archivos y el esquema de la base de datos.

Corrección hacia adelante: A veces el camino más rápido no es volver atrás sino corregir el error específico. Si el error es causado por un único módulo u override incompatible, corregir o eliminar ese único componente puede tomar minutos comparado con horas para un rollback completo. Este enfoque es mejor cuando has identificado claramente la causa desde el mensaje de error.

La Importancia de los Respaldos de la Base de Datos

Cada sección de esta guía menciona los respaldos, y por una buena razón. Una base de datos de PrestaShop contiene cada producto, cada pedido, cada cuenta de cliente, cada configuración y cada pieza de contenido de tu tienda. Perderla significa perder los datos de tu negocio.

Los respaldos diarios automatizados no son opcionales para una tienda PrestaShop en producción. Configura el sistema de respaldo de tu proveedor de hosting, usa un módulo de respaldo de base de datos o configura un cron job que ejecute mysqldump a intervalos regulares. Almacena los respaldos en múltiples ubicaciones. Prueba tu procedimiento de restauración periódicamente para asegurarte de que los respaldos sean realmente utilizables.

Antes de cualquier actualización, crea un respaldo manual además de tus respaldos automatizados. Nómbralo claramente con la fecha y la versión de PrestaShop, para que puedas identificarlo inmediatamente si necesitas restaurar.

Cuándo Buscar Ayuda Profesional

Si has seguido todos los pasos de esta guía y sigues enfrentando una página en blanco, o si los mensajes de error apuntan a problemas profundos del core que requieren correcciones a nivel de código, puede ser el momento de contratar a un desarrollador PrestaShop. Proporciónale los mensajes de error que recopilaste, las versiones de PrestaShop involucradas (antes y después de la actualización), tu versión de PHP y cualquier acción que ya hayas tomado. Esta información reducirá significativamente el tiempo necesario para diagnosticar y resolver el problema.

Intentar editar manualmente los archivos core de PrestaShop sin comprender la arquitectura del framework puede crear problemas adicionales. Si el mensaje de error hace referencia a contenedores Symfony, inyección de dependencias o configuración del kernel, estas son áreas donde los cambios incorrectos pueden propagarse en múltiples fallos.

Leer respuesta completa

Como funcionan las actualizaciones del carrito en PrestaShop

Antes de profundizar en la resolucion de problemas, conviene entender como PrestaShop gestiona las operaciones del carrito. Cuando un cliente hace clic en "Anadir al carrito", el JavaScript del front-end envia una solicitud AJAX al servidor. El servidor procesa la solicitud, actualiza el carrito en la base de datos y en la sesion, y luego devuelve una respuesta JSON con el resumen actualizado del carrito. El JavaScript recibe esta respuesta y actualiza el bloque del carrito, la pagina del producto y cualquier otro elemento dependiente del carrito en la pagina, sin necesidad de recargar completamente la pagina.

Este enfoque basado en AJAX, introducido completamente en PrestaShop 1.7, reemplazo el antiguo metodo de recarga de pagina utilizado en PrestaShop 1.6. Aunque proporciona una experiencia de compra mucho mas fluida, tambien introduce mas puntos potenciales de fallo. Una actualizacion del carrito puede fallar a nivel de JavaScript, a nivel de solicitud AJAX, a nivel de procesamiento del servidor o a nivel de renderizado de la respuesta. Cada punto de fallo produce sintomas diferentes y requiere enfoques de diagnostico distintos.

En PrestaShop 1.7 y 8.x, el archivo JavaScript principal responsable de las operaciones del carrito es core.js, que utiliza jQuery para enviar solicitudes AJAX al controlador del carrito. El controlador del carrito procesa la solicitud y despacha eventos a los que los modulos pueden engancharse mediante hooks. La respuesta activa un evento a nivel de pagina (updateCart) que todos los componentes vinculados al carrito escuchan para actualizar los datos mostrados.

Sintoma: hacer clic en Anadir al carrito no produce ningun efecto

Cuando hacer clic en el boton Anadir al carrito no produce absolutamente ninguna respuesta, ninguna animacion, ningun indicador de carga, ningun error, el problema es casi siempre un error de JavaScript que impide la ejecucion del manejador del evento clic. El evento clic del boton nunca se captura, por lo que no se envia ninguna solicitud AJAX al servidor.

Abre las Herramientas para Desarrolladores del navegador (F12 o Ctrl+Shift+I en Chrome, Firefox y Edge) y ve a la pestana Consola. Recarga la pagina del producto y busca mensajes de error en rojo. Los errores comunes incluyen $ is not defined o jQuery is not defined (jQuery no se cargo correctamente), Uncaught TypeError: Cannot read property of undefined (el JavaScript de un modulo hace referencia a algo que no existe), o Uncaught SyntaxError (un archivo JavaScript tiene un error de sintaxis, a menudo de un modulo que no fue correctamente minificado).

Un unico error de JavaScript en la pagina puede detener la ejecucion de todo el JavaScript posterior, incluida la funcionalidad principal del carrito. Si un modulo cargado antes del JavaScript principal de PrestaShop genera un error, todo el sistema del carrito se bloquea aunque el modulo no tenga nada que ver con el carrito.

Para identificar el modulo causante, observa el nombre del archivo en el mensaje de error. Normalmente hara referencia a una ruta como /modules/algunmodulo/views/js/algunarchivo.js. Desactiva ese modulo temporalmente para confirmar que es la causa, y luego contacta al desarrollador del modulo para obtener una correccion.

Sintoma: Anadir al carrito gira pero nunca se completa

Si hacer clic en Anadir al carrito activa la animacion de carga pero esta gira indefinidamente, la solicitud AJAX fue enviada pero no recibio respuesta o recibio una respuesta de error. Ve a la pestana Red en las Herramientas para Desarrolladores, haz clic en Anadir al carrito y busca la solicitud AJAX. Normalmente sera una solicitud POST a una URL que contiene controller=cart o cart en la ruta.

Haz clic en la solicitud para inspeccionarla. Revisa la columna Estado: un estado 200 con un cuerpo de respuesta vacio o malformado indica un error PHP en el servidor que fue capturado antes de la salida. Un estado 500 indica un error del servidor no gestionado. Un estado 403 puede indicar un modulo de seguridad o WAF que esta bloqueando la solicitud. Un estado 408 o timeout indica que el servidor tardo demasiado en responder.

Si el estado es 200 pero el cuerpo de la respuesta contiene HTML en lugar de JSON (busca etiquetas HTML en la respuesta), significa que PHP encontro un aviso o notificacion que fue enviado a la salida antes de la respuesta JSON, rompiendo el analisis del JSON. Esto es extremadamente comun y es causado por modulos u overrides que generan texto (incluso una linea en blanco antes de la etiqueta PHP de apertura) durante los hooks de procesamiento del carrito.

Sintoma: el carrito se actualiza pero muestra datos incorrectos

A veces el carrito parece funcionar: la animacion se reproduce, el icono del carrito se actualiza, pero las cantidades, precios o productos mostrados son incorrectos. Esto es tipicamente un problema de cache donde el cliente ve datos obsoletos en lugar del carrito recien calculado.

PrestaShop tiene multiples capas de cache, cada una de las cuales puede servir informacion obsoleta del carrito. Comprender y verificar sistematicamente cada capa es esencial para diagnosticar este tipo de problema.

Problemas de cache del navegador

El propio navegador puede almacenar en cache las respuestas AJAX o los archivos JavaScript estaticos. Aunque las solicitudes AJAX POST no deberian ser almacenadas en cache por los navegadores, algunas configuraciones de cache agresivas o los service workers pueden interferir.

Prueba abriendo una ventana en modo incognito o navegacion privada. Si el carrito funciona correctamente en modo incognito, el problema esta relacionado con la cache del navegador. Indica al cliente que limpie la cache de su navegador, o mas precisamente, que intente una recarga forzada con Ctrl+Shift+R (Windows/Linux) o Cmd+Shift+R (Mac).

Si tu tema de PrestaShop utiliza un service worker para funcionalidad de aplicacion web progresiva (PWA), el service worker podria estar interceptando y almacenando en cache las solicitudes AJAX. Revisa la pestana Aplicacion en las Herramientas para Desarrolladores, luego Service Workers, para ver si hay alguno registrado. Desregistralo temporalmente para comprobar si esta causando el problema.

Los archivos JavaScript estaticos tambien pueden estar almacenados en cache. Si recientemente actualizaste un modulo que modifica el comportamiento del carrito, el navegador del cliente podria seguir usando el archivo JavaScript antiguo. PrestaShop anade una cadena de consulta de version a las URL de JavaScript (como cart.js?v=1.0.0), pero esto solo funciona si el modulo incrementa correctamente su numero de version durante la actualizacion.

Conflictos con la cache de Smarty

PrestaShop utiliza el motor de plantillas Smarty para renderizar HTML en el lado del servidor. Smarty tiene su propio sistema de compilacion y cache que puede servir salida de plantillas obsoleta.

Si las plantillas relacionadas con el carrito fueron modificadas (por una actualizacion del tema, instalacion de un modulo o edicion manual) pero la cache de Smarty no fue limpiada, la plantilla antigua sigue sirviendose. Las plantillas compiladas se almacenan en /var/cache/prod/smarty/compile/ y la salida en cache en /var/cache/prod/smarty/cache/. Eliminar el contenido de ambos directorios obliga a Smarty a recompilar todas las plantillas desde los archivos fuente actuales.

Tambien puedes limpiar la cache de Smarty desde el back office. Ve a Parametros avanzados, luego Rendimiento, y haz clic en el boton "Limpiar cache". En PrestaShop 8.x, tambien puedes usar el boton "Limpiar cache de Symfony" que limpia tanto la cache del contenedor Symfony como la cache de Smarty.

Un problema de Smarty mas sutil involucra las configuraciones de "Forzar compilacion" y "Cache" en Parametros avanzados, Rendimiento, Smarty. Durante el desarrollo o la depuracion, establece la Compilacion de plantillas en "Forzar compilacion" y Cache en "No". Esto asegura que cada carga de pagina utilice los archivos de plantilla mas recientes. Recuerda restaurar estas configuraciones a "Recompilar plantillas si los archivos han sido modificados" y "Si" despues de la depuracion, ya que la compilacion forzada afecta significativamente el rendimiento.

Configuracion CCC y su impacto

La funcion CCC (Combinar, Comprimir, Cache) de PrestaShop, ubicada en Parametros avanzados, Rendimiento, fusiona y minifica archivos CSS y JavaScript para mejorar los tiempos de carga de la pagina. Aunque es beneficiosa para el rendimiento, el CCC puede causar problemas en el carrito de varias maneras.

Cuando el CCC esta habilitado, PrestaShop combina multiples archivos JavaScript en un unico archivo en cache. Si el JavaScript de un modulo depende del orden de carga (debe ejecutarse despues de jQuery pero antes del codigo de otro modulo), el proceso de combinacion puede reordenar los archivos incorrectamente, causando que el codigo dependiente falle.

El CCC tambien almacena en cache los archivos combinados de manera agresiva. Despues de instalar, actualizar o eliminar un modulo, el antiguo archivo combinado puede seguir sirviendose. La solucion es limpiar manualmente la cache CCC yendo a Parametros avanzados, Rendimiento, y haciendo clic en "Limpiar cache" o eliminando los archivos en cache en /themes/tu_tema/cache/.

Un problema CCC particularmente frustrante ocurre cuando el archivo JavaScript de un modulo contiene un error de sintaxis. Cuando el CCC lo combina con otros archivos, el error de sintaxis rompe todo el paquete JavaScript combinado, deshabilitando toda la funcionalidad JavaScript de la pagina, incluido el carrito. Sin CCC, solo el JavaScript de ese unico modulo fallaria mientras el resto seguiria funcionando. Desactivar temporalmente el CCC puede ayudar a aislar este tipo de problema.

Para comprobar si el CCC esta causando tu problema con el carrito, desactiva las tres opciones CCC (Smart cache para CSS, Smart cache para JavaScript y optimizacion Apache) en la configuracion de Rendimiento. Limpia todas las caches. Si el carrito empieza a funcionar, reactiva las opciones una por una para identificar cual causa el conflicto.

Problemas de cache del CDN

Si tu tienda PrestaShop utiliza un CDN (Red de Distribucion de Contenido) como Cloudflare, KeyCDN o CloudFront, el CDN podria estar almacenando en cache respuestas que no deberian almacenarse. Los CDN estan disenados para almacenar contenido estatico, pero las configuraciones incorrectas pueden hacer que almacenen respuestas AJAX dinamicas o paginas dependientes de la sesion.

Cloudflare en particular es conocido por almacenar en cache las respuestas a solicitudes POST cuando ciertas reglas de pagina o reglas de cache-everything estan configuradas de manera demasiado amplia. El endpoint AJAX del carrito devuelve datos especificos del cliente que nunca deben ser almacenados en cache por un CDN.

Para comprobar si el CDN esta involucrado, desactivalo temporalmente. En Cloudflare, puedes pausar el CDN o agregar una regla de pagina para evitar la cache en todo tu dominio temporalmente. Si el carrito funciona correctamente sin el CDN, revisa tus reglas de cache para asegurarte de que los endpoints AJAX y las paginas dinamicas esten excluidos del almacenamiento en cache.

Para Cloudflare especificamente, asegurate de que la regla de pagina "Cache Everything" no cubra todo tu dominio. Si debes usarla, agrega una regla con mayor prioridad que evite la cache para URL que contengan controller=cart, ajax=true y la ruta del checkout. Tambien verifica que el "Browser Cache TTL" no este configurado demasiado alto para los activos dinamicos.

Problemas de cookies y sesiones

PrestaShop utiliza cookies para mantener la sesion de compra, incluido el carrito. Si las cookies no funcionan correctamente, el carrito no puede persistir entre solicitudes. Cada actualizacion AJAX del carrito crea una nueva sesion en lugar de actualizar la existente, resultando en un carrito que aparece vacio despues de cada carga de pagina.

Los problemas comunes de cookies incluyen: el dominio de la cookie esta mal configurado (la cookie esta establecida para www.ejemplo.com pero la solicitud AJAX va a ejemplo.com sin el prefijo www, o viceversa), la ruta de la cookie es incorrecta, el atributo SameSite esta configurado como Strict lo que bloquea las cookies en ciertos escenarios cross-origin, o la cookie es demasiado grande y esta siendo rechazada por el navegador (los navegadores tipicamente limitan el tamano de las cookies a 4KB).

Revisa las cookies en la pestana Aplicacion de las Herramientas para Desarrolladores. Busca la cookie de sesion de PrestaShop (llamada PrestaShop-[hash] en las versiones mas recientes). Verifica que tenga el dominio y la ruta correctos, y que se este enviando con las solicitudes AJAX (revisa el encabezado Cookie en la pestana Red para la solicitud AJAX del carrito).

En configuraciones multi-dominio o multi-tienda, los problemas de cookies son especialmente comunes. Si la tienda es accesible tanto por http como por https, o tanto con www como sin www, la cookie podria no compartirse entre estas variaciones. Asegurate de que tu tienda use una unica URL canonica y que todas las demas variaciones redirijan a ella.

Los problemas con el certificado SSL tambien pueden impedir el funcionamiento de las cookies. Si el flag Secure esta establecido en la cookie pero la pagina se carga por HTTP (o contenido mixto), el navegador no enviara la cookie. Asegurate de que toda tu tienda se sirva por HTTPS de manera consistente.

Conflictos entre modulos: proceso de diagnostico

Los conflictos entre modulos son la causa mas comun de problemas con el carrito en PrestaShop. Dos o mas modulos pueden engancharse a los mismos eventos del carrito e interferir entre si, o un unico modulo puede tener un error que corrompe la respuesta del carrito.

El enfoque sistematico para diagnosticar conflictos entre modulos implica desactivar modulos en grupos. Comienza desactivando todos los modulos de terceros (mantiene activos los modulos nativos de PrestaShop). Si el carrito funciona, reactiva los modulos en grupos de 5. Cuando el problema reaparece, has reducido el campo a 5 modulos. Desactiva esos 5 y reactivalos uno por uno para encontrar al culpable exacto.

Presta especial atencion a los modulos que se enganchan a estos hooks de PrestaShop, ya que afectan directamente al comportamiento del carrito: actionCartSave, actionCartUpdate, displayShoppingCart, displayShoppingCartFooter, actionBeforeCartUpdateQty, actionAfterCartUpdateQty, displayHeader (los modulos que agregan JavaScript aqui pueden entrar en conflicto con el JS del carrito), y actionFrontControllerSetMedia.

Para ver que modulos estan registrados en los hooks relacionados con el carrito, consulta la base de datos:

SELECT h.name, m.name FROM ps_hook_module hm JOIN ps_hook h ON h.id_hook = hm.id_hook JOIN ps_module m ON m.id_module = hm.id_module WHERE h.name LIKE '%cart%' ORDER BY h.name, hm.position;

Esta consulta lista todos los modulos enganchados a hooks relacionados con el carrito, junto con su orden de ejecucion. Los conflictos a menudo surgen cuando dos modulos intentan modificar el total del carrito o aplicar descuentos de maneras incompatibles.

Depuracion con las Herramientas para Desarrolladores del navegador: guia detallada paso a paso

Las Herramientas para Desarrolladores del navegador son tu arma mas poderosa para diagnosticar problemas del carrito. Aqui tienes una guia detallada paso a paso sobre como usarlas eficazmente.

Paso 1: Abre las Herramientas para Desarrolladores y ve a la pestana Consola. Limpia todos los mensajes existentes. Recarga la pagina del producto. Toma nota de cualquier error o advertencia que aparezca. Estos son problemas preexistentes que pueden estar relacionados o no con el problema del carrito, pero deben ser documentados.

Paso 2: Ve a la pestana Red. Marca la casilla "Preservar registro" para que las solicitudes no se borren al navegar. Filtra por "XHR" o "Fetch" para ver solo las solicitudes AJAX. Haz clic en el boton Anadir al carrito.

Paso 3: Examina la solicitud AJAX. Haz clic en la solicitud del carrito que aparece. En la sub-pestana Encabezados, verifica que la URL de la solicitud sea correcta y que el Codigo de estado sea 200. En la sub-pestana Carga util de la solicitud o Datos del formulario, verifica que se esten enviando el ID de producto, la cantidad y la combinacion de atributos correctos.

Paso 4: Revisa la respuesta. Cambia a la sub-pestana Respuesta o Vista previa. La respuesta deberia ser JSON valido. Si ves HTML mezclado, se esta generando un error o advertencia PHP. Si la respuesta esta vacia, el procesamiento del lado del servidor se bloqueo antes de generar la salida. Si el JSON es valido pero contiene mensajes de error, leelos para obtener pistas.

Paso 5: Revisa la Consola despues de la respuesta AJAX. Los errores de JavaScript que ocurren durante el procesamiento de la respuesta AJAX apareceran en la Consola despues de que se complete la solicitud de red. Estos errores indican que la respuesta fue recibida pero no pudo ser procesada correctamente por el JavaScript del front-end.

Consideraciones especificas de PrestaShop 8.x

PrestaShop 8.x utiliza una arquitectura front-end significativamente actualizada en comparacion con la 1.7. El JavaScript del carrito ha sido refactorizado, y parte del codigo que antes dependia de jQuery ahora utiliza JavaScript nativo o metodos jQuery actualizados. Los modulos escritos para PrestaShop 1.7 que manipulan directamente el DOM del carrito pueden fallar en la 8.x porque la estructura HTML y los nombres de las clases CSS han cambiado.

La integracion de Symfony en PrestaShop 8.x tambien significa que la limpieza de la cache es mas compleja. La cache del contenedor Symfony, ubicada en /var/cache/prod/ y /var/cache/dev/, puede contener definiciones de servicios compiladas y mapeos de rutas que afectan como los controladores del carrito procesan las solicitudes. Limpiar solo la cache de Smarty no es suficiente; tambien debes limpiar la cache de Symfony.

PrestaShop 8.x tambien introdujo encabezados Content Security Policy (CSP) mas estrictos en algunas configuraciones. Si tu servidor o un modulo de seguridad agrega encabezados CSP que restringen el JavaScript en linea o las solicitudes AJAX a dominios especificos, las llamadas AJAX del carrito podrian ser bloqueadas. Revisa la Consola para buscar mensajes de violacion CSP, que aparecen como errores rojos que mencionan "Content Security Policy".

Problemas del lado del servidor: sesiones PHP y configuracion

La configuracion de sesiones PHP puede causar problemas del carrito dificiles de diagnosticar porque aparecen de forma intermitente. Si el directorio de almacenamiento de sesiones esta lleno, tiene permisos incorrectos o esta en un sistema de archivos que no soporta bloqueo de archivos, las sesiones pueden perderse o corromperse entre solicitudes.

Verifica tu configuracion de sesiones PHP: session.save_path debe apuntar a un directorio con permisos de escritura y espacio en disco suficiente. session.gc_maxlifetime controla cuanto tiempo se mantienen las sesiones; si esta configurado demasiado bajo, los clientes pierden sus carritos durante sesiones de navegacion prolongadas. session.cookie_lifetime deberia igualar o superar el valor de gc_maxlifetime.

En hosting compartido con muchos sitios, el directorio de sesiones puede contener millones de archivos de todos los sitios alojados, haciendo lento el acceso a los archivos de sesion. Si tu proveedor de hosting lo permite, configura un directorio de sesiones por sitio o utiliza sesiones basadas en base de datos.

Para tiendas que usan multiples servidores web detras de un balanceador de carga, las sesiones deben compartirse entre servidores. Si el almacenamiento de sesiones es basado en archivos y local a cada servidor, la solicitud siguiente de un cliente puede llegar a un servidor diferente que no tiene su sesion, resultando en un carrito vacio. Usa un almacen de sesiones compartido como Redis, Memcached o sesiones en base de datos en entornos con balanceo de carga.

Lista de verificacion de diagnostico paso a paso

Cuando un cliente reporta que el carrito no se actualiza, sigue esta lista de verificacion en orden:

1. Reproduce el problema. Intenta replicar el problema en una ventana de incognito usando el mismo producto y navegador que reporto el cliente. Si no puedes reproducirlo, pide al cliente su version de navegador, tipo de dispositivo y los pasos exactos.

2. Revisa la consola del navegador en busca de errores JavaScript. Cualquier mensaje de error en rojo es potencialmente la causa, incluso si parece no estar relacionado con el carrito.

3. Revisa la solicitud de red. Verifica que la solicitud AJAX se envie, devuelva un estado 200 y contenga JSON valido.

4. Limpia todas las caches: cache de compilacion de Smarty, cache de Smarty, cache de Symfony, cache CCC, OPcache y cache del CDN si aplica.

5. Desactiva el CCC. Si el carrito funciona con el CCC desactivado, un error en la combinacion de JavaScript es la causa.

6. Prueba con el tema predeterminado. Cambia temporalmente al tema predeterminado Classic de PrestaShop. Si el carrito funciona con el tema predeterminado, el problema esta en el JavaScript o las plantillas de tu tema personalizado.

7. Desactiva los modulos de terceros. Si el carrito funciona con todos los modulos de terceros desactivados, usa el metodo de busqueda binaria para identificar el modulo en conflicto.

8. Revisa los logs de errores PHP. Los errores del lado del servidor que no llegan al navegador se registran aqui.

9. Verifica la configuracion de cookies y sesiones. Revisa la cookie de sesion en las Herramientas para Desarrolladores y verifica la configuracion de sesiones PHP en el servidor.

10. Prueba en un dispositivo y red diferentes. Esto elimina problemas locales del navegador, proxies de red y problemas de compatibilidad JavaScript especificos del dispositivo como posibles causas.

Leer respuesta completa

Por que importan los logs de errores de PrestaShop

Toda tienda PrestaShop genera errores. Algunos son avisos inofensivos que nunca afectan a tus clientes. Otros son fallos criticos que detienen por completo tu proceso de pago. La diferencia entre un propietario de tienda que pasa dias esperando soporte y uno que resuelve problemas en minutos a menudo se reduce a una sola habilidad: saber leer los logs de errores.

Los logs de errores son la salida diagnostica de tu servidor y de tu aplicacion PrestaShop. Registran cada error PHP, cada consulta de base de datos fallida, cada problema de permisos y cada excepcion no controlada. Cuando algo sale mal, la respuesta casi siempre esta en un archivo de log. El desafio esta en saber donde buscar, que buscar y como interpretar lo que encuentras.

Esta guia cubre el panorama completo del registro de errores en PrestaShop. Aprenderas donde se encuentra cada tipo de log, como habilitar la generacion detallada de informes de errores, como leer los stack traces y como usar herramientas de linea de comandos para encontrar la aguja en el pajar. Ya sea que estes depurando una pantalla blanca de la muerte o rastreando un fallo intermitente en el proceso de pago, este es el conocimiento que necesitas.

Donde se encuentran los logs de PrestaShop

PrestaShop genera logs a multiples niveles, y cada nivel tiene sus propios archivos de log. Entender cual log revisar primero ahorra enormes cantidades de tiempo.

Logs de la aplicacion PrestaShop (var/logs)

A partir de PrestaShop 1.7, la aplicacion utiliza el framework Symfony para su back office y el enrutamiento principal. Symfony escribe sus propios logs en el directorio var/logs/ en la raiz de PrestaShop. Encontraras archivos nombrados segun el entorno actual:

var/logs/dev.log contiene los logs cuando PrestaShop se ejecuta en modo desarrollo. Este archivo es extremadamente detallado y registra todo, desde decisiones de enrutamiento hasta consultas de base de datos. Puede crecer a cientos de megabytes rapidamente.

var/logs/prod.log contiene los logs del modo produccion. Este archivo es mucho menos detallado por defecto, registrando solo advertencias y errores. Este es el archivo que deberias revisar primero cuando algo se rompe en una tienda en produccion.

Estos archivos de log siguen el formato Monolog, que es la libreria de logging estandar en Symfony. Cada linea incluye una marca de tiempo, el canal del log (como request, security o doctrine), el nivel de gravedad y el mensaje. Una entrada tipica se ve asi:

[2024-03-15 14:22:33] request.CRITICAL: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\NotFoundHttpException: "No route found for GET /admin/nonexistent" at /var/www/html/vendor/symfony/http-kernel/EventListener/RouterListener.php line 136

Los niveles de gravedad, del menos al mas severo, son: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT y EMERGENCY. Al resolver problemas, filtra primero por ERROR y CRITICAL.

Log de errores PHP

PHP mismo mantiene un log de errores separado de los logs de la aplicacion PrestaShop. Este log captura errores que ocurren antes de que el framework de logging de PrestaShop se inicialice, o errores en codigo que no utiliza el logger de Symfony. La ubicacion de este archivo depende de la configuracion de tu servidor.

En la mayoria de los servidores Linux con Apache, el log de errores PHP se encuentra en /var/log/php_errors.log o /var/log/php/error.log. En hosting compartido con cPanel, a menudo esta en /home/nombreusuario/logs/error.log o en el directorio public_html como error_log.

Puedes encontrar la ubicacion exacta revisando tu configuracion PHP. Crea un archivo PHP temporal con phpinfo(); y busca la directiva error_log. Alternativamente, ejecuta php -i | grep error_log desde la linea de comandos.

Los logs de errores PHP capturan errores fatales, errores de parseo, advertencias y avisos. Una entrada de error fatal tipicamente se ve asi:

[15-Mar-2024 14:22:33 UTC] PHP Fatal error: Uncaught Error: Class 'SomeModule\SomeClass' not found in /var/www/html/modules/somemodule/somemodule.php:45

Logs del servidor web (Apache y Nginx)

Tu servidor web mantiene su propio conjunto de logs independientes de PHP y PrestaShop. Estos logs son esenciales para diagnosticar errores 500, errores 404 y problemas de rendimiento.

Los logs de Apache se encuentran tipicamente en:

/var/log/apache2/error.log para el log de errores en sistemas Debian y Ubuntu.
/var/log/httpd/error_log para el log de errores en sistemas CentOS y RHEL.
/var/log/apache2/access.log para el log de accesos, que registra cada solicitud HTTP.

Los logs de Nginx se encuentran tipicamente en:

/var/log/nginx/error.log para el log de errores.
/var/log/nginx/access.log para el log de accesos.

Si tu sitio utiliza una configuracion de virtual host, los logs podrian estar en una ubicacion especifica del sitio definida por la directiva ErrorLog (Apache) o error_log (Nginx) en tu archivo de virtual host.

Los logs de errores del servidor web capturan problemas como errores de permiso denegado cuando PHP intenta escribir en un directorio, errores de sintaxis en la configuracion despues de un cambio en .htaccess, y errores de timeout del proxy si estas ejecutando PHP-FPM detras de Nginx. Estos son los logs que debes revisar cuando ves un error generico 500 Internal Server Error sin detalles en los logs de PHP o PrestaShop.

Logs legacy de PrestaShop (Back Office)

PrestaShop tambien mantiene un visor de logs dentro del back office en Parametros avanzados > Logs. Esta interfaz muestra las entradas de log almacenadas en la tabla de base de datos ps_log. Estos logs capturan eventos que PrestaShop registra explicitamente, como intentos de inicio de sesion fallidos, errores de instalacion de modulos y fallos en el envio de correos electronicos.

Aunque el visor de logs del back office es conveniente, tiene limitaciones significativas. No captura errores PHP, errores del servidor web, ni la mayoria de los errores fatales que impiden que la pagina se cargue. Consideralo un complemento de los logs basados en archivos, no un reemplazo.

Habilitar el modo debug en PrestaShop

Por defecto, PrestaShop se ejecuta en modo produccion y oculta los mensajes de error detallados a los visitantes. Esto es correcto para una tienda en produccion, pero hace que la depuracion sea casi imposible. Cuando algo se rompe, tu primer paso deberia ser habilitar el modo debug.

Metodo 1: el archivo defines.inc.php

Abre el archivo config/defines.inc.php y busca la linea que establece _PS_MODE_DEV_. Cambiala de false a true:

define('_PS_MODE_DEV_', true);

Este unico cambio tiene varios efectos. El reporte de errores PHP se establece en su nivel maximo, mostrando todos los errores, advertencias y avisos. El almacenamiento en cache de plantillas Smarty se desactiva, por lo que los cambios en las plantillas aparecen inmediatamente. La barra del profiler de Symfony aparece en la parte inferior de las paginas del back office. Y lo mas importante, los detalles de los errores se muestran en pantalla en lugar de mostrar una pagina de error generica.

Metodo 2: el modo Debug Profiling

Para un analisis mas profundo, tambien puedes habilitar el profiling. En el mismo archivo, establece:

define('_PS_DEBUG_PROFILING_', true);

Esto agrega informacion detallada de tiempos y uso de memoria al final de cada pagina, mostrandote que hooks toman mas tiempo, que modulos consumen mas memoria y cuantas consultas de base de datos genera cada pagina. Esto es invaluable para la depuracion de rendimiento pero nunca debe dejarse activado en produccion.

Advertencia de seguridad

El modo debug expone informacion sensible incluyendo rutas de archivos, credenciales de base de datos en los stack traces y la estructura interna de la aplicacion. Nunca dejes el modo debug habilitado en una tienda en produccion accesible al publico. Si necesitas depurar una tienda en produccion, considera restringir el modo debug a tu direccion IP envolviendo el define en una verificacion de IP, o utiliza un entorno de staging.

Leer stack traces

Cuando PrestaShop encuentra un error fatal o una excepcion no controlada en modo debug, muestra un stack trace. Un stack trace es una instantanea de la cadena de llamadas que condujo al error, que se lee desde el punto de fallo hasta el punto de entrada original. Aprender a leer stack traces es la habilidad de depuracion mas valiosa que puedes desarrollar.

Anatomia de un stack trace

Un stack trace tipico de PrestaShop se ve asi:

PHP Fatal error: Uncaught TypeError: Argument 1 passed to Product::getProductProperties() must be of the type int, null given, called in /var/www/html/classes/Product.php on line 4523

Stack trace: #0 /var/www/html/classes/Product.php(4523): Product::getProductProperties(NULL, Array) #1 /var/www/html/modules/somemodule/somemodule.php(127): Product::getProductProperties(1, Array) #2 /var/www/html/classes/Hook.php(523): SomeModule->hookDisplayHome(Array) #3 /var/www/html/classes/Hook.php(460): Hook::coreCallHook(Object(SomeModule), 'hookDisplayHome', Array) #4 /var/www/html/classes/Hook.php(408): Hook::exec('displayHome', Array)

Lee el stack trace de arriba hacia abajo. La primera linea te dice que salio mal: una funcion esperaba un entero pero recibio null. La linea #0 te dice donde ocurrio el error. La linea #1 te dice que llamo al codigo en #0. La linea #2 te dice que llamo a #1, y asi sucesivamente.

En este ejemplo, la cadena es clara: PrestaShop ejecuto el hook displayHome, que llamo al metodo hookDisplayHome en SomeModule, que llamo a Product::getProductProperties() con un valor null donde se esperaba un entero. El error esta en el modulo en la linea 127, donde pasa un valor incorrecto.

Encontrar el frame relevante

Los stack traces en PrestaShop pueden ser largos, a veces de 20 o 30 frames de profundidad. La clave es encontrar el frame que contiene tu codigo o el modulo que causa el problema. Busca rutas que contengan /modules/ o /themes/ porque estas son las fuentes mas probables de bugs. Los frames que hacen referencia a /classes/, /src/ o /vendor/ son codigo del nucleo de PrestaShop o librerias de terceros, que tienen menos probabilidad de ser la fuente del problema a menos que hayas modificado archivos del nucleo.

Patrones de error comunes en PrestaShop

Despues de leer miles de logs de errores de PrestaShop, ciertos patrones emergen repetidamente. Reconocer estos patrones te permite diagnosticar problemas en segundos en lugar de horas.

Errores Class Not Found

PHP Fatal error: Uncaught Error: Class 'ModuleName\ClassName' not found

Esto significa que el autoloader no puede encontrar la clase especificada. Las causas comunes incluyen: un archivo vendor/autoload.php faltante (el modulo necesita composer install), una declaracion de namespace que no coincide, un archivo que no fue incluido en el ZIP del modulo durante la instalacion, o un problema de sensibilidad a mayusculas y minusculas en servidores Linux donde ClassName.php y classname.php son archivos diferentes.

Errores Permission Denied

Warning: file_put_contents(/var/www/html/var/cache/prod/some_file): failed to open stream: Permission denied

Estos ocurren cuando el usuario del servidor web (generalmente www-data en Debian/Ubuntu o apache en CentOS) no tiene permisos de escritura sobre un archivo o directorio. Corrigelo ajustando la propiedad: chown -R www-data:www-data var/cache/ y los permisos: chmod -R 775 var/cache/.

Errores de limite de memoria

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65536 bytes)

El numero 134217728 bytes equivale a 128MB, que es el limite de memoria PHP predeterminado. PrestaShop recomienda al menos 256MB. Aumentalo en tu archivo php.ini: memory_limit = 512M. Si el error persiste incluso con limites de memoria altos, el codigo probablemente tiene una fuga de memoria, a menudo causada por cargar demasiados productos o categorias en una sola consulta sin paginacion.

Errores de conexion a la base de datos

Link to database cannot be established: SQLSTATE[HY000] [2002] Connection refused

Esto significa que PrestaShop no puede conectarse al servidor MySQL. Verifica que el servidor de base de datos este en ejecucion, que las credenciales en app/config/parameters.php sean correctas y que el host de la base de datos sea accesible desde el servidor web.

Errores de plantillas Smarty

SmartyException: Unable to load template file 'module:somemodule/views/templates/hook/display.tpl'

El archivo de plantilla falta, esta mal escrito o esta en el directorio equivocado. Verifica que el archivo exista en la ruta esperada y que el nombre del archivo coincida exactamente, incluyendo mayusculas y minusculas.

Errores de token CSRF

Invalid token. Please try to log in again.

Esto aparece en el back office cuando el envio de un formulario incluye un token de seguridad caducado o faltante. Tipicamente ocurre cuando una sesion expira durante una larga sesion de edicion, cuando multiples pestanas estan abiertas en la misma pagina de administracion, o cuando un modulo genera sus URLs de formulario incorrectamente.

Usar grep para encontrar errores

Cuando los archivos de log son grandes, desplazarse por ellos manualmente es poco practico. El comando grep es tu mejor aliado para encontrar rapidamente las entradas relevantes.

Busqueda basica de errores

Para encontrar todos los errores fatales en el log de errores PHP:

grep 'Fatal error' /var/log/php_errors.log

Para encontrar errores de un modulo especifico:

grep 'somemodule' /var/www/html/var/logs/prod.log

Para encontrar errores solo de hoy (asumiendo el formato de fecha en el log):

grep '2024-03-15' /var/www/html/var/logs/prod.log | grep 'ERROR\|CRITICAL'

Filtrado avanzado

Para ver errores con contexto circundante (3 lineas antes y despues de cada coincidencia):

grep -C 3 'Fatal error' /var/log/php_errors.log

Para contar cuantas veces ocurre cada error unico:

grep 'Fatal error' /var/log/php_errors.log | sort | uniq -c | sort -rn | head -20

Esta pipeline ordena los errores, cuenta los duplicados, ordena por recuento en orden descendente y muestra los 20 primeros. Esto es increiblemente util para identificar los errores mas frecuentes que necesitan atencion prioritaria.

Para buscar en multiples archivos de log simultaneamente:

grep -r 'Fatal error' /var/log/ --include='*.log'

El flag -r busca recursivamente y --include limita la busqueda a archivos con extension .log.

Monitoreo de logs en tiempo real con tail -f

Cuando estas depurando activamente un problema, necesitas ver los errores en el momento en que ocurren. El comando tail -f sigue un archivo de log en tiempo real, mostrando nuevas entradas a medida que se escriben.

Monitoreo basico en tiempo real

Para monitorear el log de produccion de PrestaShop en tiempo real:

tail -f /var/www/html/var/logs/prod.log

Para monitorear el log de errores PHP:

tail -f /var/log/php_errors.log

Para monitorear multiples archivos de log a la vez:

tail -f /var/www/html/var/logs/prod.log /var/log/php_errors.log /var/log/apache2/error.log

Monitoreo filtrado en tiempo real

Para monitorear solo las entradas de nivel error en tiempo real, combina tail con grep:

tail -f /var/www/html/var/logs/prod.log | grep --line-buffered 'ERROR\|CRITICAL'

El flag --line-buffered es importante aqui. Sin el, grep almacena en buffer su salida y podrias no ver las coincidencias inmediatamente.

Para resaltar palabras clave especificas mientras muestras toda la salida:

tail -f /var/www/html/var/logs/prod.log | grep --color=always -E 'ERROR|CRITICAL|$'

Esto resalta ERROR y CRITICAL en color mientras sigue mostrando todas las lineas.

El flujo de trabajo de depuracion

El flujo de trabajo de depuracion mas efectivo combina el monitoreo en tiempo real con las pruebas activas. Abre una ventana de terminal con tail -f ejecutandose sobre los archivos de log relevantes. En tu navegador, reproduce la accion que causa el error. Observa el terminal para las nuevas entradas de log que aparecen en el momento exacto en que activas el problema. Este enfoque elimina las conjeturas y te muestra precisamente que sucede cuando ocurre el error.

Rotacion y gestion de logs

Los archivos de log crecen continuamente y pueden consumir todo el espacio en disco disponible si se dejan sin gestion. La mayoria de los servidores Linux utilizan logrotate para gestionar esto automaticamente, pero los propios logs de PrestaShop en var/logs/ podrian no estar incluidos en la configuracion predeterminada de logrotate.

Entender Logrotate

La utilidad logrotate se ejecuta diariamente (generalmente via cron) y gestiona la rotacion, compresion y eliminacion de archivos de log. Los archivos de configuracion se encuentran en /etc/logrotate.d/. La rotacion de logs de Apache y Nginx esta tipicamente configurada por defecto.

Para el directorio var/logs de PrestaShop, podrias necesitar crear una configuracion personalizada de logrotate:

/var/www/html/var/logs/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 www-data www-data }

Esta configuracion rota los logs diariamente, mantiene 14 dias de historial, comprime los logs antiguos y crea nuevos archivos de log con los permisos correctos.

Limpieza manual de logs

Si un archivo de log ha crecido excesivamente y necesitas vaciarlo sin perder el descriptor de archivo (importante si un proceso esta escribiendo activamente en el):

truncate -s 0 /var/www/html/var/logs/prod.log

No elimines el archivo y lo recrees, porque cualquier proceso que tenga el archivo abierto continuara escribiendo en el inodo del archivo eliminado hasta que se reinicie. El enfoque con truncate vacia los contenidos mientras preserva el inodo.

Entender los contextos de error especificos de PrestaShop

Los errores de PrestaShop a menudo vienen con un contexto unico de la plataforma. Entender este contexto te ayuda a localizar y corregir problemas mas rapido.

Errores relacionados con hooks

Cuando un error ocurre dentro de un hook, el stack trace incluira referencias a Hook::exec() y Hook::coreCallHook(). El nombre del hook te dice exactamente en que momento del proceso de renderizado de la pagina ocurre el error. Por ejemplo, los errores de displayHome ocurren en la pagina de inicio, los errores de actionValidateOrder ocurren durante el proceso de pago, y los errores de displayBackOfficeHeader ocurren al cargar cualquier pagina del back office.

Si un error en un hook hace que una pagina falle, puedes desactivar temporalmente el modulo responsable desde la base de datos:

UPDATE ps_module SET active = 0 WHERE name = 'somemodule';

Esto te permite acceder al back office para diagnosticar y corregir el problema adecuadamente.

Conflictos de overrides

El sistema de overrides de PrestaShop permite a los modulos extender las clases del nucleo, pero surgen conflictos cuando dos modulos hacen override de la misma clase. El error tipicamente aparece como un conflicto en la firma del metodo o un cambio de comportamiento inesperado. Revisa el directorio override/ para ver que overrides estan activos, y revisa el archivo cache/class_index.php que mapea las clases a sus archivos de override. Eliminar este archivo de cache obliga a PrestaShop a regenerar el mapa de overrides.

Errores relacionados con la cache

Muchos errores de PrestaShop son causados por archivos de cache obsoletos. Si ves errores que no coinciden con el codigo actual (por ejemplo, un error que hace referencia a un numero de linea que no existe en el archivo), la cache probablemente esta desactualizada. Limpiala eliminando el contenido de var/cache/prod/ y var/cache/dev/. En PrestaShop 1.6, limpia cache/smarty/compile/ y cache/smarty/cache/ en su lugar.

Errores de instalacion y actualizacion de modulos

Las instalaciones de modulos pueden fallar silenciosamente, dejando el modulo en un estado parcialmente instalado. Revisa var/logs/prod.log para las entradas durante la marca de tiempo de la instalacion. Los problemas comunes incluyen tablas de base de datos faltantes (el SQL del metodo install() del modulo fallo), hooks faltantes (la llamada registerHook() fallo) y errores de entrada duplicada en la tabla ps_authorization_role al reinstalar un modulo que no fue completamente desinstalado.

Construir una lista de verificacion de depuracion

Cuando encuentras un error en PrestaShop, sigue esta lista de verificacion sistematica para encontrar la causa eficientemente:

Primero, identifica el tipo de error. Es una pantalla blanca (error 500), un mensaje de error especifico, un diseno roto o un comportamiento inesperado? Cada tipo apunta a archivos de log diferentes.

Segundo, revisa primero el log mas especifico. Para errores PHP, revisa el log de errores PHP. Para errores HTTP, revisa el log de errores del servidor web. Para errores de la aplicacion, revisa var/logs/prod.log.

Tercero, habilita el modo debug si los logs no revelan informacion suficiente. Cambia _PS_MODE_DEV_ a true y reproduce el error.

Cuarto, usa tail -f en los logs relevantes y reproduce el error en tu navegador. Esto te da una vista en tiempo real de exactamente lo que sucede.

Quinto, lee el stack trace de arriba hacia abajo. Encuentra el frame que hace referencia al codigo de tu modulo o tema. Ahi es donde debe aplicarse la correccion.

Sexto, busca el mensaje de error en los issues de GitHub de PrestaShop y en los foros. Es muy probable que alguien haya encontrado y resuelto el mismo problema antes.

Septimo, despues de aplicar una correccion, limpia todas las caches y monitorea los logs para confirmar que el error ha desaparecido. Una correccion que no produce un log limpio no es una correccion completa.

Resumen

Leer los logs de errores de PrestaShop no es un arte misterioso reservado para desarrolladores senior. Es una habilidad practica construida sobre saber donde se encuentran los logs, como filtrarlos y como interpretar lo que contienen. Los logs en var/logs/, el log de errores PHP y el log del servidor web sirven cada uno un proposito diferente y juntos proporcionan una imagen completa de cualquier problema. Habilitar el modo debug te proporciona mensajes de error detallados. Los stack traces te muestran la cadena exacta de llamadas de funcion que condujeron al fallo. Herramientas como grep y tail -f hacen posible encontrar y monitorear errores eficientemente incluso en archivos de log grandes y con mucha actividad. Domina estas tecnicas y resolveras problemas mas rapido, con menos frustracion y con mucha menos dependencia del soporte externo.

Leer respuesta completa

Entender los códigos de error HTTP en PrestaShop

Los códigos de error HTTP son respuestas estandarizadas de tu servidor web que indican que algo salió mal cuando un navegador o bot de motor de búsqueda intentó acceder a una página. Para los propietarios de tiendas PrestaShop, estos errores pueden significar ventas perdidas, clientes frustrados y posicionamientos SEO dañados.

Error 403 - Prohibido

Un error 403 significa que el servidor entendió tu solicitud pero se niega a autorizarla. Es típicamente un problema de permisos o control de acceso.

1. Permisos de archivos y directorios incorrectos

Los directorios deben estar en 755 y los archivos en 644.

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/html/prestashop

2. Reglas .htaccess bloqueando el acceso

Un archivo .htaccess demasiado restrictivo puede bloquear solicitudes legítimas.

3. ModSecurity o WAF bloqueando solicitudes

Los firewalls de aplicaciones web pueden producir falsos positivos.

Corregir errores 403

Verificar y corregir permisos de archivos
Revisar .htaccess para reglas demasiado restrictivas
Verificar registros de seguridad del hosting
Verificar que tu IP no esté en una lista negra

Error 404 - No encontrado

Un error 404 significa que el servidor no puede encontrar la página solicitada.

1. URLs amigables desactivadas o mal configuradas

Ve a Parámetros de la tienda > Tráfico y SEO, asegúrate de que las URLs amigables estén activadas y haz clic en Guardar. Verifica que mod_rewrite esté habilitado en tu servidor.

2. Productos o categorías eliminados sin redirecciones

Siempre configura redirecciones 301 al eliminar contenido.

3. .htaccess faltante o corrupto

Regenera el .htaccess desde Parámetros de la tienda > Tráfico y SEO.

Corregir errores 404

Verificar que .htaccess existe y está correctamente configurado
Verificar que mod_rewrite está habilitado
Regenerar el .htaccess
Configurar redirecciones 301
Verificar Google Search Console para errores de rastreo

Error 500 - Error interno del servidor

Un error 500 significa que algo salió mal en el lado del servidor.

1. Límite de memoria PHP excedido

memory_limit = 512M

2. Errores de sintaxis PHP o errores fatales

define('_PS_MODE_DEV_', true);

3. Incompatibilidad de versión PHP

PrestaShop	PHP Mínimo	PHP Recomendado
1.7.x	7.1	7.4
8.x	7.2	8.1
9.x	8.1	8.2+

4. Problemas de conexión a la base de datos

Verifica las credenciales en app/config/parameters.php.

5. Conflictos de módulos

mv modules/problematic_module modules/problematic_module_disabled

Corregir errores 500

Activar el modo debug
Verificar el registro de errores PHP
Aumentar el límite de memoria PHP
Verificar compatibilidad de versión PHP
Desactivar módulos instalados recientemente

Error 503 - Servicio no disponible

Un error 503 significa que el servidor no puede manejar la solicitud temporalmente.

1. Modo mantenimiento aún activo

UPDATE ps_configuration SET value = '0' WHERE name = 'PS_SHOP_ENABLE';

2. Sobrecarga del servidor

Mejorar el plan de hosting
Activar el caché de PrestaShop
Usar un CDN como Cloudflare
Activar OPcache para PHP

3. Agotamiento de workers PHP-FPM

pm = dynamic
pm.max_children = 50
pm.start_servers = 10

Corregir errores 503

Verificar y desactivar modo mantenimiento
Monitorear recursos del servidor
Verificar registros PHP-FPM
Revisar programación de tareas cron
Considerar mejorar el hosting

Consejos generales de depuración

Apache - /var/log/apache2/error.log
Nginx - /var/log/nginx/error.log
PHP-FPM - /var/log/php-fpm/error.log
PrestaShop - /var/logs/

Después de cada corrección, limpiar todas las cachés.

Leer respuesta completa

Cómo PrestaShop utiliza las cookies

Cada tienda PrestaShop depende de las cookies para funcionar. Mantienen las sesiones de los clientes, recuerdan el contenido del carrito, almacenan las preferencias de idioma y moneda, rastrean el estado de inicio de sesión y permiten al back office autenticar a los administradores. Sin cookies, una tienda PrestaShop no puede mantener el estado entre cargas de página, lo que significa que no hay carrito de compras, no hay inicio de sesión del cliente y no hay acceso al panel de administración.

PrestaShop utiliza dos cookies principales. La cookie del front office, típicamente nombrada según tu tienda (como PrestaShop-abc123), gestiona todo lo que necesita la parte orientada al cliente. La cookie del back office, con un patrón de nomenclatura similar pero un alcance diferente, gestiona la autenticación de los administradores. Ambas cookies almacenan datos serializados directamente en el valor de la cookie, una decisión de diseño que tiene implicaciones significativas para el rendimiento, la seguridad y el cumplimiento del RGPD.

Estructura y contenido de las cookies de PrestaShop

A diferencia de muchas aplicaciones web que almacenan solo un ID de sesión en la cookie y mantienen todos los datos de sesión en el servidor, PrestaShop almacena una cantidad sustancial de datos directamente en la propia cookie. La cookie del front office contiene campos que incluyen el ID del cliente, el nombre y correo electrónico del cliente, si el cliente está conectado, el ID del carrito, el idioma seleccionado, la moneda seleccionada, la última categoría visitada, el último producto visitado, el paso del proceso de compra y otra información de estado diversa.

Estos datos se serializan utilizando la clase de cookies propia de PrestaShop (Cookie.php en el directorio classes). El valor de la cookie se cifra utilizando una clave derivada de la constante _COOKIE_KEY_ en config/settings.inc.php (PrestaShop 1.6/1.7) o app/config/parameters.php (PrestaShop 8.x). Este cifrado previene la manipulación y protege datos sensibles como el ID del cliente y el correo electrónico de ser legibles en el navegador.

Por qué PrestaShop almacena datos en la cookie

La razón histórica de esta decisión de diseño es el rendimiento. Al almacenar datos de sesión en la cookie, PrestaShop evita una búsqueda de sesión del lado del servidor en cada solicitud. No hay necesidad de leer un archivo de sesión, consultar una base de datos ni conectarse a un servidor de sesiones. Los datos llegan con la solicitud, ya disponibles.

Sin embargo, este enfoque tiene desventajas que se vuelven más relevantes a medida que la tienda crece. El tamaño de la cookie aumenta con la cantidad de datos almacenados, y cada solicitud HTTP (incluyendo solicitudes de imágenes, CSS y archivos JavaScript) envía la cookie completa al servidor. Una cookie de 4 KB enviada con 30 solicitudes de recursos por carga de página significa 120 KB de ancho de banda de subida innecesario por carga de página. Esta sobrecarga es medible en conexiones móviles y a gran escala.

Tamaño de la cookie e impacto en el rendimiento

Las cookies del navegador tienen un límite práctico de tamaño de aproximadamente 4.096 bytes por cookie. La cookie del front office de PrestaShop puede acercarse o superar este límite, especialmente cuando los módulos añaden sus propios datos a la cookie a través de hookActionBeforeSubmitAccount o modificando directamente el objeto cookie.

Midiendo el impacto del tamaño de la cookie

Para ver cómo las cookies afectan al rendimiento de tu tienda, abre las herramientas de desarrollador del navegador y ve a la pestaña Red. Observa las cabeceras de solicitud de cualquier petición a tu dominio. La cabecera Cookie muestra todas las cookies enviadas. Fíjate en su tamaño. Ahora observa las cabeceras de solicitud de un recurso estático (una imagen o archivo CSS) en el mismo dominio. Las mismas cookies se envían con esa solicitud también, añadiendo sobrecarga sin razón.

Reduciendo la sobrecarga de cookies para recursos estáticos

La forma más efectiva de eliminar la sobrecarga de cookies para archivos estáticos es servirlos desde un dominio diferente (un dominio sin cookies). En PrestaShop, puedes configurar servidores de medios en el back office en Parámetros avanzados > Rendimiento. Cuando configuras un servidor de medios como static.tudominio.com, PrestaShop sirve imágenes, CSS y JavaScript desde ese dominio. Como las cookies son específicas del dominio, ninguna cookie se envía con las solicitudes al dominio de medios.

Alternativamente, un CDN como Cloudflare, Fastly o CloudFront puede servir tus recursos estáticos. Los servidores de borde del CDN típicamente eliminan las cookies de las respuestas en caché, por lo que aunque las cookies se envíen en la solicitud, la respuesta viene de la caché sin la sobrecarga de un viaje de ida y vuelta al servidor de origen.

Inflado de cookies por módulos

Los módulos de terceros a veces añaden datos a la cookie de PrestaShop sin considerar las implicaciones de tamaño. Cada módulo que almacena un valor en la cookie aumenta su tamaño y la sobrecarga en cada solicitud. Si tu cookie es inusualmente grande, verifica qué datos han añadido los módulos examinando el contenido descifrado de la cookie o revisando el código de los módulos en busca de llamadas a $this->context->cookie->mymodule_value = ....

Los módulos bien diseñados usan almacenamiento del lado del servidor (base de datos o caché) y almacenan como máximo un pequeño identificador en la cookie. Los módulos mal diseñados vuelcan estructuras de datos completas en la cookie, inflando su tamaño. Si identificas un módulo problemático, contacta al desarrollador o reemplaza el almacenamiento en cookie por almacenamiento respaldado por base de datos usando un identificador de sesión.

Gestión de sesiones: archivos, base de datos y Redis

Mientras PrestaShop almacena algunos datos directamente en cookies, PHP también mantiene su propio sistema de sesiones. El back office de PrestaShop depende más intensamente de las sesiones PHP que el front office. El gestor de sesiones determina dónde se almacenan los datos de sesión en el lado del servidor.

Sesiones basadas en archivos (predeterminadas)

Por defecto, PHP almacena las sesiones como archivos en el directorio session.save_path (típicamente /tmp o /var/lib/php/sessions). Cada sesión crea un archivo. Para una tienda con miles de sesiones activas, esto significa miles de archivos pequeños. Las sesiones basadas en archivos funcionan bien para tiendas pequeñas y medianas pero pueden causar problemas a gran escala.

Los problemas comunes con las sesiones basadas en archivos incluyen la recolección de basura lenta cuando el directorio de sesiones contiene demasiados archivos, el bloqueo de archivos que puede causar la serialización de solicitudes (dos solicitudes de la misma sesión no pueden procesarse simultáneamente) y los entornos de alojamiento compartido donde el directorio de sesiones se llena o tiene permisos restrictivos.

Sesiones en base de datos

PrestaShop soporta almacenar sesiones en la base de datos. Esto se configura en los ajustes de PHP o a través del gestor de sesiones de PrestaShop. Las sesiones en base de datos eliminan los problemas del sistema de archivos pero añaden una consulta a la base de datos por cada solicitud. Para tiendas que ya tienen una carga alta de base de datos, esto puede empeorar el rendimiento. Sin embargo, las sesiones en base de datos tienen la ventaja de ser compartidas entre múltiples servidores web en una configuración con balanceo de carga.

Sesiones con Redis o Memcached

Para tiendas PrestaShop de alto tráfico, Redis es el backend óptimo para el almacenamiento de sesiones. Redis almacena los datos de sesión en memoria, proporcionando tiempos de acceso inferiores al milisegundo. Soporta la expiración automática (timeout de sesión) y los datos de sesión se comparten entre todas las instancias del servidor web.

Para configurar PHP para usar Redis para las sesiones, establece session.save_handler = redis y session.save_path = "tcp://127.0.0.1:6379" en tu archivo php.ini o en la configuración del pool de PHP-FPM. Si tu instancia de Redis requiere autenticación, añade la contraseña a la ruta de guardado: "tcp://127.0.0.1:6379?auth=tucontraseña".

PrestaShop ya soporta Redis para el caché de objetos (configurado en el back office en Parámetros avanzados > Rendimiento). Usar la misma instancia de Redis tanto para sesiones como para caché de objetos simplifica tu infraestructura proporcionando al mismo tiempo un rendimiento excelente para ambos.

Atributos SameSite, Secure y HttpOnly

Los navegadores modernos aplican atributos de seguridad de cookies que afectan directamente al comportamiento de las cookies de PrestaShop. Los atributos de cookie mal configurados causan errores de inicio de sesión, carritos perdidos y errores en el procesamiento de pagos.

Atributo SameSite

El atributo SameSite controla si una cookie se envía con solicitudes entre sitios. Tiene tres valores posibles:

SameSite=Strict significa que la cookie nunca se envía con solicitudes entre sitios. Esto es demasiado restrictivo para PrestaShop porque los clientes que hacen clic en un enlace a tu tienda desde un correo electrónico o redes sociales no tendrían su cookie de sesión enviada, desconectándoles efectivamente.

SameSite=Lax es el valor predeterminado en los navegadores modernos. La cookie se envía con navegaciones de nivel superior (hacer clic en un enlace) pero no con sub-solicitudes entre sitios (imágenes, iframes, AJAX). Esto funciona bien para la cookie del front office de PrestaShop en la mayoría de los casos.

SameSite=None significa que la cookie siempre se envía, incluyendo con solicitudes entre sitios. Debe ir acompañada del atributo Secure. Se necesita cuando tu tienda está incrustada en un iframe en otro sitio o cuando las pasarelas de pago de terceros necesitan redirigir de vuelta a tu tienda con la sesión intacta.

Problemas con las pasarelas de pago

Muchos problemas de pago en PrestaShop son causados por problemas con las cookies SameSite. El escenario típico es: un cliente procede al pago, es redirigido al sitio de la pasarela de pago, completa el pago y es redirigido de vuelta a tu tienda. Si la cookie de sesión tiene SameSite=Lax, puede no enviarse en la redirección desde la pasarela de pago, dependiendo de cómo se implemente la redirección. Si la pasarela usa una redirección POST (común con 3D Secure), la política Lax bloquea la cookie y PrestaShop pierde la sesión. El cliente ve un carrito vacío o una página de error genérica en lugar de la confirmación del pedido.

La solución es configurar la cookie de PrestaShop como SameSite=None; Secure. En PrestaShop 1.7.7+ y 8.x, esto se puede configurar en los ajustes de cookies. Para versiones anteriores, puede ser necesario modificar la clase Cookie o añadir cabeceras a través de la configuración del servidor web. Siempre prueba los flujos de pago después de cambiar los ajustes de SameSite.

Atributo Secure

El atributo Secure asegura que la cookie solo se envía a través de conexiones HTTPS. Si tu tienda funciona sobre HTTPS (como debería), este atributo previene que la cookie sea transmitida a través de una conexión no cifrada, protegiéndola de la interceptación. PrestaShop establece este atributo cuando la tienda detecta una conexión HTTPS.

Un problema común ocurre con configuraciones mixtas HTTP/HTTPS. Si tu back office está en HTTPS pero algunas páginas del front office están en HTTP, las cookies marcadas como Secure no se enviarán en las páginas HTTP, rompiendo la sesión. La solución es forzar HTTPS en todas partes, lo cual deberías hacer de todos modos por razones de seguridad y SEO.

Atributo HttpOnly

El atributo HttpOnly impide que JavaScript acceda a la cookie a través de document.cookie. Esta es una medida de seguridad crítica contra ataques de cross-site scripting (XSS). Si un atacante inyecta JavaScript malicioso en tu tienda (a través de un módulo vulnerable, por ejemplo), el atributo HttpOnly impide que ese código robe las cookies de sesión.

PrestaShop establece el flag HttpOnly en sus cookies por defecto. No lo desactives a menos que tengas una razón muy específica y entiendas las implicaciones de seguridad.

Depuración de problemas de sesión y cookies

Los problemas de cookies y sesiones se manifiestan como síntomas misteriosos: clientes desconectados aleatoriamente, carritos que se vacían solos, sesiones de administración que expiran inmediatamente, procesos de pago que fallan silenciosamente. La depuración sistemática requiere verificar varias capas.

Herramientas de desarrollador del navegador

Abre la pestaña Application (Chrome) o Storage (Firefox) y navega a Cookies. Encuentra el dominio de tu tienda y examina todas las cookies. Verifica las columnas Nombre, Valor, Dominio, Ruta, Expira, Tamaño, HttpOnly, Secure y SameSite. Busca cookies que sean inusualmente grandes, que tengan configuraciones de dominio incorrectas (una cookie para www.example.com no se enviará a example.com) o que les falten atributos de seguridad.

Verificación de sesiones del lado del servidor

Si las sesiones se almacenan en archivos, verifica el directorio de sesiones en busca de la presencia y antigüedad de los archivos de sesión. Si un cliente reporta haber sido desconectado, encuentra su archivo de sesión (el nombre del archivo es el ID de sesión de la cookie PHPSESSID) y verifica cuándo fue modificado por última vez. Si el archivo falta, la sesión fue recolectada por el recolector de basura o nunca se creó correctamente.

Para sesiones en Redis, usa redis-cli para verificar si la clave de sesión existe: EXISTS PHPREDIS_SESSION:session_id. Verifica el TTL para ver si está a punto de expirar: TTL PHPREDIS_SESSION:session_id.

Causas comunes de desconexiones aleatorias

El _COOKIE_KEY_ cambió. Si esta clave cambia (durante un despliegue mal configurado, una sobrescritura del archivo de configuración o una actualización), todas las cookies existentes se vuelven ilegibles porque fueron cifradas con la clave antigua. Todos los clientes quedan efectivamente desconectados. La solución es restaurar la clave original desde una copia de seguridad.

La recolección de basura de sesiones es demasiado agresiva. El parámetro PHP session.gc_maxlifetime determina cuánto tiempo (en segundos) un archivo de sesión se considera válido. Si esto está configurado demasiado bajo (el valor predeterminado es 1440 segundos, o 24 minutos), las sesiones de los clientes que navegan lentamente se eliminan. Para una tienda, configúralo a al menos 3600 (1 hora) o más.

Balanceador de carga sin afinidad de sesión. Si tu tienda funciona en múltiples servidores web detrás de un balanceador de carga y las sesiones se almacenan en archivos, cada servidor tiene su propio directorio de sesiones. Un cliente cuyas solicitudes alternan entre servidores perderá su sesión en cada cambio. La solución es la afinidad de sesión (sesiones pegajosas) en el balanceador de carga, o almacenamiento de sesiones compartido usando Redis o una base de datos.

Discordancia del dominio de la cookie. Si tu tienda es accesible tanto en www.example.com como en example.com, pero el dominio de la cookie está configurado como www.example.com, los clientes que accedan al sitio sin el prefijo www no tendrán la cookie. Asegura un uso consistente del dominio con una redirección y verifica el dominio de la cookie en la configuración de PrestaShop.

Cumplimiento de cookies con el RGPD

El Reglamento General de Protección de Datos (RGPD) y la Directiva ePrivacy requieren consentimiento informado antes de establecer cookies no esenciales en el navegador del usuario. Las tiendas PrestaShop deben cumplir con estas regulaciones, y el incumplimiento puede resultar en sanciones significativas.

Cookies esenciales vs no esenciales

El RGPD distingue entre cookies estrictamente necesarias para el funcionamiento del sitio web y cookies que sirven para otros propósitos como analítica, marketing o personalización. La cookie de sesión de PrestaShop es esencial porque la tienda no puede funcionar sin ella. Un cliente no puede añadir productos al carrito ni completar una compra sin una cookie de sesión. Las cookies esenciales no requieren consentimiento bajo el RGPD.

Sin embargo, muchas otras cookies comúnmente encontradas en tiendas PrestaShop son no esenciales y requieren consentimiento explícito antes de ser establecidas. Estas incluyen las cookies de seguimiento de Google Analytics (_ga, _gid), las cookies del Facebook Pixel, las cookies publicitarias de plataformas de remarketing, las cookies de widgets de chat en vivo, las cookies de botones para compartir en redes sociales y cualquier cookie establecida por módulos de terceros con fines de seguimiento o personalización.

Implementación del consentimiento de cookies

PrestaShop no incluye un mecanismo integrado de consentimiento de cookies que cumpla los requisitos del RGPD. Necesitas un módulo de PrestaShop diseñado para el consentimiento de cookies o la integración con una plataforma de gestión del consentimiento (CMP) de terceros como Cookiebot, Osano o Usercentrics.

Una implementación adecuada del consentimiento de cookies debe presentar al usuario una elección clara antes de que se establezca cualquier cookie no esencial. Debe permitir al usuario aceptar o rechazar categorías individuales de cookies (analítica, marketing, etc.), no solo ofrecer una elección de todo-o-nada. Debe recordar la elección del usuario y no preguntar de nuevo hasta que expire el consentimiento. Debe realmente prevenir que las cookies bloqueadas se establezcan, no solo registrar la preferencia mientras sigue cargando los códigos de seguimiento.

El último punto es crítico y a menudo mal gestionado. Un banner de consentimiento que aparece pero carga Google Analytics de todos modos independientemente de la elección del usuario no proporciona ninguna protección legal. La implementación debe cargar condicionalmente los recursos de seguimiento y marketing basándose en el consentimiento del usuario.

Implementación técnica del consentimiento

El enfoque técnico para la gestión de cookies basada en consentimiento implica envolver el código no esencial en verificaciones de consentimiento. Para el JavaScript en línea que establece cookies o carga píxeles de seguimiento, reemplaza la ejecución directa con un cargador condicionado al consentimiento. El código de seguimiento se almacena pero no se ejecuta hasta que el usuario da su consentimiento.

Para los módulos de terceros que establecen cookies, la implementación es más compleja. Algunos módulos proporcionan hooks u opciones de configuración para la integración del consentimiento. Otros cargan sus cookies incondicionalmente y deben ser modificados o reemplazados. Audita cada módulo en tu tienda respecto al uso de cookies y determina cuáles establecen cookies no esenciales.

Consentimiento de cookies y almacenamiento en caché

El almacenamiento en caché de página completa crea un conflicto con el consentimiento de cookies. Si una página se almacena en caché con Google Analytics cargado y se sirve a un usuario que no ha dado consentimiento, estás violando el RGPD. Hay dos enfoques para manejar esto.

El primer enfoque es almacenar en caché la página sin recursos no esenciales e inyectarlos dinámicamente mediante JavaScript después de verificar el consentimiento. Esto funciona bien con el sistema CCC (Combine, Compress, Cache) de PrestaShop y con Varnish u otras cachés de proxy inverso.

El segundo enfoque es no almacenar en caché las páginas para usuarios que aún no han hecho una elección de consentimiento (visitantes por primera vez). Esto perjudica el rendimiento para nuevos visitantes pero asegura el cumplimiento. La mayoría de las plataformas de gestión del consentimiento utilizan el primer enfoque porque preserva los beneficios del almacenamiento en caché.

Consideraciones de seguridad relacionadas con las cookies

Más allá de los atributos HttpOnly y Secure ya discutidos, hay consideraciones de seguridad adicionales para las cookies de PrestaShop.

Robo de cookies y secuestro de sesión

Si un atacante obtiene una cookie de sesión válida de PrestaShop, puede suplantar al cliente o al administrador. La protección principal es HTTPS en todas partes (previene la interceptación), cookies HttpOnly (previene el robo por XSS) y el atributo Secure (previene la transmisión por HTTP). PrestaShop también vincula las sesiones a las direcciones IP en algunas configuraciones, lo que proporciona una capa adicional de protección pero puede causar problemas a los usuarios cuyas direcciones IP cambian (usuarios móviles, usuarios de VPN).

Seguridad de la clave de la cookie

El _COOKIE_KEY_ en la configuración de PrestaShop es la clave maestra para el cifrado de cookies. Si esta clave se ve comprometida, un atacante puede descifrar cualquier cookie de PrestaShop y falsificar cookies de sesión válidas. Protege esta clave restringiendo el acceso a los archivos de configuración, nunca commitándola en repositorios públicos y nunca compartiéndola en solicitudes de soporte.

Prevención de la fijación de sesión

Los ataques de fijación de sesión implican que un atacante establece un ID de sesión conocido en el navegador de la víctima antes de que la víctima inicie sesión. Cuando la víctima inicia sesión, el ID de sesión preestablecido por el atacante se convierte en autenticado. PrestaShop mitiga esto regenerando el ID de sesión al iniciar sesión. Asegúrate de que la regeneración del ID de sesión funcione correctamente y no haya sido deshabilitada por ningún módulo o cambio de configuración.

Resolución de problemas comunes con las cookies

Bucle de inicio de sesión en el panel de administración

El síntoma es introducir credenciales válidas en el back office de PrestaShop, ver brevemente el panel de control y ser redirigido de vuelta a la página de inicio de sesión. Esto es casi siempre un problema de cookies. Verifica que el dominio de la cookie sea correcto, que el nombre del directorio de administración no haya cambiado, que HTTPS esté correctamente configurado (el contenido mixto puede impedir el envío de la cookie Secure) y que el directorio de almacenamiento de sesiones sea escribible por el servidor web.

Carrito que se vacía al navegar

Si el carrito se vacía cuando el cliente navega a otra página, la cookie de sesión no se está manteniendo. Las causas comunes incluyen una configuración del dominio de la cookie faltante o incorrecta, un session.cookie_lifetime mal configurado en PHP (establecido en 0 significa que la cookie expira al cerrar el navegador, lo cual es correcto, pero algunas configuraciones lo establecen en un tiempo muy corto), o una capa de CDN o almacenamiento en caché que elimina la cabecera Set-Cookie de las respuestas.

Fallo del pago después del proceso de pago

Cuando los clientes completan el pago pero ven un error o un carrito vacío al regresar a tu tienda, la política SameSite de la cookie suele ser la causa, como se describió en la sección de pasarelas de pago anterior. Prueba el flujo completo de pago con las herramientas de desarrollador del navegador abiertas, observando las cookies en cada paso para identificar dónde se pierde la sesión.

Múltiples tiendas en el mismo dominio

Si ejecutas múltiples instalaciones de PrestaShop en el mismo dominio (por ejemplo, en subdirectorios), sus cookies pueden entrar en conflicto. Cada instalación usa un nombre de cookie similar, y si la ruta de la cookie está establecida en /, la cookie de una tienda sobrescribe la de la otra. Establece nombres de cookie únicos para cada instalación a través del _COOKIE_KEY_ (que afecta al nombre de la cookie) o configura la ruta de la cookie para que coincida con el subdirectorio de cada instalación.

Optimización de la configuración de cookies para el rendimiento

Una configuración de cookies de PrestaShop bien optimizada minimiza la sobrecarga mientras mantiene la funcionalidad. Usa un dominio sin cookies o un CDN para los recursos estáticos para evitar enviar cookies con solicitudes de imágenes, CSS y JavaScript. Mantén el tamaño de la cookie pequeño evitando que los módulos almacenen datos innecesarios en ella. Establece tiempos de espera de sesión apropiados que equilibren la seguridad (más corto es más seguro) con la experiencia del usuario (más largo significa menos re-inicios de sesión). Usa Redis para el almacenamiento de sesiones para combinar acceso rápido con estado compartido entre instancias del servidor. Habilita los atributos Secure y HttpOnly para proteger la integridad de la cookie sin afectar al rendimiento. Implementa un consentimiento de cookies adecuado para evitar cargar cookies de seguimiento innecesarias que añaden sobrecarga y riesgo legal.

Cada una de estas optimizaciones es individualmente pequeña, pero juntas crean una mejora significativa tanto en rendimiento como en cumplimiento. La gestión de cookies no es un trabajo glamuroso, pero subyace a cada interacción entre tu tienda y tus clientes, lo que hace que valga la pena hacerlo bien.

Leer respuesta completa

Why Database Performance Matters in PrestaShop

PrestaShop is a database-heavy application. Every product page, category listing, search result, cart update, and checkout step involves multiple database queries. A typical product page can generate 50 to 200 or more SQL queries depending on the number of modules installed, the complexity of the product (combinations, features, attachments), and the theme. When any of these queries run slowly, the entire page slows down, and the effect compounds under load.

The challenge is identifying which queries are actually slow. With hundreds of queries per page load, you cannot simply guess. You need data. The MySQL slow query log is the most direct and reliable tool for collecting this data. It records every query that exceeds a time threshold you define, giving you a clear picture of where your database spends the most time.

This guide covers how to enable and configure the slow query log, how to analyze the results, how to interpret query execution plans, and how to apply the most common optimizations for PrestaShop databases.

Enabling the Slow Query Log

The slow query log is a MySQL feature that writes queries exceeding a specified execution time to a log file. It is disabled by default on most installations because it adds a small amount of I/O overhead, but the performance cost is negligible compared to the diagnostic value it provides.

Configuration via my.cnf

To enable the slow query log permanently, add the following lines to your MySQL configuration file. On most Linux systems, this file is located at /etc/mysql/my.cnf, /etc/my.cnf, or in a directory like /etc/mysql/conf.d/:

slow_query_log = 1 enables the feature.

slow_query_log_file = /var/log/mysql/slow-query.log specifies where the log is written. Make sure the MySQL process has write permissions to this directory.

long_query_time = 1 sets the threshold in seconds. Any query that takes longer than this value is logged. Start with 1 second to catch the most egregious offenders, then lower it to 0.5 or even 0.1 seconds as you optimize the worst queries and want to find more subtle bottlenecks.

log_queries_not_using_indexes = 1 logs queries that do not use any index, regardless of how long they take. This is extremely useful for PrestaShop because many performance problems are caused by full table scans on large tables. However, this can generate a lot of log entries on a busy store, so you may want to enable it temporarily during analysis and disable it afterward.

After editing the configuration file, restart MySQL for the changes to take effect.

Enabling at Runtime

You can also enable the slow query log without restarting MySQL by running SQL commands. Connect to MySQL as root and execute:

SET GLOBAL slow_query_log = 'ON';

SET GLOBAL long_query_time = 1;

SET GLOBAL log_queries_not_using_indexes = 1;

Runtime changes take effect immediately but do not persist across MySQL restarts. This approach is useful for temporary analysis sessions where you want to collect data for a specific period and then disable logging.

Choosing the Right Threshold

The long_query_time value determines what gets logged. Setting it too high means you miss moderately slow queries that collectively impact performance. Setting it too low floods the log with entries that are not individually problematic.

For an initial analysis, start at 1 second. This catches queries that are clearly too slow. After optimizing those, lower the threshold to 0.5 seconds, then 0.2 seconds. On a well-optimized PrestaShop database, the goal is for no query to take longer than 0.1 seconds, but reaching that level requires significant optimization work.

Keep in mind that query execution time varies with server load. A query that takes 0.3 seconds under normal load might take 2 seconds during a traffic spike because of CPU contention, disk I/O bottlenecks, or lock contention. The slow query log captures actual execution times, so analyzing logs from peak traffic periods gives you the most realistic picture.

Analyzing the Slow Query Log

The raw slow query log is a text file with entries that look like this:

# Time: 2024-03-15T14:22:33.456789Z
# User@Host: prestashop[prestashop] @ localhost []
# Query_time: 3.456123 Lock_time: 0.000234 Rows_sent: 1 Rows_examined: 847293
SET timestamp=1710511353;
SELECT * FROM ps_product WHERE active = 1 AND id_product NOT IN (SELECT id_product FROM ps_category_product WHERE id_category = 2);

The key fields are Query_time (how long the query took), Lock_time (how long it waited for a lock), Rows_sent (how many rows were returned), and Rows_examined (how many rows MySQL had to look at to find the result). A query that examines 847,293 rows to return 1 row is a clear sign of a missing index or inefficient query structure.

Using mysqldumpslow

Reading the raw log file is impractical for busy stores that generate thousands of slow query entries. The mysqldumpslow tool, included with MySQL, aggregates and summarizes slow query log entries. It groups identical queries together (abstracting away specific values) and sorts them by various criteria.

To find the 10 slowest queries by average time: mysqldumpslow -s at -t 10 /var/log/mysql/slow-query.log

To find the queries with the most total execution time: mysqldumpslow -s t -t 10 /var/log/mysql/slow-query.log

To find the queries that examined the most rows: mysqldumpslow -s r -t 10 /var/log/mysql/slow-query.log

The -s flag specifies the sort order: at for average time, t for total time, c for count (how many times the query appeared), r for rows examined. The -t flag limits the output to the top N queries.

The most useful sort for initial analysis is by total time (-s t), which shows you which queries consume the most database time overall. A query that takes 0.5 seconds but runs 1000 times per hour consumes more total time than a query that takes 5 seconds but runs once per hour.

Using pt-query-digest

For more detailed analysis, Percona Toolkit's pt-query-digest is the industry standard tool. It provides far more detailed statistics than mysqldumpslow, including percentile distributions of query times, variance analysis, and table-level statistics.

Basic usage: pt-query-digest /var/log/mysql/slow-query.log

The output starts with a profile section that ranks queries by total time, similar to mysqldumpslow but with more detail. Each query then gets a detailed section showing the minimum, maximum, mean, median, and 95th percentile execution times, plus the distribution of rows examined and rows sent.

The 95th percentile is particularly important for PrestaShop performance. It tells you the execution time that 95% of executions fall below. If the average is 0.3 seconds but the 95th percentile is 2.5 seconds, you have a consistency problem: most of the time the query is acceptable, but 5% of users experience a much slower response.

You can install Percona Toolkit on Debian and Ubuntu with apt install percona-toolkit or download it from the Percona website. It is worth installing on any server where you run PrestaShop.

Common Slow Queries in PrestaShop

Certain query patterns appear repeatedly in PrestaShop slow query logs. Knowing these patterns helps you diagnose issues faster.

Full Table Scans on ps_product

Queries against the ps_product table without proper index usage are among the most common slow queries. As your catalog grows beyond a few thousand products, any query that scans the entire product table becomes problematic. Look for queries with WHERE clauses on columns that are not indexed, or queries that join ps_product with ps_product_lang and ps_product_shop without using the primary keys efficiently.

Category Product Listings with Many Filters

When customers use layered navigation (faceted search) to filter products by attributes, features, or price ranges, PrestaShop generates complex queries that join multiple tables. The ps_layered_* tables used by the faceted search module can become performance bottlenecks if indexes are missing or if the indexing process has not run recently.

Search Queries

PrestaShop's built-in search uses the ps_search_word and ps_search_index tables. On stores with large catalogs and many search terms, these tables grow large and queries against them slow down. The search query typically involves a full-text operation or multiple LIKE conditions, both of which are inherently slower than index lookups.

Cart and Order Queries

Queries that aggregate cart or order data can be slow on stores with a long history. If your ps_cart table has millions of rows (which is common because PrestaShop creates a new cart for almost every visitor), queries that scan this table become slow. The same applies to ps_orders and ps_order_detail on high-volume stores.

Statistics and Reporting Queries

Back office statistics modules often run aggregate queries (SUM, COUNT, GROUP BY) across large tables like ps_orders, ps_connections, and ps_page_viewed. These queries can be extremely slow because they scan large datasets. On stores that have been running for years, these tables may contain millions of rows, and statistics queries that worked fine on a small dataset now take minutes.

Module-Generated Queries

Third-party modules frequently generate inefficient queries because module developers often test against small datasets. A module that works perfectly with 100 products may generate catastrophically slow queries with 10,000 products. The slow query log helps you identify which modules are responsible because the query text often includes table names or patterns that point to specific modules.

Using EXPLAIN to Analyze Queries

Once you have identified slow queries from the log, the next step is understanding why they are slow. The EXPLAIN statement shows you how MySQL plans to execute a query, including which indexes it uses, how many rows it expects to examine, and what join strategies it employs.

Reading EXPLAIN Output

Run EXPLAIN followed by the slow query. The output shows one row per table in the query, with these important columns:

type: How MySQL accesses the table. Values from best to worst: system/const (single row, essentially free), eq_ref (one row per join, using unique index), ref (multiple rows, using non-unique index), range (index range scan), index (full index scan), ALL (full table scan). If you see ALL on a table with more than a few thousand rows, that is almost certainly your bottleneck.

key: Which index MySQL actually chose for this table. If this is NULL, no index is being used, and MySQL is scanning the entire table.

rows: The estimated number of rows MySQL needs to examine. This is an estimate, not exact, but it gives you a sense of scale. If the estimated rows value is close to the total number of rows in the table, you have a full table scan.

Extra: Additional information about the execution plan. Watch for Using filesort (MySQL must sort results without an index, which is slow for large datasets), Using temporary (MySQL creates a temporary table, often for GROUP BY or DISTINCT operations), and Using where (MySQL is filtering rows after reading them, which means the index does not fully cover the WHERE clause).

EXPLAIN Example

Consider a slow query: SELECT p.id_product, pl.name FROM ps_product p LEFT JOIN ps_product_lang pl ON p.id_product = pl.id_product WHERE pl.id_lang = 1 AND p.active = 1 AND p.price > 100 ORDER BY p.date_add DESC LIMIT 20

Running EXPLAIN on this query might show that the ps_product table is accessed with type ALL (full table scan), no key is used, and the Extra column shows Using where; Using filesort. This tells you that MySQL is reading every row in the product table, filtering by active status and price, and then sorting the results by date. On a table with 50,000 products, this involves reading and sorting thousands of rows to return just 20.

The fix would be creating a composite index on (active, price, date_add) or restructuring the query to take better advantage of existing indexes.

Index Optimization for PrestaShop

Adding the right indexes is the most effective way to speed up slow queries. An index allows MySQL to find rows without scanning the entire table, similar to how a book's index lets you find a topic without reading every page.

When to Add an Index

Add an index when EXPLAIN shows a full table scan (type ALL) on a table with many rows, when a query runs frequently and consistently appears in the slow query log, and when the query's WHERE clause, JOIN condition, or ORDER BY clause references columns that are not currently indexed.

Do not add indexes blindly. Every index speeds up reads but slows down writes (INSERT, UPDATE, DELETE) because MySQL must update the index on every data modification. PrestaShop performs many writes (cart updates, order creation, statistics tracking), so excessive indexing creates its own performance problems.

Composite Indexes

For PrestaShop queries, composite (multi-column) indexes are often more effective than single-column indexes. A composite index on (id_shop, id_lang, active) lets MySQL efficiently handle queries that filter by all three columns. The order of columns in the index matters: MySQL uses the index from left to right, so the most selective column (the one that filters out the most rows) should generally come first.

PrestaShop's multishop and multilanguage architecture means many queries include id_shop and id_lang conditions. These columns appear in virtually every query against product, category, and CMS tables. If you are adding custom indexes, including these columns is often necessary for the index to be useful.

Covering Indexes

A covering index contains all the columns that a query needs, so MySQL can satisfy the entire query from the index without reading the actual table data. This is shown in EXPLAIN as Using index in the Extra column. Covering indexes provide the best possible performance because reading from an index is faster than reading from the table itself (indexes are smaller and more likely to fit in memory).

Common Index Additions for PrestaShop

Several indexes that are not present in a default PrestaShop installation can significantly improve performance on large stores. These include indexes on the date_add column in ps_cart and ps_orders for queries that filter or sort by date, composite indexes on ps_product_attribute for combination-heavy queries, and indexes on custom columns added by modules that run frequent queries against them.

Before adding any index, verify the improvement by running the slow query with and without the index. Use EXPLAIN to confirm that MySQL actually uses the new index. An unused index wastes disk space and slows down writes without providing any benefit.

Connection Management and Query Optimization

Connection Pooling

PrestaShop uses a single database connection per request by default. Each PHP process opens a connection to MySQL, executes its queries, and closes the connection when the request completes. On busy stores with many concurrent visitors, this creates a high rate of connection creation and teardown, which has overhead.

MySQL's max_connections setting limits how many simultaneous connections are allowed. If your store runs out of connections, visitors see "Too many connections" errors. The default value is often 151, which may be insufficient for high-traffic stores running many PHP-FPM workers.

To determine the right value, check the Max_used_connections status variable, which tells you the peak number of simultaneous connections since MySQL started. Set max_connections to at least 20% above this peak to provide headroom during traffic spikes.

Query Optimization Techniques

Beyond indexing, several query-level optimizations can improve PrestaShop database performance:

Avoid SELECT *: Queries that select all columns transfer more data than necessary between MySQL and PHP. PrestaShop core sometimes uses SELECT * for convenience, but custom queries should specify only the columns needed.

Limit subqueries: MySQL's optimizer handles subqueries less efficiently than JOINs in many cases. If you see slow queries with IN (SELECT ...) patterns, rewriting them as JOINs often improves performance. This applies particularly to queries generated by modules.

Use LIMIT wisely: For paginated listings, PrestaShop typically uses LIMIT offset, count. For large offsets (like page 500 of a product listing), this becomes slow because MySQL must read and discard all rows up to the offset. A more efficient approach is keyset pagination, where you filter by the last seen ID instead of using an offset.

Batch operations: Modules that process products in loops often execute one query per product. Rewriting these as batch queries (using IN clauses or CASE statements for updates) dramatically reduces the number of round trips to the database.

Monitoring and Ongoing Optimization

Database optimization is not a one-time task. As your catalog grows, traffic patterns change, and you install new modules, new slow queries emerge. Establish a routine for monitoring database performance.

Enable the slow query log permanently with a reasonable threshold (0.5 to 1 second). Review the log weekly or monthly using pt-query-digest. Pay attention to new queries that appear in the log and to existing queries whose execution time increases over time.

Monitor MySQL's key performance metrics: the buffer pool hit rate (should be above 99%), the number of slow queries per hour, the average query time, and the connection usage. These metrics give you early warning of performance degradation before it impacts users.

When you add or update modules, check whether they introduce new slow queries. Run the module's functionality while monitoring the slow query log to catch problems before they affect production traffic. A module that generates efficient queries on a test store with 50 products may create severe bottlenecks on a production store with 50,000 products. Testing with production-scale data is the only reliable way to verify module performance.

Summary

The MySQL slow query log is your most valuable tool for finding and fixing database bottlenecks in PrestaShop. Enable it, set an appropriate threshold, and use analysis tools like mysqldumpslow or pt-query-digest to identify the worst offenders. Use EXPLAIN to understand why specific queries are slow, and apply targeted indexes to eliminate full table scans. Monitor your database performance continuously, because optimization is an ongoing process as your store grows. The combination of slow query log analysis, EXPLAIN-driven optimization, and proper indexing can transform a sluggish PrestaShop store into one that handles large catalogs and high traffic with responsive page loads.

Leer respuesta completa

Cuando las combinaciones de PrestaShop matan el rendimiento: limites y soluciones

El sistema de combinaciones de PrestaShop permite crear variantes de producto. Funciona perfectamente para productos con pocas variantes. Pero cuando los productos tienen cientos o miles de combinaciones, el rendimiento se degrada dramaticamente.

Por que las combinaciones causan problemas de rendimiento

Arquitectura de la base de datos

PrestaShop almacena datos de combinaciones en multiples tablas: ps_product_attribute, ps_product_attribute_combination, ps_stock_available, ps_specific_price. Un producto con 5 tallas y 10 colores crea 50 combinaciones con mas de 350 filas en la base de datos.

El problema del crecimiento exponencial

Atributos	Valores	Combinaciones	Filas BD
2	5 x 5	25	~175
3	10 x 15 x 8	1.200	~8.400
4	10 x 15 x 8 x 5	6.000	~42.000

Limites practicos

Cantidad	Front Office	Back Office	Veredicto
1-50	Rapido	Rapido	Sin problemas
50-200	Aceptable	Aceptable	Manejable
200-500	Lento (3-8s)	Lento	Optimizacion necesaria
500-1000	Muy lento	Muy lento	Considerar reestructuracion
1000+	Inutilizable	A menudo falla	Reestructuracion requerida

Solucion 1 - Reestructurar el catalogo

En lugar de un producto con 50 combinaciones, crear productos separados por color con 5 combinaciones cada uno. Mas rapido y mejor para SEO.

Solucion 2 - Optimizacion de base de datos y servidor

ALTER TABLE ps_product_attribute 
  ADD INDEX idx_product_default (id_product, default_on);

ALTER TABLE ps_stock_available 
  ADD INDEX idx_product_attribute (id_product, id_product_attribute);

Solucion 3 - Carga progresiva de combinaciones

En lugar de cargar todas las combinaciones al cargar la pagina, obtener datos via AJAX cuando el cliente selecciona un atributo.

Solucion 4 - Estrategias de cache

Cache de pagina completa (Varnish, LiteSpeed) para paginas de producto. Redis o Memcached para cache de objetos.

Cuando evitar las combinaciones completamente

Productos configurables con 4+ atributos - Modulo configurador de producto
Productos dimensionales - Modulo de dimensiones personalizadas
Productos print-on-demand - Modulo disenador de producto

Recomendaciones por cantidad de combinaciones

Cantidad	Accion recomendada
Menos de 100	Ninguna accion necesaria
100-300	Indices BD, OPcache, Redis
300-1000	Dividir productos, indices, lazy loading
Mas de 1000	Reestructurar catalogo, modulo configurador

Leer respuesta completa

Cookie	Proveedor	Finalidad	Duración
TawkConnectionTime	Tawk.to	Rastreo del tiempo de conexion de la sesion de chat	Sesión
__tawkuuid	Tawk.to	Identifica a los visitantes recurrentes del chat	6 mes(es)

Solución de problemas

El problema: necesitas el módulo, pero no sus recursos en todas las páginas

Método 1: Usar Theme.yml para eliminar recursos de módulos

Método 2: Media::unregisterStylesheet y Media::unregisterJavascript

Método 3: Módulo personalizado para bloquear recursos específicos

Método 4: El enfoque de desvincular hooks

Método 5: Anular los recursos del módulo a través de tu tema

PrestaShop 1.7 vs 8.x: diferencias en el enfoque

Midiendo las mejoras de rendimiento después de desactivar recursos

Riesgos y consideraciones de compatibilidad

Un flujo de trabajo práctico para la eliminación segura de recursos

Comprender memory_limit de PHP

Cómo Verificar Tu Límite de Memoria Actual

Desde el Back Office de PrestaShop

Usando phpinfo()

Vía Línea de Comandos

Causas Comunes de Errores de Límite de Memoria

Importaciones de Productos Masivas

Productos con Muchas Combinaciones

Módulos Sobrecargados o Mal Codificados

Catálogos Grandes y Consultas Complejas

Compilación de Plantillas Smarty

Cómo Aumentar el Límite de Memoria

Método 1: php.ini

Método 2: .htaccess (Solo Apache con mod_php)

Método 3: .user.ini (PHP-FPM)

Método 4: Dentro del Código de PrestaShop

Método 5: Configuración Por Pool (PHP-FPM)

Memoria Por Proceso vs Memoria Compartida

Diagnosticar Fugas de Memoria y Uso Excesivo

Habilitar el Modo Debug de PrestaShop

Monitorear el Uso de Memoria en el Código

Usar el Profiling de Xdebug

Verificar Consultas Lentas y MySQL

Memoria OPcache

Configuración de Memoria MySQL

Cuándo Actualizar Tu Hosting

Referencia Rápida: Configuraciones Recomendadas por Tamaño de Tienda

Comprender max_input_vars en PrestaShop

Por Qué PrestaShop Necesita Valores max_input_vars Altos

Síntomas de max_input_vars Demasiado Bajo

Cómo Verificar Tu Valor Actual de max_input_vars

Calcular el Valor max_input_vars Que Necesitas

Cómo Aumentar max_input_vars

Método 1: php.ini (Recomendado)

Método 2: .htaccess (Apache con mod_php o mod_fcgid)

Método 3: .user.ini (PHP-FPM / CGI)

Método 4: Panel de Control del Hosting

La Complicación del Parche Suhosin

Enfoques Alternativos para Productos con 500+ Combinaciones

Importar Combinaciones mediante CSV

Usar la API Webservice de PrestaShop

Dividir Productos Grandes

Gestionar Combinaciones en Lotes

Verificar la Corrección

Configuraciones PHP Relacionadas a Verificar

Notas Específicas por Versión de PrestaShop

Prevenir Problemas Futuros

Por Qué Aparecen Páginas en Blanco Después de las Actualizaciones de PrestaShop

Paso 1: Habilitar el Modo Debug

Paso 2: Verificar los Registros de Errores

Causa Común 1: Módulos Incompatibles

Causa Común 2: Incompatibilidad de Versión PHP

Causa Común 3: Conflictos de Override

Causa Común 4: Caché y Archivos Compilados

Causa Común 5: Fallos en la Migración de la Base de Datos

Procedimiento de Recuperación Paso a Paso

Procedimiento de Actualización Seguro para Futuras Actualizaciones

Estrategias de Rollback

La Importancia de los Respaldos de la Base de Datos

Cuándo Buscar Ayuda Profesional

Como funcionan las actualizaciones del carrito en PrestaShop

Sintoma: hacer clic en Anadir al carrito no produce ningun efecto

Sintoma: Anadir al carrito gira pero nunca se completa

Sintoma: el carrito se actualiza pero muestra datos incorrectos

Problemas de cache del navegador

Conflictos con la cache de Smarty

Configuracion CCC y su impacto

Problemas de cache del CDN

Problemas de cookies y sesiones