Integración Omnisend

OPcache es una extensión de PHP que almacena en cache el código PHP compilado en memoria, de modo que PHP no tiene que recompilarlo en cada petición. Debería habilitarlo sin duda — puede mejorar el rendimiento de PrestaShop entre un 30-50% sin ningún inconveniente para producción. La mayoría de los proveedores de hosting lo tienen habilitado por defecto. La configuración importante es opcache.validate_timestamps: establézcala en 1 en desarrollo, pero muchos servidores de producción la establecen en 0 para máximo rendimiento (lo que significa que necesita restablecer OPcache manualmente después de desplegar cambios de código).

See our full guide on PHP optimization

Cómo funcionan las plantillas de correo electrónico de PrestaShop

PrestaShop envía correos electrónicos transaccionales en cada momento clave del recorrido del cliente: creación de cuenta, confirmación de pedido, notificación de envío, restablecimiento de contraseña y mucho más. Estos correos electrónicos se generan a partir de archivos de plantilla almacenados en su servidor y son completamente personalizables. Comprender cómo funciona el sistema de plantillas es el primer paso para crear correos electrónicos de confirmación de pedido profesionales y coherentes con la marca, que refuercen la identidad de su tienda.

Cada correo electrónico de PrestaShop consta de dos archivos de plantilla: una versión HTML para los clientes de correo que soportan formato enriquecido, y una versión de texto plano (TXT) para los clientes de correo que no lo soportan. Ambos archivos deben existir para que un correo electrónico se envíe correctamente. La versión HTML es la que verá la gran mayoría de sus clientes. La versión TXT sirve como alternativa y también es utilizada por herramientas de accesibilidad y algunos filtros de correo corporativo.

Las plantillas de correo electrónico se encuentran en la estructura de directorios mails/. La ubicación exacta depende de si está utilizando correos electrónicos del núcleo, correos electrónicos sobrescritos por el tema o correos electrónicos específicos de un módulo. Comprender esta jerarquía es esencial, ya que PrestaShop comprueba múltiples ubicaciones para cada plantilla y utiliza la primera que encuentra.

La estructura de directorios de las plantillas de correo electrónico

PrestaShop organiza las plantillas de correo electrónico en una jerarquía de directorios específica. Cuando necesita enviar un correo electrónico, el sistema busca en estas ubicaciones en orden de prioridad:

Sobrescrituras a nivel de tema (Prioridad más alta)

Las plantillas en /themes/su-tema/mails/es/ (donde es es el código ISO del idioma) tienen prioridad sobre todas las demás ubicaciones. Si desea personalizar una plantilla de correo electrónico sin modificar los archivos del núcleo, es aquí donde deben colocarse sus plantillas personalizadas. Este enfoque sobrevive a las actualizaciones de PrestaShop, ya que los archivos del tema no se sobrescriben durante las actualizaciones del núcleo.

Plantillas del núcleo (Predeterminadas)

Las plantillas predeterminadas se encuentran en /mails/es/ en el directorio raíz de su PrestaShop. Estas son las plantillas que se envían con PrestaShop y se utilizan cuando no existe ninguna sobrescritura del tema. Editar estos archivos directamente funciona, pero no se recomienda porque sus cambios se perderán cuando actualice PrestaShop.

Plantillas específicas de módulos

Los módulos que envían sus propios correos electrónicos almacenan las plantillas en /modules/nombre-modulo/mails/es/. Por ejemplo, los correos electrónicos de notificación de pedido enviados por los módulos de pago del núcleo se almacenan en sus respectivos directorios de módulos. Puede sobrescribirlos colocando copias modificadas en el directorio mails/ de su tema con el mismo nombre de archivo.

Subdirectorios de idiomas

Cada directorio mails/ contiene subdirectorios para cada idioma instalado, utilizando el código ISO del idioma: en para inglés, fr para francés, de para alemán, y así sucesivamente. Cuando PrestaShop envía un correo electrónico, utiliza la plantilla del directorio que coincide con la preferencia de idioma del cliente. Si una plantilla no existe en el idioma del cliente, PrestaShop recurre al idioma predeterminado.

Anatomía de una plantilla de confirmación de pedido

El correo electrónico de confirmación de pedido es el correo electrónico transaccional más importante que envía su tienda. Es el archivo denominado order_conf.html (y su compañero order_conf.txt) en su directorio mails. Examinemos su estructura en detalle.

Estructura de la plantilla HTML

Las plantillas de correo electrónico de PrestaShop son documentos HTML independientes. No utilizan archivos CSS externos porque la mayoría de los clientes de correo eliminan las hojas de estilo externas. Todo el estilo debe ser CSS en línea. Una plantilla típica de confirmación de pedido incluye estas secciones:

El documento comienza con un doctype HTML estándar y una sección head. El cuerpo contiene un diseño basado en tablas (porque los clientes de correo tienen un soporte deficiente para los métodos de diseño CSS modernos como flexbox y grid). Dentro de este diseño, encontrará una sección de encabezado con el logotipo de su tienda, el área de contenido principal con los detalles del pedido, una tabla de productos que lista cada artículo pedido, un resumen de precios con subtotales y totales, información de envío, detalles del método de pago y un pie de página con la información de contacto de la tienda y los avisos legales.

El sistema de variables

PrestaShop utiliza un sistema simple de sustitución de variables en las plantillas de correo electrónico. Las variables se encierran entre llaves: {nombre_variable}. Cuando se genera el correo electrónico, PrestaShop reemplaza cada variable con su valor real. La plantilla de confirmación de pedido utiliza estas variables clave:

{firstname} y {lastname} contienen el nombre del cliente. {order_name} es el número de referencia del pedido (como ABCDEF123). {shop_name} es el nombre de su tienda tal como está configurado en el back office. {shop_url} es la URL de su tienda. {shop_logo} es la ruta a la imagen del logotipo de su tienda. {date} es la fecha del pedido. {payment} es el método de pago utilizado. {total_paid} es el importe total pagado. {delivery_company} y {delivery_address} contienen la información del transportista y la dirección de envío.

Para la lista de productos, PrestaShop utiliza una sintaxis de bloque especial. La sección de artículos de productos está envuelta en un bucle que se repite para cada producto del pedido: {items} contiene el HTML preformateado para toda la tabla de la lista de productos, incluyendo nombres de productos, cantidades, precios y cualquier detalle de personalización.

Referencia de variables disponibles

Para ver todas las variables disponibles para una plantilla de correo electrónico específica, consulte el código PHP que envía el correo electrónico. Para la confirmación de pedido, compruebe la clase PaymentModule (en /classes/PaymentModule.php). El método validateOrder() construye el array de variables de la plantilla. Cada clave del array corresponde a un nombre de variable que puede usar en la plantilla.

Las variables comúnmente disponibles en los correos electrónicos de confirmación de pedido incluyen: {id_order}, {order_name}, {delivery_block_txt}, {invoice_block_txt}, {delivery_block_html}, {invoice_block_html}, {delivery_company}, {delivery_firstname}, {delivery_lastname}, {delivery_address1}, {delivery_address2}, {delivery_city}, {delivery_postal_code}, {delivery_country}, {delivery_phone}, {invoice_company}, {invoice_firstname}, {invoice_lastname}, {invoice_address1}, {invoice_address2}, {invoice_city}, {invoice_postal_code}, {invoice_country}, {invoice_phone}, {message} y {total_products}.

Personalizar la plantilla de confirmación de pedido

Paso 1: Crear una sobrescritura del tema

Nunca edite directamente los archivos de plantilla del núcleo. En su lugar, copie la plantilla al directorio mails de su tema:

Copie /mails/es/order_conf.html a /themes/su-tema/mails/es/order_conf.html. Haga lo mismo para order_conf.txt. Si el directorio mails/es/ no existe en su tema, créelo.

Si su tienda admite varios idiomas, copie las plantillas para cada directorio de idioma. Su confirmación de pedido en francés va en /themes/su-tema/mails/fr/order_conf.html y así sucesivamente.

Paso 2: Modificar el diseño HTML

Abra la plantilla HTML en un editor de texto (no en un editor visual que pueda añadir código no deseado). El HTML de correo electrónico difiere del HTML web en varios aspectos importantes:

Use tablas para el diseño, no divs. Los clientes de correo, especialmente Outlook, tienen un soporte CSS muy limitado. Un diseño de tres columnas debe usar un <table> con tres elementos <td>, no columnas CSS ni flexbox.

Use estilos en línea en cada elemento. En lugar de <p class="heading"> con una hoja de estilos separada, use <p style="font-size:18px; font-weight:bold; color:#333333;">. Cada elemento con estilo necesita su propio atributo de estilo en línea.

Establezca anchos explícitos en tablas y celdas. Los clientes de correo no siempre respetan los anchos porcentuales. Use un ancho fijo para su tabla de contenido principal (600 píxeles es el estándar) con columnas internas porcentuales.

Use fuentes web seguras. No todos los clientes de correo soportan fuentes personalizadas. Utilice Arial, Helvetica, Georgia, Times New Roman, Verdana o Trebuchet MS. Puede intentar cargar una fuente personalizada como alternativa, pero siempre especifique una fuente web segura como alternativa final.

Paso 3: Añadir su branding

Reemplace el encabezado predeterminado de PrestaShop con el branding de su tienda. Esto típicamente implica actualizar el logotipo (la variable {shop_logo} utiliza automáticamente el logotipo de su tienda, pero puede querer una versión específica para correos electrónicos), cambiar el color de fondo del encabezado para que coincida con su marca, añadir la paleta de colores de su marca a los encabezados y enlaces, e incluir el eslogan de su tienda o un breve mensaje de marketing.

Mantenga la estructura general simple. Los diseños de correo electrónico excesivamente complejos se rompen en diferentes clientes de correo. Un diseño limpio de una sola columna con los colores y el logotipo de su marca es más efectivo y más fiable que un elaborado diseño de múltiples columnas.

Paso 4: Personalizar la tabla de productos

La tabla de productos predeterminada en la confirmación de pedido de PrestaShop es funcional pero básica. Puede mejorarla añadiendo imágenes de productos (use URLs absolutas a imágenes alojadas en su servidor, no rutas relativas), añadiendo enlaces a las páginas de productos para que los clientes puedan reordenar fácilmente o dejar reseñas, añadiendo campos personalizados como fechas de entrega estimadas o mensajes personalizados, y ajustando el estilo de la tabla para que coincida con su marca.

Al añadir imágenes de productos, manténgalas pequeñas (de 50 a 80 píxeles de ancho) y siempre incluya un atributo alt. Algunos clientes de correo bloquean las imágenes por defecto, y el texto alternativo garantiza que los clientes puedan identificar sus productos de todos modos.

Añadir campos personalizados a los correos electrónicos de pedido

Las variables predeterminadas de PrestaShop cubren la información estándar del pedido, pero puede querer incluir datos adicionales como puntos de fidelidad ganados, fecha de entrega estimada, un mensaje de agradecimiento personalizado o recomendaciones de productos de venta cruzada.

Añadir variables mediante un módulo

La forma más limpia de añadir variables personalizadas es a través de un módulo que se enganche al proceso de envío de correos electrónicos. Cree un módulo que registre el hook actionEmailSendBefore (disponible a partir de PrestaShop 1.7.6) o el hook actionGetExtraMailTemplateVars. En su manejador del hook, añada sus variables personalizadas al array de variables de la plantilla:

Su función de hook recibe el array de variables de la plantilla por referencia. Puede añadir nuevas variables a este array, y estarán disponibles en la plantilla usando la sintaxis estándar {nombre_variable}. Por ejemplo, después de añadir loyalty_points al array en su hook, puede usar {loyalty_points} en su plantilla HTML de confirmación de pedido.

Usar datos existentes de la base de datos

Puede incorporar cualquier dato de su base de datos PrestaShop en las variables de correo electrónico. Ejemplos comunes incluyen el recuento total de pedidos del cliente (para mostrar "¡Gracias por tu 5.° pedido!"), el saldo de puntos de fidelidad del cliente, campos de producto personalizados almacenados en características o atributos de productos, e información del almacén o proveedor para los productos pedidos.

Configuración de correos electrónicos multilingües

Si su tienda atiende a clientes en múltiples idiomas, cada plantilla de correo electrónico necesita una versión para cada idioma. PrestaShop gestiona la selección del idioma automáticamente basándose en la preferencia de idioma del cliente, pero usted debe proporcionar las plantillas.

Crear plantillas específicas para cada idioma

Para cada idioma que soporte su tienda, cree un directorio en la carpeta mails de su tema: /themes/su-tema/mails/en/, /themes/su-tema/mails/fr/, /themes/su-tema/mails/de/, y así sucesivamente. Copie y traduzca cada archivo de plantilla en el directorio apropiado.

No use traducción automática para correos electrónicos transaccionales. Estos correos representan la comunicación de su tienda con los clientes, y las traducciones deficientes dañan la confianza. Haga que cada versión de idioma sea escrita o revisada por un hablante nativo.

Soporte para idiomas de derecha a izquierda

Si soporta idiomas como el árabe o el hebreo, sus plantillas de correo electrónico necesitan soporte de diseño RTL (de derecha a izquierda). Añada dir="rtl" al elemento de tabla principal y ajuste la alineación del texto y el relleno en sus estilos en línea. Cree plantillas separadas para los idiomas RTL en lugar de intentar hacer que una sola plantilla funcione para ambas direcciones.

Formato de fechas y monedas

PrestaShop formatea automáticamente los valores de fechas y monedas según la configuración de idioma y moneda del cliente. Los valores {date}, {total_paid} y otros valores formateados ya reflejan la configuración regional correcta. Sin embargo, si añade variables personalizadas con valores de fecha o moneda, asegúrese de formatearlos correctamente para el idioma de destino.

Configuración SMTP para una entrega fiable

La mejor plantilla de correo electrónico del mundo es inútil si sus correos electrónicos no llegan a la bandeja de entrada. La configuración de correo electrónico predeterminada de PrestaShop utiliza la función mail() integrada de PHP, que no es fiable para correos electrónicos transaccionales. La mayoría de estos correos terminan en la carpeta de spam o son rechazados por completo por los proveedores de correo modernos.

Por qué importa el SMTP

El SMTP (Simple Mail Transfer Protocol) con autenticación adecuada es esencial para la entregabilidad del correo electrónico. Cuando envía correos electrónicos a través de la función mail() de PHP, el correo proviene de la dirección IP de su servidor web sin ninguna autenticación. Los proveedores de correo como Gmail, Outlook y Yahoo ven esto como una señal de alarma y frecuentemente clasifican estos correos como spam.

Con SMTP, sus correos electrónicos se envían a través de un servidor de correo autenticado con registros SPF, DKIM y DMARC adecuados. Esto demuestra a los servidores de correo receptores que el correo electrónico es legítimo y está autorizado por su dominio.

Configurar SMTP en PrestaShop

Vaya a Parámetros avanzados > Correo electrónico en su back office de PrestaShop. Cambie el método de "Usar la función mail() de PHP" a "Establecer mis propios parámetros SMTP". Introduzca los detalles de su servidor SMTP: la dirección del servidor, el puerto (típicamente 587 para TLS o 465 para SSL), el tipo de cifrado, el nombre de usuario y la contraseña.

Los proveedores SMTP comunes para PrestaShop incluyen Gmail SMTP (smtp.gmail.com, puerto 587, TLS, requiere una contraseña de aplicación si la 2FA está habilitada), Amazon SES (económico para grandes volúmenes), SendGrid (generoso nivel gratuito), Mailgun (amigable para desarrolladores con buena gestión de registros) y el servidor SMTP de su proveedor de hosting (consulte con su host para conocer la configuración).

Probar la configuración SMTP

Después de configurar el SMTP, use el botón "Enviar un correo electrónico de prueba" en la parte inferior de la página de configuración de correo electrónico. Introduzca su propia dirección de correo electrónico y compruebe que el correo de prueba llega a su bandeja de entrada (no al spam). Si el correo de prueba falla, verifique sus credenciales SMTP, asegúrese de que su servidor puede acceder al servidor SMTP en el puerto configurado (algunos proveedores de hosting bloquean los puertos salientes 25 y 587) y compruebe si su proveedor SMTP requiere configuraciones de seguridad específicas.

Registros SPF, DKIM y DMARC

Para la máxima entregabilidad, configure estos registros DNS para su dominio. SPF (Sender Policy Framework) especifica qué servidores están autorizados para enviar correos electrónicos en nombre de su dominio. DKIM (DomainKeys Identified Mail) añade una firma digital a sus correos electrónicos que demuestra que fueron enviados por su dominio. DMARC (Domain-based Message Authentication, Reporting, and Conformance) indica a los servidores receptores qué hacer con los correos electrónicos que no superan las comprobaciones SPF o DKIM.

Su proveedor SMTP le proporcionará los registros DNS específicos que debe añadir. Por ejemplo, si utiliza SendGrid, proporcionan registros SPF y DKIM durante el proceso de autenticación del dominio. Añádalos como registros TXT en la configuración DNS de su dominio.

Probar las plantillas de correo electrónico

Enviar correos electrónicos de prueba

PrestaShop no tiene una forma integrada de previsualizar plantillas de correo electrónico específicas. Para probar su plantilla de confirmación de pedido, necesita realizar un pedido de prueba real. Cree una cuenta de cliente de prueba, añada productos al carrito y complete el proceso de compra con un método de pago de prueba. Si tiene un módulo de pago en modo sandbox configurado, utilícelo. De lo contrario, los métodos de pago por transferencia bancaria o cheque le permiten completar un pedido sin procesamiento de pago real.

Pruebas en diferentes clientes de correo

El renderizado de correos electrónicos varía drásticamente entre los clientes de correo. Lo que se ve perfecto en Gmail puede estar roto en Outlook. Como mínimo, pruebe sus plantillas en Gmail (web), Outlook (escritorio y web), Apple Mail, Yahoo Mail y al menos una aplicación de correo móvil. Servicios como Litmus o Email on Acid automatizan estas pruebas renderizando su correo electrónico en docenas de clientes de correo simultáneamente, pero son servicios de pago.

Problemas de renderizado comunes

Si su correo electrónico se ve roto en Outlook, es casi con toda seguridad un problema de CSS. Outlook utiliza el motor de renderizado de Microsoft Word para los correos HTML, que tiene un soporte CSS extremadamente limitado. No soporta imágenes de fondo en las celdas de tabla (use colores de fondo en su lugar), padding en elementos de bloque (use padding de celdas de tabla), max-width (use anchos fijos), margin para centrar (use align="center" en tablas) ni floats CSS.

Para la responsividad móvil, envuelva su tabla de contenido en un contenedor con max-width:600px y añada una media query en el bloque de estilo del head (que algunos clientes de correo soportan) que establezca los anchos de tabla al 100% en pantallas pequeñas. Esto no es un diseño responsive perfecto, pero evita el desplazamiento horizontal en la mayoría de los dispositivos móviles.

Problemas comunes y resolución

Imágenes que faltan en los correos electrónicos

Este es el problema más común de las plantillas de correo electrónico. Las imágenes en los correos electrónicos deben usar URLs absolutas (que comiencen con https://), no rutas relativas. Si su plantilla hace referencia a /img/logo.png, cámbielo a https://www.sudominio.com/img/logo.png. La variable {shop_logo} genera automáticamente una URL absoluta, pero todas las imágenes que añada manualmente deben usar URLs completas.

Verifique también que sus imágenes sean accesibles desde fuera de su red. Si su tienda está detrás de un firewall o autenticación HTTP, los clientes de correo no pueden cargar las imágenes. Pruebe abriendo la URL de la imagen en una ventana de navegador privada/incógnita.

Diseño roto después de la edición

El HTML de correo electrónico es frágil. Una sola etiqueta sin cerrar o una celda de tabla faltante puede romper todo el diseño. Siempre valide su HTML después de editarlo. Cuente sus etiquetas de apertura y cierre de table, tr y td. Cada <table> necesita un </table>, cada <tr> necesita un </tr> y cada <td> necesita un </td>. Compruebe que cada fila en una tabla tenga el mismo número de celdas (o use colspan para compensar la diferencia).

Variables que no se reemplazan

Si ve el texto literal {nombre_variable} en sus correos electrónicos enviados en lugar de los valores reales, compruebe el nombre de la variable en busca de errores tipográficos. Los nombres de las variables distinguen entre mayúsculas y minúsculas. Verifique también que la variable exista para el tipo específico de correo electrónico que está personalizando. No todas las variables están disponibles en todas las plantillas de correo electrónico. Las variables específicas del pedido como {order_name} solo están disponibles en los correos electrónicos relacionados con pedidos.

Los correos electrónicos no se envían en absoluto

Si los correos electrónicos no se envían, compruebe el back office de PrestaShop en Parámetros avanzados > Correo electrónico. Allí puede ver un registro de los correos electrónicos enviados. Si el registro muestra fallos, compruebe su configuración SMTP. Si no aparecen correos electrónicos en el registro, es posible que el correo electrónico no se esté activando en absoluto. Verifique que las transiciones de estado de pedido estén configuradas para enviar correos electrónicos al cliente (Pedidos > Estados > editar estado > marcar "Enviar un correo electrónico al cliente").

Compruebe también el registro de errores PHP de su servidor en busca de errores relacionados con el correo electrónico. Los problemas comunes incluyen la función mail() de PHP deshabilitada por el proveedor de hosting, fallos de autenticación SMTP debido a contraseñas cambiadas y problemas de conectividad de red entre su servidor y el servidor SMTP.

Los correos electrónicos van al spam

Incluso con una configuración SMTP correcta, los correos electrónicos pueden seguir llegando al spam. Las razones más comunes son registros SPF/DKIM/DMARC faltantes o incorrectos, contenido de correo electrónico que activa los filtros de spam (uso excesivo de mayúsculas, palabras que activan el spam como "gratis" o "actúe ahora", demasiadas imágenes con poco texto), envío desde una dirección IP con mala reputación (común con el hosting compartido) y la dirección de correo electrónico "de" cuyo dominio no coincide con el dominio del servidor SMTP.

Corrija primero los registros DNS y luego revise el contenido de sus correos electrónicos. Use una herramienta como mail-tester.com para analizar sus correos electrónicos en busca de activadores de spam. Envíe un correo de prueba a la dirección que proporcionan y recibirá un informe detallado que muestra qué podría causar la clasificación como spam.

Sobrescrituras de correo electrónico específicas del tema

Algunos temas de PrestaShop incluyen sus propias plantillas de correo electrónico que coinciden con el diseño del tema. Si su tema tiene plantillas en /themes/su-tema/mails/, estas sobrescriben automáticamente las plantillas del núcleo.

Comprobar las plantillas de correo electrónico del tema

Busque en el directorio de su tema activo una carpeta mails. Si existe, el tema proporciona plantillas de correo electrónico personalizadas. Estas plantillas suelen coincidir con la paleta de colores y el diseño del encabezado/pie de página del tema, dando a sus correos electrónicos coherencia visual con su escaparate.

Personalizar las plantillas de correo electrónico del tema

Si su tema proporciona plantillas de correo electrónico, edite esas en lugar de copiar del directorio mails/ del núcleo. Las plantillas del tema pueden usar una estructura HTML diferente o incluir CSS adicional específico del sistema de diseño del tema. Partir de la versión del tema garantiza la coherencia visual.

Mantener las plantillas sincronizadas con las actualizaciones del tema

Cuando actualice su tema, compruebe si la actualización incluye cambios en las plantillas de correo electrónico. Si es así, sus personalizaciones podrían sobrescribirse. Antes de actualizar, haga una copia de seguridad de sus plantillas personalizadas. Después de actualizar, compare las nuevas plantillas con sus copias de seguridad y vuelva a aplicar sus personalizaciones a las versiones actualizadas. Esto es tedioso pero necesario para mantener tanto sus personalizaciones como las posibles mejoras o correcciones que el desarrollador del tema haya realizado.

Mejores prácticas para correos electrónicos de confirmación de pedido

Un correo electrónico de confirmación de pedido bien elaborado hace más que confirmar la transacción. Genera confianza, reduce las consultas de soporte y crea oportunidades de fidelización.

Incluya un número de referencia de pedido claro y destacado en la parte superior. Los clientes necesitan este número cuando contactan con soporte o hacen seguimiento de su pedido. Liste cada producto con su nombre, cantidad, precio y todas las opciones o personalizaciones. Incluya el desglose completo de subtotal, costos de envío, impuestos, descuentos y total. Muestre la dirección de entrega para que los clientes puedan verificarla y contactarle inmediatamente si es incorrecta. Indique el método de pago utilizado y cualquier detalle de transacción relevante. Proporcione un enlace a la página de seguimiento del pedido o al historial de pedidos del cliente en su cuenta. Añada su información de contacto de servicio al cliente para que los clientes sepan cómo comunicarse con usted si algo no está bien.

Mantenga el diseño limpio y adaptado a dispositivos móviles. Más de la mitad de todos los correos electrónicos se leen en dispositivos móviles. Use un diseño de una sola columna, texto grande y legible (mínimo 14px para el texto del cuerpo) y botones con objetivos táctiles adecuados (mínimo 44px de altura). Su correo electrónico de confirmación de pedido es un reflejo de la profesionalidad de su tienda. Invierta el tiempo necesario para hacerlo bien.

Why Regular Technical Audits Matter

PrestaShop stores degrade over time. Modules get installed and forgotten. PHP versions fall behind. Error logs fill up with warnings that nobody reads. Database tables grow bloated with abandoned cart data and expired sessions. Security patches go unapplied. Each of these issues is small on its own, but together they compound into slow page loads, security vulnerabilities, and eventually downtime or data loss.

The problem is that most store owners only discover these issues when something breaks. A customer complains about slow checkout. Google drops your rankings because your site fails Core Web Vitals. Or worse, you discover your admin panel is compromised because you never changed the default admin path and your PHP version had a known vulnerability.

A 30-minute technical health audit, performed monthly, prevents all of this. It is not a deep dive into every configuration setting. It is a focused checklist that catches the most common and most dangerous issues before they become emergencies. This guide walks through each check with approximate time estimates, giving you a repeatable process you can follow every month.

Check 1: PHP Version and Configuration (3 Minutes)

PHP is the engine that runs PrestaShop, and running an outdated version is both a performance and security risk. PHP versions receive active support for two years and security fixes for one additional year after that. After that, known vulnerabilities go unpatched.

Checking Your PHP Version

Go to your PrestaShop back office and navigate to Advanced Parameters > Information. The PHP version is listed in the Server Information section. Alternatively, you can check in your hosting control panel (cPanel, Plesk, or similar).

As of 2026, the actively supported PHP versions are 8.2, 8.3, and 8.4. If you are running PHP 8.1 or older, upgrading should be a priority. PrestaShop 8.x requires PHP 7.2 or later but performs significantly better on PHP 8.1 and above. PrestaShop 1.7.x supports PHP 7.1 through 8.1, depending on the specific version.

Key PHP Settings to Verify

While on the Information page, check these PHP configuration values:

memory_limit should be at least 256M for PrestaShop. If it is lower, you may experience white pages or incomplete operations when handling large catalogs or generating reports.

max_execution_time should be at least 300 (5 minutes). Lower values can cause timeouts during import operations, cache rebuilds, and module installations.

upload_max_filesize and post_max_size should be at least 16M, or higher if you regularly upload large product images or import files.

OPcache should be enabled. OPcache stores compiled PHP code in memory, dramatically reducing page load times. If it is disabled, your store is running significantly slower than it could be.

Check 2: Error Log Review (4 Minutes)

Error logs tell you what is breaking behind the scenes, even when the front end appears to work normally. Warnings and notices that do not crash the page still indicate problems that waste server resources and can escalate into real failures.

PrestaShop Logs

In the back office, go to Advanced Parameters > Logs. Sort by date (newest first) and scan the last week of entries. Focus on Severity 3 (Error) and Severity 4 (Critical) messages. Common critical errors include database connection failures, file permission errors, module exceptions, and payment processing errors.

If you see repeated errors from the same module, that module has a bug that needs attention. If you see database errors, your database server may be running out of connections or disk space.

PHP Error Log

The PHP error log location depends on your hosting environment. Common locations include /var/log/php/error.log, /var/log/apache2/error.log, or a path specified in your hosting control panel. Check the last 100 lines for fatal errors, warnings, and deprecation notices.

Deprecation notices are especially important to track. They warn you that a function or feature your code uses will be removed in a future PHP version. Addressing these now prevents your store from breaking when you upgrade PHP.

What to Do with Errors

Do not try to fix every error during the audit. The audit is for identification. Create a list of the most critical and most frequent errors, prioritized by severity. Fatal errors and critical errors need immediate attention. Warnings should be addressed within the month. Notices and deprecation warnings can be scheduled for your next maintenance window.

Check 3: Module Audit (5 Minutes)

Modules are the most common source of security vulnerabilities, performance problems, and compatibility issues in PrestaShop. A quick module audit identifies dead weight and potential risks.

Identifying Unused Modules

Go to Modules > Module Manager. Look for modules that are installed but disabled. These modules still have files on your server and potentially have database tables, but they are not serving any purpose. They increase your attack surface (a vulnerability in a disabled module's files can still be exploited) and slow down backups.

For each disabled module, decide whether you will use it again. If not, uninstall it completely (not just disable). Uninstalling removes the module's database tables and configuration. After uninstalling, also delete the module's directory from /modules/ to remove its files from the server entirely.

Checking for Updates

In the Module Manager, look for modules with available updates. Outdated modules are a primary vector for security exploits. Update notifications appear as badges on the module listing. Prioritize updates for modules that handle sensitive data: payment modules, customer account modules, and any module that processes forms.

Before updating any module, check the changelog to understand what changed. If the update includes security fixes, apply it immediately. If it is a feature update, test it on a staging environment first if possible.

Counting Total Modules

Check how many modules are installed in total. PrestaShop ships with many modules by default, and stores accumulate more over time. Each active module adds hooks that execute on every page load, increasing response time. If you have more than 80 to 100 active modules, review the list critically. Many default PrestaShop modules (like the social sharing buttons, customer data privacy notice, and statistics modules) can be disabled if you do not use them, resulting in measurable performance improvement.

Check 4: Database Health (4 Minutes)

Your PrestaShop database grows continuously. Every customer visit creates session data. Every abandoned cart stays in the database. Every log entry accumulates. Over months and years, this bloat slows down queries and increases backup times.

Checking Database Size

In your hosting control panel (cPanel > phpMyAdmin, for example), check the total database size. A healthy PrestaShop database for a small to medium store (under 10,000 products) should be under 500 MB. If yours is significantly larger, data bloat is likely the cause.

Identifying Large Tables

In phpMyAdmin, click on your database and sort tables by size. The usual culprits for bloat are: ps_connections and ps_connections_page (visitor tracking data that can grow to gigabytes), ps_log (PrestaShop's internal log table), ps_mail (email history), ps_cart and ps_cart_product (abandoned cart data), ps_guest (anonymous visitor records), and ps_pagenotfound (404 error tracking).

These tables can be safely cleaned of old data. For example, you do not need connection data from two years ago. PrestaShop has a built-in feature for cleaning some of these tables: go to Advanced Parameters > Administration and look for the "Automatically check for module updates" and data cleanup options. For more thorough cleanup, the free PrestaShop Cleaner module can purge old statistics data, abandoned carts, and expired sessions.

Checking for Missing Indexes

While in phpMyAdmin, check the structure of your most important tables (ps_product, ps_category_product, ps_stock_available) and verify that indexes exist on the columns used in search and filtering. Missing indexes cause slow queries that affect page load times. However, do not add indexes without understanding the trade-offs, as each index slows down write operations slightly.

Check 5: Security Basics (5 Minutes)

Security vulnerabilities in PrestaShop stores are actively exploited. Automated scanners continuously probe the internet for vulnerable installations. Five minutes of security checks can prevent a catastrophic breach.

Admin Panel URL

Your admin panel should not be accessible at a predictable URL like /admin/ or /backoffice/. PrestaShop generates a randomized admin directory name during installation (like /admin738xyz/). Verify that your admin URL is still randomized by checking the admin directory name on your server. If someone has renamed it to something guessable, rename it back to a random string.

SSL Certificate

Your entire store must run on HTTPS. Check by visiting your store's URL with http:// and verifying that it redirects to https://. In the back office, go to Shop Parameters > General and verify that "Enable SSL" and "Enable SSL on all pages" are both set to Yes.

Also check your SSL certificate's expiration date. Let's Encrypt certificates expire every 90 days and should auto-renew, but auto-renewal fails silently more often than you would expect. Click the padlock icon in your browser's address bar to see the certificate details and expiration date. If it expires within the next 30 days, verify that auto-renewal is configured and working.

File Permissions

Incorrect file permissions are a security risk. On Linux servers, your PrestaShop files should generally be owned by the web server user (typically www-data or apache) and have these permissions: directories at 755 (owner can read/write/execute, others can read/execute), files at 644 (owner can read/write, others can read only), and configuration files like config/settings.inc.php or app/config/parameters.php at 640 or 440 (restricted read access).

Check a few critical files to verify permissions are not too open. No file should be 777 (world-writable). If you find 777 permissions, fix them immediately. They allow any user on the server to modify those files.

Debug Mode

Verify that debug mode is disabled on your production store. Debug mode exposes detailed error messages, file paths, and database queries to visitors, which is valuable information for attackers. Check the file /config/defines.inc.php and ensure _PS_MODE_DEV_ is set to false. In PrestaShop 8.x, also check the .env file for the APP_DEBUG setting.

Known Vulnerabilities

Check whether your PrestaShop version has known security vulnerabilities. Visit the PrestaShop security advisories page and compare the listed versions with yours. If your version is affected by any advisory that you have not patched, prioritize applying the fix.

Check 6: Performance Quick Test (4 Minutes)

Performance directly affects conversion rates. Every additional second of page load time reduces conversions measurably. A quick performance test identifies major bottlenecks.

Running a Lighthouse Audit

Open Google Chrome, navigate to your store's homepage, open Chrome DevTools (F12), and click the Lighthouse tab. Run an audit for Performance, Best Practices, and SEO on a Mobile device. The test takes about 30 seconds.

Focus on the Performance score. A score below 50 indicates serious performance problems. Between 50 and 89 means there is room for improvement. Above 90 is good. The audit report shows specific issues and estimates of how much time each fix would save.

Key Metrics to Check

From the Lighthouse report, pay attention to Largest Contentful Paint (LCP), which measures how long it takes for the main content to appear. It should be under 2.5 seconds. First Input Delay (FID) or Interaction to Next Paint (INP) measures responsiveness. It should be under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability. It should be under 0.1.

If LCP is high, the most common causes in PrestaShop are unoptimized images (large product images served without compression or proper sizing), slow server response time (check your hosting plan and database performance), render-blocking CSS and JavaScript (disable unnecessary modules that add their assets to every page), and disabled caching (Smarty cache and CCC should be enabled in production).

Checking Cache Configuration

In the back office, go to Advanced Parameters > Performance. Verify these settings: Smarty cache should be Yes with the cache type set to "File". CCC (Combine, Compress, Cache) should have CSS and JavaScript minification and combination enabled. Template compilation should be set to "Recompile templates if the files have been updated" (not "Force compilation" which is for development only).

If any of these are misconfigured, fixing them provides an immediate and noticeable performance improvement.

Check 7: SEO Basics (3 Minutes)

Technical SEO issues prevent search engines from properly crawling and indexing your store. A few quick checks catch the most impactful problems.

Robots.txt

Visit yourdomain.com/robots.txt in your browser. Verify that it exists and contains sensible rules. PrestaShop generates a robots.txt file automatically. Check that it is not blocking important pages. Your product pages, category pages, and CMS pages should not be disallowed. Common mistakes include blocking all URLs with parameters (which blocks filtered category pages and search results) and blocking the /modules/ directory (which can prevent CSS and JavaScript from being loaded by search engine renderers).

Also verify that the robots.txt includes a sitemap directive pointing to your XML sitemap: Sitemap: https://www.yourdomain.com/1_index_sitemap.xml.

XML Sitemap

Visit the sitemap URL listed in your robots.txt. Verify that it loads, that it is recent (check the last modification dates), and that it contains your important pages. If the sitemap is outdated or empty, regenerate it. If you use the built-in PrestaShop sitemap generator, go to Modules > Module Manager, find the Google Sitemap module, and click Configure to regenerate.

Check the number of URLs in the sitemap against your expected count. If you have 1,000 products but the sitemap only lists 200 URLs, something is wrong with the generation process. Common causes include products being disabled or out of stock being excluded from the sitemap, category visibility settings filtering out products, and the sitemap generation process timing out before completing.

Canonical URLs

Visit a few product pages and view the page source (Ctrl+U). Look for the <link rel="canonical"> tag in the head section. It should contain the clean URL of the current page without any query parameters. If canonical tags are missing or incorrect, duplicate content issues will harm your SEO. In the back office, go to Shop Parameters > Traffic & SEO and verify that "Disable Apache's MultiViews option" and "Disable Apache's mod_security module" are configured correctly for your server.

Check 8: Backup Verification (3 Minutes)

Backups that have never been tested are not backups. They are wishful thinking. This check verifies that your backup system is actually working.

Checking Backup Recency

Determine where your backups are stored. This varies by hosting provider. Check your hosting control panel for backup tools (cPanel has a Backup section, Plesk has a Backup Manager). If you use a backup module in PrestaShop, check its configuration and recent backup log.

Your most recent backup should be no more than 24 hours old for active stores. If your last backup is older than a week, your backup system is either not configured, not running, or failing silently. Fix this immediately. Data loss from a server failure or hack without a recent backup can be business-ending.

Verifying Backup Completeness

A complete PrestaShop backup includes the entire database (all tables, not just product data) and the file system (all PrestaShop files, including uploaded images, module files, and theme customizations). Many backup solutions only capture the database or only capture the files. Verify that yours captures both.

Check the backup file sizes. A database backup for a small store should be at least several megabytes. If it is suspiciously small (under 1 MB for an active store), it might be empty or corrupted. A file backup should include your /img/ directory, which is typically the largest directory and can be several gigabytes for stores with many product images.

Offsite Backup Storage

Backups stored on the same server as your store are vulnerable to the same failures. If the server's hard drive fails, you lose both the store and the backup. Verify that your backups are copied to a separate location: a different server, cloud storage (like Amazon S3, Google Cloud Storage, or Dropbox), or downloaded to a local computer.

Check 9: Update Status (2 Minutes)

Running outdated software is the single most common reason PrestaShop stores get hacked. This final check verifies that your core installation and critical modules are up to date.

PrestaShop Core Version

Check your current PrestaShop version in the back office footer or on the Advanced Parameters > Information page. Compare it against the latest stable release on the PrestaShop website or GitHub releases page. If you are more than one minor version behind (for example, running 8.1.2 when 8.1.5 is available), plan an update. If you are running a version with known security vulnerabilities, update urgently.

PrestaShop major version upgrades (like 1.7 to 8.x) are complex migration projects, not simple updates. Do not attempt these without thorough planning and testing. But minor version updates (like 8.1.2 to 8.1.5) are generally safe and primarily contain security and bug fixes.

Critical Module Updates

Some modules handle sensitive operations and must be kept current: payment modules (any module that processes credit cards, PayPal, or other payment methods), the PrestaShop autoupgrade module (used for core updates), and any security-related modules. Check the Module Manager for available updates on these specific modules.

Your 30-Minute Audit Checklist Summary

Here is the complete checklist with time allocations that you can follow each month:

Minutes 1-3: PHP Version and Configuration. Check PHP version is supported. Verify memory_limit, max_execution_time, and OPcache status.

Minutes 4-7: Error Log Review. Scan PrestaShop logs for Severity 3 and 4 entries. Check PHP error log for fatal errors and deprecation notices. Note recurring errors for follow-up.

Minutes 8-12: Module Audit. Review disabled modules and uninstall unused ones. Check for available updates, especially on payment and security modules. Count total active modules and identify candidates for removal.

Minutes 13-16: Database Health. Check total database size. Identify bloated tables. Plan cleanup of old connection, log, and cart data.

Minutes 17-21: Security Basics. Verify admin URL is randomized. Check SSL certificate and expiration. Verify file permissions. Confirm debug mode is off. Check for known vulnerabilities in your version.

Minutes 22-25: Performance Quick Test. Run Lighthouse audit on homepage. Check LCP, INP, and CLS metrics. Verify cache and CCC settings in back office.

Minutes 26-28: SEO Basics. Check robots.txt for errors. Verify sitemap is current and complete. Spot-check canonical URLs on product pages.

Minutes 29-30: Backup and Updates. Verify backup recency and completeness. Check PrestaShop core and critical module versions against latest releases.

This audit does not fix problems. It identifies them. After completing the checklist, you should have a prioritized list of issues to address. Critical security issues and broken functionality come first. Performance optimizations and cleanup tasks come second. Minor improvements and future planning come third. By performing this audit monthly, you catch problems early, maintain a clear picture of your store's technical health, and avoid the nasty surprises that come from months of neglected maintenance.

Lazy Loading en 2026: que manejan los navegadores de forma nativa y que necesita un modulo

El lazy loading es una tecnica de optimizacion del rendimiento que aplaza la carga de recursos fuera de pantalla hasta que el usuario se desplaza cerca de ellos. En 2026, el soporte nativo de los navegadores para lazy loading ha madurado significativamente, pero todavia hay escenarios donde los propietarios de tiendas PrestaShop necesitan modulos adicionales o implementaciones personalizadas. Esta guia explica exactamente que manejan los navegadores por si solos, que brechas quedan y como implementar la mejor estrategia de lazy loading para tu tienda PrestaShop.

Que cubre el lazy loading nativo en 2026

El atributo HTML loading="lazy" ahora esta soportado por mas del 95% de los navegadores a nivel mundial. Esto incluye Chrome (desde v77), Firefox (desde v75), Safari (desde v15.4), Edge (desde v79) y todos los navegadores basados en Chromium.

Como funciona el lazy loading nativo

<img src="imagen-producto.jpg" 
     loading="lazy" 
     width="800" 
     height="600" 
     alt="Nombre del producto">

Que manejan los navegadores nativamente

Que los navegadores NO manejan

Implementar lazy loading nativo en PrestaShop

Para temas PrestaShop 8.x y 9.x

{* Antes - sin lazy loading *}
<img src="{$product.cover.bySize.home_default.url}" 
     alt="{$product.name}">

{* Despues - con lazy loading nativo *}
<img src="{$product.cover.bySize.home_default.url}" 
     loading="lazy" 
     width="{$product.cover.bySize.home_default.width}"
     height="{$product.cover.bySize.home_default.height}"
     alt="{$product.name}">

Regla critica: nunca apliques lazy loading a imagenes above-the-fold

El error mas comun del lazy loading es aplicarlo a imagenes visibles sin desplazamiento. Esto en realidad perjudica el rendimiento porque el navegador retrasa la carga del contenido que el usuario ve inmediatamente.

Imagenes que NO deben ser lazy loaded:

• El logo de tu tienda
• Imagenes hero/banner en la parte superior de la pagina
• Las primeras 1-2 imagenes de producto en paginas de categoria

<img src="hero-banner.jpg" 
     loading="eager" 
     fetchpriority="high" 
     width="1200" 
     height="400" 
     alt="Banner promocion de verano">

Cuando necesitas un modulo: imagenes de fondo CSS

Los temas PrestaShop frecuentemente usan imagenes de fondo CSS para sliders, banners y cabeceras de categoria.

document.addEventListener('DOMContentLoaded', function() {
    const lazyBackgrounds = document.querySelectorAll('[data-bg]');
    const observer = new IntersectionObserver(function(entries) {
        entries.forEach(function(entry) {
            if (entry.isIntersecting) {
                entry.target.style.backgroundImage = 'url(' + entry.target.dataset.bg + ')';
                observer.unobserve(entry.target);
            }
        });
    }, { rootMargin: '200px 0px' });
    lazyBackgrounds.forEach(function(bg) { observer.observe(bg); });
});

Cuando necesitas un modulo: efectos placeholder

• Efecto blur-up (LQIP) - Carga primero una version pequena y borrosa
• Pantallas esqueleto - Bloques placeholder grises
• Placeholders de color dominante - Usa el color dominante de la imagen como fondo

Impacto en rendimiento y Core Web Vitals

• LCP - El lazy loading de imagenes above-the-fold PERJUDICA el LCP
• CLS - Imagenes sin atributos width/height causan cambios de diseno
• INP - Menos recursos cargandose simultaneamente mejoran la interactividad

<!-- MAL - causa cambio de diseno -->
<img src="producto.jpg" loading="lazy" alt="Producto">

<!-- BIEN - reserva espacio -->
<img src="producto.jpg" loading="lazy" 
     width="400" height="400" alt="Producto">

Recomendaciones especificas para PrestaShop

Paginas de listado de productos

Lazy loadear todas las imagenes de producto excepto la primera fila. Aplicar fetchpriority="high" a la primera fila.

Paginas de detalle de producto

La imagen principal debe cargarse eager con fetchpriority="high". Las miniaturas de la galeria pueden ser lazy loaded.

Resumen: Modulo vs. Nativo

Limitacion de velocidad y proteccion contra bots para PrestaShop sin WAF

Los bots representan mas del 40% del trafico web en 2026. Esta guia muestra como implementar proteccion efectiva usando solo configuracion del servidor, reglas .htaccess y modulos ligeros.

Metodo 1 - Rate Limiting Apache .htaccess

RewriteCond %{HTTP_USER_AGENT} (SemrushBot|AhrefsBot|MJ12bot) [NC]
RewriteRule .* - [F,L]

Metodo 2 - Rate Limiting Nginx

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location ~ /login$ {
    limit_req zone=login burst=3 nodelay;
}

Metodo 3 - fail2ban contra brute force

fail2ban monitorea los logs del servidor y bloquea automaticamente las IPs maliciosas.

Metodo 4 - Rate Limiting a nivel PHP

Para hosting compartido: rate limiter basado en archivos en PHP.

Metodo 5 - robots.txt y control de crawling

User-agent: SemrushBot
Crawl-delay: 10

Metodo 6 - CAPTCHA en formularios criticos

Agregar reCAPTCHA en login, registro, contacto y newsletter.

Metodo 7 - Cloudflare Free

Browser Integrity Check, Bot Fight Mode y Rate Limiting estan disponibles gratis.

Resumen de capas de proteccion

Redirecciones .htaccess en PrestaShop: escribir reglas sin romper tu tienda

El archivo .htaccess es uno de los archivos mas poderosos y peligrosos en tu instalacion PrestaShop. Un solo caracter mal colocado puede dejar toda tu tienda fuera de linea. Pero dominar las redirecciones .htaccess es esencial para el SEO.

Como PrestaShop usa .htaccess

PrestaShop genera y gestiona automaticamente el archivo .htaccess. Cuando activas las URLs amigables en la configuracion SEO y URLs, PrestaShop escribe reglas de reescritura entre dos comentarios marcadores.

Regla critica - Nunca agregues tus redirecciones personalizadas dentro de este bloque. PrestaShop las sobreescribira en la proxima regeneracion. Coloca tus reglas ANTES del bloque PrestaShop.

Tipos de redirecciones

301 - Redireccion permanente

Usa cuando una pagina se ha movido permanentemente. Los motores de busqueda transfieren el valor SEO a la nueva URL.

302 - Redireccion temporal

Usa cuando una pagina esta temporalmente no disponible.

410 - Gone (Eliminado)

Usa cuando una pagina ha sido eliminada permanentemente sin reemplazo.

Sintaxis basica de redirecciones

Redirect 301 /pagina-antigua.html https://tutienda.com/pagina-nueva.html
Redirect 301 /producto-antiguo.html https://tutienda.com/es/producto-nuevo.html

Redirecciones basadas en patrones con RewriteRule

RewriteEngine On
RewriteRule ^carpeta-antigua/(.*)$ https://tutienda.com/carpeta-nueva/$1 [R=301,L]

Escenarios comunes de redireccion PrestaShop

Escenario 1 - Migracion desde otra plataforma

RewriteRule ^product/slug-antiguo/?$ https://tutienda.com/es/nueva-url.html [R=301,L]

Escenario 2 - Forzar HTTPS y WWW

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Reglas que pueden romper PrestaShop

Bucles de redireccion infinitos

El error mas peligroso. Siempre usa condiciones para prevenir bucles.

# PELIGROSO
RewriteRule ^(.*)$ https://tutienda.com/$1 [R=301,L]

# SEGURO
RewriteCond %{HTTP_HOST} !^www\.tutienda\.com$ [NC]
RewriteRule ^(.*)$ https://www.tutienda.com/$1 [R=301,L]

Romper el acceso al back office

# SEGURO - excluir admin y API
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteCond %{REQUEST_URI} !^/api [NC]
RewriteRule ^(.*)$ https://tutienda.com/es/$1 [R=301,L]

Probar redirecciones de forma segura

cp .htaccess .htaccess.backup
curl -I -L https://tutienda.com/pagina-antigua.html

Donde colocar las reglas personalizadas

# TUS REDIRECCIONES AQUI (antes del bloque PrestaShop)
Redirect 301 /pagina-antigua.html https://tutienda.com/pagina-nueva.html

# ~~start~~ Bloque PrestaShop
# ... reglas auto-generadas ...
# ~~end~~ Bloque PrestaShop

Cuando usar un modulo

Considera un modulo de redirecciones cuando personal no tecnico necesite gestionar redirecciones, tengas cientos de redirecciones, o necesites deteccion automatica de 404.

Matriz de compatibilidad de versiones PHP para PrestaShop

Elegir la versión correcta de PHP para tu tienda PrestaShop es una de las decisiones de infraestructura más críticas que tomarás. Ejecutar una versión PHP incompatible puede causar pantallas en blanco, flujos de pago defectuosos, fallos en módulos y vulnerabilidades de seguridad. Esta guía completa cubre cada versión de PrestaShop desde 1.6 hasta 9.x y asocia cada una con sus versiones PHP compatibles, configuraciones recomendadas y consideraciones de actualización.

Por qué la versión PHP importa para PrestaShop

PHP es el lenguaje del lado del servidor que impulsa PrestaShop. Cada versión principal de PHP introduce mejoras de rendimiento, nuevas características del lenguaje y depreca funciones más antiguas. El código fuente de PrestaShop evoluciona en paralelo con PHP, lo que significa que las versiones más recientes de PrestaShop aprovechan las características modernas de PHP mientras abandonan el soporte para las obsoletas.

Usar la versión PHP incorrecta causa tres categorías de problemas:

• Errores fatales - Las funciones eliminadas en versiones PHP más recientes (por ejemplo, las funciones mysql_* eliminadas en PHP 7.0, each() eliminada en PHP 8.0) causan fallos inmediatos.
• Advertencias de deprecación - Las funciones deprecadas generan advertencias que pueden romper las respuestas AJAX, la salida JSON y la generación de PDF cuando display_errors está habilitado.
• Exposición a riesgos de seguridad - Las versiones PHP que han llegado al final de su vida útil ya no reciben parches de seguridad, dejando tu tienda vulnerable.

Matriz de compatibilidad completa

PrestaShop 1.6.x

PHP recomendado para 1.6.x - PHP 7.1. Ofrece el mejor equilibrio entre rendimiento y compatibilidad. Ejecutar 1.6.x en PHP 7.2+ requiere modificaciones en archivos del núcleo que interrumpen la ruta de actualización y no es recomendable.

PrestaShop 1.7.x

Advertencia crítica - Ninguna versión de PrestaShop 1.7 soporta PHP 8.0 o posterior. Si ejecutas PS 1.7.6 en PHP 8, Smarty se bloqueará inmediatamente porque el motor de plantillas utiliza funciones eliminadas en PHP 8.0. La eliminación de la función each() y los cambios en el funcionamiento de array_key_exists() con objetos causan errores fatales.

PrestaShop 8.x

PHP recomendado para 8.x - PHP 8.1. Es el punto óptimo que ofrece compatibilidad completa, soporte de seguridad activo y excelente rendimiento con compilación JIT. PHP 8.1 trae fibers, enums, propiedades readonly y tipos intersection que PrestaShop 8 puede aprovechar.

PrestaShop 9.x

PHP recomendado para 9.x - PHP 8.3 o 8.4. PrestaShop 9 funciona con Symfony 6.4 LTS y requiere PHP 8.1 como mínimo. PHP 8.4 introduce Property Hooks y visibilidad asimétrica que futuras actualizaciones de PrestaShop aprovecharán.

Fechas de fin de vida de PHP que debes conocer

Si en 2026 estás usando PHP 7.4 o 8.0, estás operando con una versión no soportada que ya no recibe parches de seguridad. Este es un riesgo crítico para cualquier tienda de comercio electrónico que maneja datos de pago.

Cómo verificar tu versión PHP actual

Método 1 - Back Office de PrestaShop

Navega a Parámetros avanzados > Información. La sección Información del servidor muestra tu versión PHP, junto con el límite de memoria, tiempo máximo de ejecución y otras configuraciones relevantes.

Método 2 - Archivo PHP Info

Crea un archivo llamado phpinfo.php en el directorio raíz de tu tienda con este contenido:

<?php phpinfo();

Accede a él a través de tu navegador en https://tutienda.com/phpinfo.php. Elimina este archivo inmediatamente después de verificar - expone detalles sensibles de configuración del servidor.

Método 3 - Línea de comandos

php -v
php -r "echo PHP_VERSION;"

Ten en cuenta que la versión PHP del CLI puede diferir de la versión PHP del servidor web. Verifica siempre a través de la interfaz web o phpinfo().

Problemas comunes con la versión PHP incorrecta

Pantalla blanca de la muerte (WSOD)

El síntoma más común de incompatibilidad PHP. Revisa tu log de errores PHP (normalmente en /var/log/php-errors.log o accesible a través de tu panel de hosting). Errores típicos:

Fatal error: Uncaught Error: Call to undefined function mysql_connect()
Fatal error: Uncaught Error: Call to undefined function each()
Fatal error: Cannot use "parent" when current class scope has no parent

Las advertencias de deprecación rompen AJAX

Cuando display_errors = On y actualizas PHP, los avisos de deprecación se anteponen a las respuestas AJAX. Esto rompe el parsing JSON en el back office, causando que funciones como la búsqueda de productos, búsqueda de clientes y creación de pedidos fallen silenciosamente. La solución:

; php.ini
display_errors = Off
log_errors = On
error_log = /ruta/hacia/php-error.log

Incompatibilidad de módulos

Los módulos de terceros pueden no soportar tu versión PHP. Antes de actualizar PHP, verifica la compatibilidad de cada módulo instalado. Áreas problemáticas comunes:

• Módulos que usan create_function() - eliminada en PHP 8.0
• Módulos que usan funciones mysql_* - eliminadas en PHP 7.0
• Módulos que usan acceso posicional a cadenas con llaves $str{0} - eliminado en PHP 8.0
• Módulos que no manejan tipos de retorno nullable - más estrictos desde PHP 8.1+

Cómo actualizar PHP para PrestaShop de forma segura

Paso 1 - Auditar tu configuración actual

Antes de cambiar nada, documenta tu entorno actual:

php -v                    # Versión PHP actual
php -m                    # Extensiones cargadas
php -i | grep memory      # Límite de memoria
php -i | grep max_exec    # Límite de tiempo de ejecución

Paso 2 - Verificar la compatibilidad de módulos

Revisa cada módulo instalado. Consulta la documentación del desarrollador del módulo sobre el soporte de versiones PHP. Si un módulo no se ha actualizado en más de dos años, es probable que sea incompatible con PHP 8.x.

Paso 3 - Probar primero en staging

Nunca actualices PHP en tu servidor de producción sin pruebas previas. Crea una copia staging de tu tienda y prueba con la nueva versión PHP. Verifica:

• Las páginas del front office cargan correctamente
• Páginas de producto, páginas de categoría, páginas CMS
• El proceso de carrito y checkout se completa
• Los módulos de pago procesan transacciones de prueba
• La funcionalidad del back office funciona (edición de productos, gestión de pedidos)
• Todos los módulos de terceros funcionan correctamente
• Los cron jobs se ejecutan sin errores

Paso 4 - Actualización con plan de rollback

La mayoría de los proveedores de hosting permiten cambiar la versión PHP desde el panel de control (cPanel, Plesk, DirectAdmin). Mantén la versión PHP anterior disponible para un rollback rápido si surgen problemas.

Paso 5 - Limpiar todas las cachés después de la actualización

Después de cambiar la versión PHP, limpia cada capa de caché:

# Limpiar la caché de PrestaShop
rm -rf var/cache/prod/* var/cache/dev/*

# Limpiar las plantillas Smarty compiladas
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

# Si usas OPcache, reiniciar PHP-FPM
systemctl restart php8.3-fpm

# Limpiar la caché del CDN (Cloudflare, etc.)

Mejores prácticas de configuración PHP para PrestaShop

Independientemente de la versión PHP elegida, estas configuraciones son esenciales para un rendimiento óptimo de PrestaShop:

; Configuraciones php.ini recomendadas
memory_limit = 512M
max_execution_time = 300
max_input_vars = 10000
post_max_size = 32M
upload_max_filesize = 32M

; Configuraciones OPcache (críticas para el rendimiento)
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 16229
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1

; Extensiones requeridas
extension = intl
extension = zip
extension = gd
extension = curl
extension = mbstring
extension = openssl
extension = pdo_mysql
extension = fileinfo

Consideraciones para desarrolladores de módulos

Si desarrollas módulos de PrestaShop, debes considerar cuidadosamente la compatibilidad PHP:

• Versión PHP mínima - Apunta a PHP 7.2 como mínimo para módulos que deben funcionar en PrestaShop 8.0+, o PHP 8.1 para módulos exclusivos de PrestaShop 9.
• Usa PHPStan o Psalm - Las herramientas de análisis estático detectan incompatibilidades de versión PHP antes que tus usuarios.
• Evita la sintaxis específica de versión - Características como las expresiones match (PHP 8.0), los enums (PHP 8.1) y las propiedades readonly (PHP 8.1) limitan tu módulo a esas versiones PHP y superiores.
• Prueba en múltiples versiones - Usa contenedores Docker con diferentes versiones PHP para probar tu módulo en todo el rango de compatibilidad.

Preguntas frecuentes

¿Puedo ejecutar PrestaShop 1.7 en PHP 8?

No. Ninguna versión de PrestaShop 1.7 soporta oficialmente PHP 8.0 o posterior. Aunque algunos usuarios han aplicado parches para hacerlo funcionar parcialmente, esto no está soportado y causará problemas con las actualizaciones. El camino correcto es migrar a PrestaShop 8.x.

¿Debería usar PHP 8.4 con PrestaShop 8.1?

No recomendado. PrestaShop 8.1 fue desarrollado y probado principalmente con PHP 8.1. Aunque PHP 8.2 tiene soporte parcial en versiones 8.1.x posteriores, PHP 8.4 introduce cambios que pueden causar problemas con componentes Symfony más antiguos. Quédate con PHP 8.1 para PrestaShop 8.x.

¿Cuánto más rápido es PHP 8.x en comparación con 7.x?

Los benchmarks muestran que PHP 8.1 es aproximadamente 20-30% más rápido que PHP 7.4 para cargas de trabajo típicas de PrestaShop. El compilador JIT proporciona el mayor beneficio para tareas computacionales. Para operaciones vinculadas a E/S (consultas de base de datos, lectura de archivos), la mejora es menor pero aún medible.

¿Actualizar PHP requiere actualizar PrestaShop?

No necesariamente, pero ambos van de la mano. Puedes actualizar PHP dentro del rango soportado para tu versión de PrestaShop sin actualizar PrestaShop en sí. Sin embargo, si quieres usar una versión PHP moderna (8.3+), necesitarás PrestaShop 8.1 o 9.x.

What Content Security Policy Is and Why It Matters

Content Security Policy (CSP) is a security mechanism implemented through HTTP headers that tells the browser exactly which resources are allowed to load on your pages. It prevents cross-site scripting (XSS) attacks, data injection attacks, and other code injection vulnerabilities by giving you granular control over where JavaScript, CSS, images, fonts, frames, and other resources can originate from.

Without CSP, a browser will execute any JavaScript it encounters on your page, regardless of where it came from. If an attacker manages to inject a malicious script (through a vulnerable module, a compromised third-party library, or a stored XSS vulnerability), the browser happily executes it with full access to the page content, including customer data, form inputs, and session cookies.

With CSP, you declare a whitelist of trusted sources. If the browser encounters a resource that does not match the policy, it blocks it and logs a violation. This means that even if an attacker finds a way to inject code into your page, the browser refuses to execute it because it does not come from an approved source.

For PrestaShop stores that handle customer personal information, payment data, and authentication credentials, CSP is a critical security layer. It is not a replacement for fixing vulnerabilities in your code, but it is an effective defense-in-depth measure that limits the damage when a vulnerability exists.

CSP Directives Explained

A Content Security Policy consists of one or more directives, each controlling a specific type of resource. The most important directives for PrestaShop are:

default-src: The fallback directive. If a more specific directive is not set, the browser uses default-src. Setting default-src 'self' means that by default, only resources from your own domain are allowed.

script-src: Controls where JavaScript can be loaded from. This is the most critical directive for XSS prevention. Common values include 'self' (your own domain), specific CDN domains, and analytics domains.

style-src: Controls where CSS can be loaded from. PrestaShop themes and modules frequently use inline styles, which means you may need 'unsafe-inline' unless you implement a nonce-based approach.

img-src: Controls where images can be loaded from. PrestaShop stores often load images from their own domain, CDN domains, and third-party services like Google (for user avatars or Maps).

font-src: Controls where fonts can be loaded from. Google Fonts, Font Awesome CDN, and your own domain are common sources.

connect-src: Controls which URLs can be contacted via JavaScript (AJAX requests, WebSocket connections, EventSource). Payment gateways, analytics endpoints, and your own API endpoints need to be listed here.

frame-src: Controls which domains can be embedded in iframes. Payment gateways like PayPal, Stripe, and Klarna use iframes for their payment forms. YouTube and Vimeo embeds also require frame-src entries.

frame-ancestors: Controls which domains can embed your page in an iframe. Setting frame-ancestors 'self' prevents clickjacking attacks by ensuring your store cannot be embedded in another site's iframe.

object-src: Controls plugin content like Flash. Set this to 'none' because Flash is obsolete and no PrestaShop functionality requires it.

base-uri: Controls which URLs can be used in the <base> element. Set to 'self' to prevent base URI manipulation attacks.

form-action: Controls which URLs forms can submit to. This should include your own domain and any external payment processing endpoints.

Starting with Report-Only Mode

Deploying CSP on a PrestaShop store requires careful preparation because an overly restrictive policy will break functionality. The right approach is to start with report-only mode, which tells the browser to report violations without actually blocking anything.

Instead of using the Content-Security-Policy header, use Content-Security-Policy-Report-Only. This header accepts the exact same directives but only generates reports without enforcing the policy. Your store continues to function normally while you collect data about what would be blocked.

Setting Up Violation Reporting

Add a report-uri directive to your policy that points to an endpoint that collects violation reports. You can use a free service like Report URI (report-uri.com), which provides a dashboard for viewing and analyzing CSP violations, or you can set up your own endpoint.

The browser sends violation reports as JSON POST requests. Each report includes the blocked URI, the directive that was violated, the page where the violation occurred, and other useful debugging information. Collecting these reports for a week or two on a live store gives you a comprehensive picture of all the resources your store loads and where they come from.

Building Your Initial Policy

Using the violation reports from report-only mode, build a whitelist of all legitimate resource sources. Group them by directive type. Your initial policy will likely include:

Your own domain for all resource types. CDN domains (like cdnjs.cloudflare.com, fonts.googleapis.com, fonts.gstatic.com) for scripts, styles, and fonts. Analytics domains (like google-analytics.com, googletagmanager.com, connect.facebook.net) for tracking. Payment gateway domains for scripts, frames, and connections. Chat widget domains if you use live chat. Social media domains for embedded content or share buttons.

Building a CSP for PrestaShop

PrestaShop presents specific challenges for CSP implementation because of its architecture and the modules ecosystem.

Handling Inline Styles and Scripts

PrestaShop core, themes, and many modules use inline styles and inline JavaScript extensively. Inline code is blocked by default in CSP because an attacker who injects content into your page would be injecting inline code. There are three approaches to handling this:

Using 'unsafe-inline': The simplest but least secure approach. Adding 'unsafe-inline' to script-src and style-src allows all inline code, which significantly weakens CSP's XSS protection. For style-src, this is generally acceptable because inline styles pose a much lower security risk than inline scripts. For script-src, avoid 'unsafe-inline' if at all possible.

Using nonces: The recommended approach. A nonce is a random, single-use token generated on each request. You add the nonce to your CSP header (script-src 'nonce-abc123') and to each legitimate inline script tag (<script nonce="abc123">). The browser only executes inline scripts that have the correct nonce. Since the nonce changes on every request and an attacker cannot predict it, injected scripts without the nonce are blocked.

Implementing nonces in PrestaShop requires modifying the theme to add nonce attributes to all inline script tags and creating a mechanism (typically a module or a custom hook) that generates the nonce, adds it to the CSP header, and makes it available to templates. This is a significant implementation effort but provides strong XSS protection.

Using hashes: You can whitelist specific inline scripts by their SHA-256 hash. The browser computes the hash of each inline script it encounters and checks it against the hashes listed in the CSP. This approach works for inline scripts that do not change between requests (static inline scripts), but it is impractical for PrestaShop because many inline scripts include dynamic content like product IDs, prices, and user-specific data that change the hash.

Handling eval and Dynamic Code

Some JavaScript libraries use eval() or new Function() to dynamically create and execute code. CSP blocks these by default. If a module or library requires eval, you must add 'unsafe-eval' to script-src. Common culprits include older versions of jQuery templates, some analytics scripts, and certain payment gateway libraries.

Check your violation reports for entries with eval or inline as the blocked URI. These indicate code that uses dynamic evaluation. Where possible, replace the library with a version that does not use eval. When that is not possible (such as with a third-party payment gateway library you cannot modify), 'unsafe-eval' is the only option.

Third-Party Services

Most PrestaShop stores rely on multiple third-party services, each of which needs to be whitelisted in your CSP. Here are the most common ones and the directives they require:

Google Analytics and Google Tag Manager: These require entries in script-src for www.google-analytics.com, www.googletagmanager.com, and tagmanager.google.com. They also need connect-src entries for www.google-analytics.com and analytics.google.com (for sending tracking data), and img-src entries for www.google-analytics.com (for the tracking pixel). Google Tag Manager is particularly challenging because it dynamically loads scripts from domains you may not know in advance, as the scripts loaded depend on the tags configured in GTM.

PayPal: Requires script-src and frame-src entries for *.paypal.com and *.paypalobjects.com. The exact domains depend on whether you use PayPal Standard, PayPal Express, or the newer PayPal Commerce Platform integration.

Stripe: Requires script-src for js.stripe.com, frame-src for js.stripe.com and hooks.stripe.com, and connect-src for api.stripe.com.

Google Fonts: Requires style-src for fonts.googleapis.com and font-src for fonts.gstatic.com.

YouTube embeds: Require frame-src for www.youtube.com and www.youtube-nocookie.com.

Facebook Pixel and social plugins: Require script-src and connect-src for connect.facebook.net and www.facebook.com, plus img-src for www.facebook.com and *.fbcdn.net.

Live chat widgets (Tidio, Crisp, Intercom, etc.): Each has its own set of domains for scripts, styles, WebSocket connections, and images. Check your violation reports or the provider's documentation for the exact domains required.

A Complete CSP Example for PrestaShop

Here is a realistic CSP header for a PrestaShop store that uses Google Analytics, Google Fonts, PayPal, YouTube embeds, and has inline styles:

Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com www.googletagmanager.com js.stripe.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' fonts.googleapis.com 'unsafe-inline'; img-src 'self' data: www.google-analytics.com *.paypal.com; font-src 'self' fonts.gstatic.com; connect-src 'self' www.google-analytics.com analytics.google.com api.stripe.com; frame-src 'self' www.youtube.com www.youtube-nocookie.com js.stripe.com *.paypal.com; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self' *.paypal.com;

This policy includes 'unsafe-inline' and 'unsafe-eval' for scripts, which weakens XSS protection but is necessary for most PrestaShop installations that have not been modified to support nonces. For img-src, the data: source is included because PrestaShop and many modules use data URIs for small images and icons.

Implementing CSP in PrestaShop

Via .htaccess (Apache)

For Apache servers, add the CSP header in your .htaccess file. Place it near the top of the file, before the PrestaShop rewrite rules:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' ..."

This requires the mod_headers module to be enabled. You can verify by checking if your server returns the header using browser DevTools (Network tab, click on the main document request, check the Response Headers).

Via Nginx Configuration

For Nginx, add the header in your server block:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' ..." always;

The always parameter ensures the header is sent even for error responses, which is important because error pages can also be targets for XSS attacks.

Via a PrestaShop Module

Implementing CSP through a module gives you the ability to manage the policy from the back office. The module hooks into the actionOutputHTMLBefore or uses PHP's header() function in a front controller hook to add the CSP header to every response. A module-based approach is easier to maintain because you can update the policy without editing server configuration files and without restarting the web server.

Testing Your CSP with Browser DevTools

After implementing your CSP (in report-only mode initially), use browser DevTools to monitor for violations. Open the Console tab and look for messages that start with "[Report Only]" (in report-only mode) or "Refused to" (in enforcement mode). Each message tells you exactly what was blocked and which directive was responsible.

Test every page type on your store: the home page, category pages, product pages, the cart, the checkout process (including each step and each payment method), the customer account pages, and CMS pages. Each page type may load different resources, and you need to ensure your policy covers all of them.

Pay special attention to the checkout process. A blocked payment gateway script or iframe during checkout directly prevents customers from completing purchases. Test every payment method you offer, including the 3D Secure verification flow if applicable, because these often load additional resources from domains that are not obvious.

Common Testing Pitfalls

Testing in a development environment may not reveal all violations because your development setup may not include all the third-party services that run on production (analytics, advertising pixels, live chat, A/B testing tools). Always deploy CSP in report-only mode on production first and collect reports for at least one to two weeks before switching to enforcement.

Some violations only occur under specific conditions. For example, a payment gateway might load additional verification scripts only when a customer's card requires 3D Secure authentication. Social sharing buttons might load scripts only when a visitor clicks them. Dynamic content loaded via AJAX may reference resources that are not present on the initial page load. Run through every possible user flow during testing.

Gradual Enforcement Strategy

The recommended deployment strategy for CSP on PrestaShop follows these steps:

Phase 1: Discovery. Deploy a permissive Content-Security-Policy-Report-Only header with default-src * 'unsafe-inline' 'unsafe-eval' data: blob:; and a report-uri. This logs all resources without blocking anything, giving you a complete inventory of what your store loads.

Phase 2: Draft policy. Based on the violation reports, build a whitelist policy that covers all legitimate resources. Deploy it in report-only mode and monitor for violations that indicate you missed a resource.

Phase 3: Refine. Over one to two weeks, check violation reports daily and add any legitimate sources you missed. Pay attention to reports that come from specific page types or user flows you might not have tested manually.

Phase 4: Enforce. Switch from Content-Security-Policy-Report-Only to Content-Security-Policy. Keep the report-uri directive so you continue receiving violation reports. Monitor closely for the first week after enforcement to catch any legitimate resources that are being blocked.

Phase 5: Tighten. Once enforcement is stable, look for opportunities to tighten the policy. Can you replace 'unsafe-inline' in script-src with nonces? Can you narrow wildcard domains to specific subdomains? Can you remove sources that are no longer used? Each tightening step improves your security posture.

Maintaining Your CSP

A CSP is not a set-and-forget configuration. Every time you install a new module, add a third-party service, change payment gateways, or update your theme, you may need to update your CSP to include new resource sources. Make CSP review part of your module installation and update process.

Keep your report-uri active even after enforcement so you receive alerts about new violations. A sudden increase in violation reports might indicate that a module update introduced new resource requirements, or it might indicate an actual XSS attack attempt that your CSP is successfully blocking. Either way, you want to know about it.

Document your CSP and the reason for each entry. Over time, policies accumulate entries for services you no longer use. Periodic reviews to remove unnecessary entries keep the policy clean and reduce the attack surface. A CSP with fewer allowed sources is inherently more secure than one with many.

Cómo PrestaShop gestiona las imágenes de productos

Cada imagen subida a PrestaShop pasa por un pipeline de procesamiento. Cuando añades una imagen de producto, el sistema almacena el archivo original y luego genera múltiples versiones redimensionadas llamadas miniaturas (thumbnails). Cada miniatura corresponde a un tipo de imagen definido en el back office bajo Diseño > Ajustes de imágenes. Estos tipos de imagen especifican dimensiones exactas en píxeles y están vinculados a contextos específicos: listados de productos, páginas de producto, vistas previas del carrito, cabeceras de categorías, logotipos de fabricantes y más.

PrestaShop almacena las imágenes en el directorio /img/. En PrestaShop 1.7 y 8.x, las imágenes de productos están organizadas usando una estructura de directorios basada en el ID de la imagen. Por ejemplo, una imagen con ID 1234 se almacena en /img/p/1/2/3/4/. Dentro de ese directorio encontrarás la imagen original (nombrada por ID, como 1234.jpg) y todas las miniaturas generadas (como 1234-home_default.jpg, 1234-large_default.jpg, 1234-small_default.jpg).

La convención de nombres sigue el patrón: {image_id}-{image_type_name}.{extension}. Esto significa que cada tipo de imagen que definas crea un archivo adicional por cada imagen de producto en tu catálogo. Una tienda con 5.000 imágenes de producto y 8 tipos de imagen tendrá aproximadamente 45.000 archivos de imagen (5.000 originales más 5.000 por 8 miniaturas). Esta escala importa cuando necesitas regenerarlas.

Comprender los tipos de imagen

Los tipos de imagen están definidos en la tabla de base de datos ps_image_type y se gestionan a través del back office. Cada tipo de imagen tiene un nombre, ancho, alto y flags que indican a qué tipos de entidad se aplica (productos, categorías, fabricantes, proveedores, tiendas). La instalación predeterminada de PrestaShop incluye varios tipos de imagen:

cart_default es típicamente de 125x125 píxeles, usado en el carrito y el mini carrito. small_default es de unos 98x98 píxeles, usado en listados de productos en algunos temas. medium_default es de unos 452x452 píxeles, usado para las miniaturas de productos en la página de producto. home_default es de unos 250x250 píxeles, usado en la página de inicio y listados de categorías. large_default es de unos 800x800 píxeles, usado como la imagen principal del producto en la página de producto.

Los temas pueden definir sus propios requisitos de tipos de imagen. Cuando instalas un nuevo tema, típicamente registra sus tipos de imagen preferidos durante la instalación. El punto crítico es que los archivos de imagen reales en disco deben coincidir con lo que el tema espera. Si el tema requiere home_default a 340x340 pero tus archivos de imagen fueron generados a 250x250 porque usabas un tema diferente anteriormente, cada listado de productos mostrará imágenes con dimensiones incorrectas.

Cuándo es necesaria la regeneración de imágenes

Varias situaciones requieren una regeneración total o parcial de miniaturas. Comprender cuándo es verdaderamente necesaria te ahorra ejecutar un proceso que puede tomar horas en catálogos grandes.

Cambio de tema

Esta es la razón más común. Diferentes temas requieren diferentes dimensiones de imagen. Cuando cambias de un tema a otro, las plantillas del nuevo tema hacen referencia a tipos de imagen con dimensiones específicas. Si esas dimensiones no coinciden con los archivos de miniatura existentes, las imágenes aparecen estiradas, recortadas incorrectamente o borrosas. Después de instalar un nuevo tema, siempre verifica sus requisitos de tipos de imagen y regenera las miniaturas para que coincidan.

Cambios en las dimensiones del tipo de imagen

Si modificas el ancho o alto de un tipo de imagen existente a través de Diseño > Ajustes de imágenes, el cambio solo afecta la definición en la base de datos. Todos los archivos de miniatura existentes en disco conservan sus dimensiones antiguas. Debes regenerar las miniaturas para el tipo de imagen modificado para aplicar las nuevas dimensiones a las imágenes existentes.

Añadir un nuevo tipo de imagen

Cuando creas un nuevo tipo de imagen, aún no existen archivos de miniatura para él. Si una plantilla hace referencia a este nuevo tipo de imagen, mostrará enlaces de imagen rotos hasta que regeneres. El proceso de regeneración crea los archivos de miniatura faltantes para cada imagen existente.

Problemas de calidad de imagen

Si cambias la configuración de calidad de compresión JPEG en PrestaShop (que se encuentra en Rendimiento > Ajustes de imágenes o la sección de configuración de imágenes dependiendo de tu versión), las miniaturas existentes fueron generadas con la configuración de calidad anterior. La regeneración aplica el nuevo nivel de calidad a todas las miniaturas.

Después de una migración o cambio de servidor

A veces durante la migración, los archivos de miniatura se pierden o corrompen mientras las imágenes originales sobreviven. Si las imágenes de productos aparecen rotas pero los originales existen en los directorios esperados, la regeneración recrea todas las miniaturas a partir de los originales.

Habilitar el formato WebP

PrestaShop 8.x introdujo soporte WebP para imágenes de productos. Cuando habilitas la generación WebP, las imágenes existentes no obtienen automáticamente variantes WebP. Debes regenerar las miniaturas para crear las versiones .webp junto a los archivos JPEG o PNG existentes.

Regeneración a través del panel de administración

PrestaShop proporciona una herramienta de regeneración integrada en el back office bajo Diseño > Ajustes de imágenes (o Preferencias > Imágenes en versiones anteriores). En la parte inferior de la página encontrarás la sección de regeneración.

Opciones disponibles

Puedes elegir borrar las imágenes anteriores antes de regenerar. Cuando está habilitado, PrestaShop elimina todas las miniaturas existentes antes de crear nuevas. Esto es útil cuando quieres eliminar miniaturas para tipos de imagen que ya no existen, pero significa que todas las imágenes estarán no disponibles durante el proceso de regeneración. Cuando está deshabilitado, PrestaShop sobrescribe las miniaturas existentes y crea las faltantes sin eliminar nada primero.

Puedes seleccionar qué tipos de entidad regenerar: productos, categorías, fabricantes, proveedores o tiendas. Si solo cambiaste las dimensiones de imágenes de productos, no hay necesidad de regenerar imágenes de categorías o fabricantes.

Limitaciones del enfoque del panel de administración

La regeneración del panel de administración se ejecuta como una solicitud web. Esto crea varios problemas para catálogos grandes. Los servidores web tienen límites de tiempo de ejecución, típicamente de 30 a 300 segundos dependiendo de tu configuración. Una tienda con 10.000 imágenes de producto y 8 tipos de imagen necesita generar 80.000 archivos de miniatura. Incluso a un ritmo generoso de 10 imágenes por segundo, eso toma más de dos horas. La mayoría de los servidores web terminarán el proceso mucho antes de que finalice.

Los límites de memoria también aplican. Cada imagen debe cargarse en memoria, redimensionarse usando GD o ImageMagick, y guardarse. Las imágenes originales de alta resolución pueden consumir de 20 a 50 MB de memoria cada una durante el procesamiento. El límite de memoria predeterminado de PHP de 128 MB o 256 MB puede agotarse rápidamente, especialmente al procesar imágenes en secuencia sin una limpieza de memoria adecuada.

Si el proceso es interrumpido por un timeout o error de memoria, terminas con un catálogo parcialmente regenerado. Algunos productos tienen nuevas miniaturas, otros tienen las antiguas y algunos podrían no tener ninguna. Este estado inconsistente es peor que el problema original.

Regeneración CLI para catálogos grandes

Para tiendas con más de unos pocos cientos de productos, la regeneración por línea de comandos es fuertemente recomendada. Evita los límites de timeout del servidor web y puede configurarse con límites de memoria más altos.

Uso de la consola PrestaShop

PrestaShop 1.7.5 y posteriores incluyen una consola Symfony. Puedes regenerar miniaturas usando:

php bin/console prestashop:image:regenerate

Este comando acepta varias opciones. Para regenerar solo tipos de imagen específicos, usa el flag --image-type seguido del nombre del tipo de imagen. Para procesar solo productos, categorías u otros tipos de entidad específicos, usa el flag --entity. El flag --format te permite especificar qué formatos de salida generar (jpg, png, webp).

Ejecuta el comando desde el directorio raíz de PrestaShop. Si usas Docker, ejecútalo dentro del contenedor:

docker exec -u www-data your-container php bin/console prestashop:image:regenerate

El flag -u www-data asegura que los archivos generados sean propiedad del usuario del servidor web. Ejecutar como root crea archivos que el servidor web no puede servir ni modificar posteriormente.

Configuración de memoria y tiempo

Para la ejecución CLI, puedes aumentar los límites de PHP directamente en el comando:

php -d memory_limit=512M -d max_execution_time=0 bin/console prestashop:image:regenerate

Establecer max_execution_time=0 elimina completamente el límite de tiempo, y 512 MB de memoria son suficientes para la mayoría de los catálogos. Para tiendas con originales de resolución extremadamente alta (4000x4000 píxeles o más), podrías necesitar 1 GB o más.

Enfoque de regeneración personalizado

Para catálogos muy grandes (50.000 o más imágenes), incluso el comando de consola puede ser lento o problemático. Un enfoque PHP personalizado te permite procesar imágenes en lotes con seguimiento de progreso, manejo de errores y la capacidad de reanudar después de una interrupción.

El enfoque consiste en consultar la base de datos para todos los registros de imagen, iterar a través de ellos en lotes de 100 o 200, generar miniaturas para cada imagen y registrar el progreso. Si el proceso se interrumpe, puedes reanudarlo desde donde se detuvo verificando qué miniaturas ya existen.

Un enfoque por lotes también permite distribuir la regeneración en múltiples ejecuciones durante las horas de menor tráfico, evitando el impacto en el rendimiento de la tienda activa.

Generación WebP durante la regeneración

WebP es un formato de imagen moderno que proporciona tamaños de archivo significativamente menores que JPEG a calidad comparable. PrestaShop 8.x puede generar versiones WebP de las miniaturas durante el proceso de regeneración.

Habilitar el soporte WebP

Antes de regenerar, habilita WebP en la configuración de PrestaShop. En PrestaShop 8.x, esta opción está en los ajustes de imágenes. Cuando está habilitada, el proceso de regeneración crea tanto la miniatura tradicional JPEG/PNG como una versión .webp para cada tipo de imagen.

Requisitos del servidor

La generación WebP requiere la extensión GD compilada con soporte WebP (--with-webp) o la extensión ImageMagick con delegados WebP. Puedes verificar el soporte GD con phpinfo() o gd_info(). Busca WebP Support en la salida. Si el soporte WebP falta, el proceso de regeneración silenciosamente omite la creación WebP sin producir errores.

Consideraciones de espacio en disco

Los archivos WebP son típicamente del 25 al 35 por ciento más pequeños que los archivos JPEG equivalentes, pero estás almacenando ambos formatos. Una tienda con 40.000 miniaturas JPEG que ocupan 2 GB de espacio en disco necesitará aproximadamente 3,4 GB en total después de la generación WebP (los 2 GB originales más aproximadamente 1,4 GB de archivos WebP). Planifica tu espacio en disco en consecuencia antes de iniciar una regeneración completa.

Servir WebP a los navegadores

Generar archivos WebP es solo la mitad de la solución. Tu tema y servidor deben estar configurados para servir WebP a los navegadores que lo soportan con fallback a JPEG/PNG para los que no. Esto se maneja típicamente a través de elementos <picture> en las plantillas del tema o mediante negociación de contenido del lado del servidor usando el encabezado Accept.

En Apache, puedes añadir reglas de reescritura que verifican el soporte WebP y sirven la versión WebP cuando está disponible. En Nginx, la directiva try_files puede verificar si existe una versión .webp de la imagen solicitada y servirla si el encabezado Accept del navegador incluye image/webp.

Impacto en el rendimiento y mitigación

La regeneración de imágenes es intensiva en CPU y pesada en E/S. En una tienda activa, puede degradar significativamente el rendimiento si no se gestiona cuidadosamente.

Impacto en la CPU

Cada operación de redimensionamiento de imagen requiere cargar el original en memoria, ejecutar el algoritmo de redimensionamiento, aplicar las configuraciones de calidad/compresión y escribir el resultado en disco. La operación de redimensionamiento en sí es computacionalmente costosa, especialmente para imágenes grandes que se reducen a miniaturas pequeñas. En un entorno de hosting compartido, esto puede saturar la CPU y ralentizar toda la tienda.

Impacto en E/S

La regeneración lee cada imagen original y escribe múltiples archivos de miniatura. En discos duros tradicionales, esto crea una carga de E/S significativa. En almacenamiento SSD, el impacto es mucho menor pero aún notable a escala. El patrón de E/S es particularmente hostil para los discos giratorios porque involucra lecturas aleatorias (originales dispersos por directorios) combinadas con escrituras secuenciales (miniaturas en los mismos directorios).

Ejecutar la regeneración en horas de bajo tráfico

Programa la regeneración para tu período de menor tráfico. Para tiendas europeas, esto es típicamente entre las 2:00 y las 6:00 de la madrugada. Para tiendas con tráfico global, puede que no haya un verdadero periodo de bajo tráfico, pero puedes identificar puntos relativamente bajos a partir de tus datos de analytics.

Uso de nice e ionice

En servidores Linux, puedes reducir la prioridad del proceso de regeneración para que no prive a otros procesos de recursos. El comando nice reduce la prioridad de CPU, e ionice reduce la prioridad de E/S:

nice -n 19 ionice -c 3 php bin/console prestashop:image:regenerate

Un valor nice de 19 es la prioridad más baja. La clase ionice 3 es la clase idle, lo que significa que el proceso solo obtiene tiempo de E/S cuando nada más lo necesita. Esto reduce drásticamente el impacto en la tienda activa pero hace que la regeneración tarde más.

Escalado temporal

Si estás en un servidor en la nube, considera escalar temporalmente tu servidor (más cores de CPU, más RAM, almacenamiento más rápido) durante la duración de la regeneración, y luego reducir. El costo extra de unas pocas horas de recursos de nivel superior es usualmente mínimo comparado con el impacto de una regeneración lenta de varios días en el rendimiento de tu tienda.

Evitar timeouts durante la regeneración

Los timeouts son el problema más común con la regeneración de imágenes. Aquí están las configuraciones específicas que los previenen.

Configuración PHP

La directiva max_execution_time limita cuánto tiempo puede ejecutarse un proceso PHP. Para la ejecución CLI, típicamente ya está establecida en 0 (ilimitado), pero verifica comprobando php -i | grep max_execution_time. Para la regeneración web a través del panel de administración, aumenta este valor en tu php.ini o .htaccess:

php_value max_execution_time 7200

También aumenta max_input_time si usas el panel de administración, ya que el timeout de envío del formulario es separado del timeout de ejecución:

php_value max_input_time 7200

Timeout del servidor web

La directiva Timeout de Apache y proxy_read_timeout / fastcgi_read_timeout de Nginx pueden terminar solicitudes de larga duración incluso si PHP mismo no ha superado el timeout. Para Apache: Timeout 7200. Para Nginx, añade a tu bloque server: fastcgi_read_timeout 7200; o proxy_read_timeout 7200;.

Configuración PHP-FPM

Si usas PHP-FPM (como la mayoría de las configuraciones modernas), el request_terminate_timeout en la configuración de tu pool también puede matar procesos de larga duración. Establécelo en 0 para deshabilitar el timeout, o iguálalo al tiempo máximo de ejecución deseado:

request_terminate_timeout = 7200

Timeouts de Cloudflare y CDN

Si tu tienda está detrás de Cloudflare u otro CDN, el CDN tiene su propio timeout de solicitudes (el plan gratuito de Cloudflare tiene un timeout de 100 segundos). Esto hace que la regeneración por panel de administración detrás de un CDN sea efectivamente imposible. Debes usar la regeneración CLI, evitar el CDN para el acceso de administración, o usar una solución que procese imágenes de forma asíncrona.

Estrategias de regeneración incremental

La regeneración completa procesa cada imagen en el catálogo. Para tiendas con decenas de miles de imágenes, esto puede tomar muchas horas. Los enfoques incrementales procesan solo las imágenes que realmente necesitan nuevas miniaturas.

Regeneración selectiva de tipo de imagen

Si solo añadiste o modificaste un tipo de imagen, no necesitas regenerar todos los tipos de imagen. Usa la opción --image-type en el comando de consola para apuntar solo al tipo de imagen específico que cambió. Esto reduce el trabajo a un octavo (o cualquier fracción de tus tipos de imagen totales) de una regeneración completa.

Procesamiento basado en fecha

Si necesitas regenerar miniaturas solo para productos añadidos recientemente (por ejemplo, después de corregir un problema de procesamiento de imágenes), puedes consultar la base de datos para imágenes añadidas después de una fecha específica y procesar solo esas. La tabla ps_image no tiene una columna de fecha por defecto, pero la tabla asociada ps_product tiene campos date_add y date_upd que pueden usarse para identificar productos modificados recientemente.

Detección de miniaturas faltantes

En lugar de regenerar todo, escanea los directorios de imágenes para encontrar imágenes a las que les faltan miniaturas específicas y regenera solo esas. Este es el enfoque más rápido cuando has añadido un nuevo tipo de imagen o cuando una regeneración parcial fue interrumpida.

La lógica es directa: para cada ID de imagen en la base de datos, verifica si el archivo de miniatura esperado existe en disco. Si no existe, regenera solo esa miniatura. Esto convierte una regeneración completa de varias horas en un proceso dirigido que podría tomar minutos.

Procesamiento paralelo

Para catálogos muy grandes, puedes dividir el rango de IDs de imagen en bloques y procesarlos en paralelo usando múltiples procesos PHP. Por ejemplo, un proceso maneja los IDs de imagen de 1 a 10000, otro maneja de 10001 a 20000, y así sucesivamente. Cada proceso funciona independientemente, y el throughput combinado es aproximadamente proporcional al número de procesos paralelos (limitado por los cores de CPU y el ancho de banda de E/S).

Ten cuidado con el procesamiento paralelo y la E/S de disco. Ejecutar demasiados procesos simultáneamente en un disco duro tradicional causará contención de E/S y realmente ralentizará las cosas. En almacenamiento SSD, de 4 a 8 procesos paralelos típicamente funcionan bien.

Consideraciones sobre el formato de imagen

PrestaShop soporta JPEG, PNG y GIF como formatos fuente, y puede generar miniaturas en estos formatos más WebP. El formato fuente afecta el comportamiento de la regeneración.

Imágenes JPEG

JPEG es el formato más común para fotos de productos. Soporta compresión con pérdida, lo que significa que cada vez que se guarda un JPEG, se pierde algo de calidad. Por eso regenerar miniaturas desde las subidas originales produce mejores resultados que regenerar desde miniaturas previamente redimensionadas. Siempre asegúrate de estar trabajando desde la imagen original subida, no desde una miniatura generada previamente.

Imágenes PNG

PNG soporta transparencia y compresión sin pérdida. Si tus imágenes de producto usan fondos transparentes, las miniaturas PNG preservan esa transparencia. Sin embargo, los archivos PNG son típicamente mucho más grandes que los archivos JPEG. Considera si realmente necesitas la transparencia. Si no, convertir las imágenes de producto PNG a JPEG durante la regeneración puede reducir significativamente el espacio en disco y mejorar los tiempos de carga de página.

Manejo de GIF

PrestaShop puede aceptar subidas GIF, pero las miniaturas generadas desde fuentes GIF son estáticas (la animación no se preserva). Si tienes imágenes de producto GIF animadas, ten en cuenta que la regeneración produce miniaturas estáticas del primer fotograma.

Verificación post-regeneración

Después de que la regeneración se complete, verifica los resultados antes de asumir que todo está correcto.

Verificación visual de la calidad de imágenes

Abre varias páginas de producto e inspecciona las imágenes visualmente. Verifica que las miniaturas sean nítidas, correctamente proporcionadas y no estén estiradas ni pixeladas. Presta especial atención a las imágenes que eran originalmente pequeñas (cercanas o menores que las dimensiones de la miniatura), ya que estas tienen más probabilidades de mostrar problemas de calidad al ser ampliadas.

Verificación del conteo de archivos

Compara el número de miniaturas generadas con las expectativas. Si tienes 5.000 imágenes de producto y 8 tipos de imagen, deberías tener aproximadamente 40.000 archivos de miniatura (más los originales y potencialmente las variantes WebP). Un conteo significativamente menor indica que el proceso de regeneración fue interrumpido o encontró errores en algunas imágenes.

Verificación de permisos de archivos

Verifica que los archivos regenerados sean propiedad del usuario del servidor web (típicamente www-data en Debian/Ubuntu o apache en CentOS). Si ejecutaste la regeneración como root, los archivos podrían no ser legibles por el servidor web, causando imágenes rotas en el frontend. Corrige con: chown -R www-data:www-data img/p/.

Limpieza de caché

Después de la regeneración, limpia todas las cachés. Esto incluye la caché interna de PrestaShop (Parámetros avanzados > Rendimiento), cualquier caché de opcode (OPcache) y cualquier caché CDN o proxy inverso. Las páginas cacheadas antiguas podrían seguir haciendo referencia a URLs o dimensiones de imagen antiguas. Si usas un módulo que genera sprites CSS o imágenes inline, regenéralos también.

Si tu tienda está detrás de Cloudflare, purga la caché para la ruta /img/ o haz una purga completa de caché. Cloudflare cachea imágenes agresivamente, y los visitantes podrían ver miniaturas antiguas hasta que la caché del CDN expire o sea purgada.

Resolución de problemas comunes de regeneración

Miniaturas negras o corrompidas

Esto generalmente indica un problema con la librería GD. La extensión GD podría no soportar el formato fuente (por ejemplo, GD compilado sin soporte JPEG). Verifica las capacidades de GD con gd_info(). Otra causa es memoria insuficiente: si PHP no puede asignar suficiente memoria para cargar la imagen original, GD podría producir una imagen negra en lugar de lanzar un error.

Dimensiones incorrectas en las miniaturas generadas

Si las miniaturas tienen dimensiones inesperadas, verifica las definiciones de tipos de imagen en la base de datos. El panel de administración podría mostrar un valor mientras la base de datos contiene otro (esto puede suceder después de una importación fallida o una modificación manual de la base de datos). Consulta directamente: SELECT * FROM ps_image_type WHERE name = 'home_default';

La regeneración se cuelga sin progreso

Un proceso de regeneración colgado generalmente significa que encontró una imagen muy grande que agotó la memoria disponible. Verifica el log de errores PHP buscando fallos de asignación de memoria. La solución es aumentar el límite de memoria o pre-procesar las imágenes fuente problemáticas para reducir su resolución antes de la regeneración.

Errores de permiso denegado

Si la regeneración reporta errores de permiso, el proceso PHP no puede escribir en los directorios de imágenes. Esto ocurre comúnmente en entornos Docker donde los volúmenes bind-mounted tienen diferente propiedad dentro y fuera del contenedor. Asegúrate de que el usuario que ejecuta el comando de regeneración tenga acceso de escritura al árbol completo del directorio /img/.

Resumen

La regeneración de imágenes es una tarea de mantenimiento que todo propietario de tienda PrestaShop encuentra, generalmente durante un cambio de tema o al optimizar los ajustes de imagen. Para catálogos pequeños (menos de 500 productos), la herramienta del panel de administración funciona adecuadamente. Para cualquier cosa mayor, la regeneración CLI es el único enfoque fiable. Los principios clave son: siempre trabaja desde las imágenes originales, haz coincidir las definiciones de tus tipos de imagen con los requisitos de tu tema, gestiona proactivamente los recursos del servidor y los timeouts, usa enfoques incrementales cuando sea posible y verifica los resultados después de que el proceso se complete. Con WebP convirtiéndose en el estándar para imágenes web, la regeneración también sirve como el mecanismo para crear variantes de formato moderno de todo tu catálogo de productos, ofreciendo tamaños de archivo más pequeños y cargas de página más rápidas a tus clientes.

Qué es Varnish y por qué importa para PrestaShop

Varnish Cache es un proxy inverso HTTP que se sitúa entre tu servidor web e internet, sirviendo copias cacheadas de las páginas sin tocar jamás PHP ni MySQL. Cuando un visitante solicita una página que Varnish tiene en caché, la respuesta llega directamente desde la memoria en microsegundos. PHP nunca se ejecuta. MySQL nunca recibe una consulta. El servidor web apenas nota que la solicitud ha ocurrido.

Esto es fundamentalmente diferente de cómo funcionan los módulos de full page cache (FPC) basados en PHP en PrestaShop. Un módulo FPC sigue ejecutándose dentro de PHP. La solicitud llega a Apache o Nginx, PHP se inicia, PrestaShop se inicializa (cargando la configuración, estableciendo conexiones a la base de datos, analizando las rutas), y luego el módulo FPC intercepta la solicitud antes de que se ejecute la lógica completa del controlador, sirviendo un archivo HTML cacheado. Aunque esto es significativamente más rápido que renderizar la página desde cero, aún implica iniciar PHP y cargar el framework de PrestaShop. Esa sobrecarga, típicamente de 50-200 milisegundos incluso para un acierto de caché, se acumula bajo carga.

Varnish elimina completamente esa sobrecarga. Un acierto de caché de Varnish se sirve en 1-5 milisegundos. Con tráfico elevado, la diferencia es dramática. Una tienda PrestaShop que lucha por manejar 100 usuarios simultáneos con un módulo FPC puede servir miles de usuarios simultáneos con Varnish, porque la gran mayoría de las solicitudes nunca llegan al backend PHP.

Cuándo los módulos PHP Full Page Cache son suficientes

Antes de invertir en Varnish, vale la pena entender cuándo un módulo FPC basado en PHP es suficientemente bueno. Para muchas tiendas PrestaShop, lo es.

Si tu tienda recibe menos de 50.000 páginas vistas diarias, un módulo FPC bien configurado manejará la carga sin problemas. La complejidad adicional de Varnish no está justificada cuando tu servidor tiene capacidad de reserva. Si los tiempos de respuesta del servidor con FPC son consistentemente inferiores a 200 milisegundos, tus visitantes ya están obteniendo cargas de página rápidas. El cuello de botella en ese punto es probablemente el renderizado frontend (CSS, JavaScript, imágenes) en lugar del tiempo de respuesta del servidor.

Los módulos FPC manejan algunos escenarios específicos de PrestaShop con más elegancia que Varnish porque se ejecutan dentro de la aplicación. Pueden verificar si un usuario está conectado, si el carrito tiene artículos y si cierto contenido dinámico necesita personalización — todo dentro del mismo proceso PHP. Con Varnish, estas comprobaciones deben manejarse mediante la inspección de cookies y reglas de variación de caché, lo que añade complejidad a la configuración.

Considera Varnish cuando tu tienda maneja regularmente picos de tráfico (ventas flash, campañas de marketing, picos estacionales) que sobrecargan tu capacidad PHP, cuando necesitas tiempos de respuesta inferiores a 10 ms por razones de SEO o experiencia de usuario, cuando tu presupuesto de hosting es limitado y necesitas servir más tráfico con el mismo hardware, o cuando tu tienda sirve una alta proporción de navegación anónima (páginas de categoría, páginas de producto) en relación con la actividad del carrito y el checkout.

Cómo funciona Varnish: El flujo de solicitudes

Comprender el flujo de solicitudes a través de Varnish es esencial para configurarlo correctamente con PrestaShop.

Llegada de la solicitud

Cuando un visitante solicita una página, la solicitud llega primero a Varnish (Varnish escucha en el puerto 80 o 443 si la terminación SSL es manejada por un proxy frontend). Varnish examina la solicitud: la URL, el método HTTP, las cookies y los encabezados.

Búsqueda en caché

Varnish comprueba su caché en busca de una respuesta almacenada que coincida con esta solicitud. La clave de caché se basa típicamente en la URL y encabezados seleccionados. Si existe una respuesta coincidente y no ha expirado, Varnish la sirve directamente. Esto es un acierto de caché (cache hit). La respuesta se envía al visitante y el servidor backend nunca es contactado.

Fallo de caché

Si no existe una respuesta cacheada coincidente, Varnish reenvía la solicitud al servidor backend (Apache o Nginx ejecutando PrestaShop). PrestaShop procesa la solicitud normalmente, genera la respuesta HTML y la envía de vuelta a Varnish. Varnish almacena la respuesta en su caché (si la respuesta es cacheable) y la reenvía al visitante. Las solicitudes posteriores de la misma página se servirán desde la caché.

Invalidación de caché

Cuando los datos del producto cambian, los precios se actualizan o el contenido se modifica, la versión en caché se vuelve obsoleta. Varnish necesita ser informado de descartar la versión antigua cacheada para que obtenga una nueva del backend. Esto es la invalidación de caché, y es la parte más difícil de cualquier sistema de caché para implementar correctamente.

Configuración VCL para PrestaShop

Varnish Configuration Language (VCL) es un lenguaje específico de dominio que controla cómo Varnish maneja las solicitudes. Una configuración VCL adecuada para PrestaShop debe manejar varios comportamientos específicos de PrestaShop.

Definición del backend

La definición del backend le indica a Varnish dónde reenviar los fallos de caché. Para una configuración típica de PrestaShop donde Apache o Nginx se ejecuta en el mismo servidor en el puerto 8080:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .connect_timeout = 5s;
  .first_byte_timeout = 60s;
  .between_bytes_timeout = 10s;
}

Los timeouts son importantes. Las páginas de PrestaShop pueden tardar varios segundos en generarse con caché fría, especialmente las páginas de categoría con muchos productos. Configurar first_byte_timeout demasiado bajo hace que Varnish devuelva un error 503 antes de que PrestaShop termine de generar la página.

Manejo de cookies y sesiones

Las cookies son el mayor desafío al hacer caché de PrestaShop con Varnish. PrestaShop establece varias cookies por defecto, y Varnish trata cualquier solicitud con cookies como no cacheable a menos que se le indique lo contrario. Si no manejas las cookies en tu VCL, Varnish no cacheará prácticamente nada.

PrestaShop establece estas cookies en la mayoría de las solicitudes: la cookie de sesión (típicamente llamada PrestaShop-xxxx), las cookies relacionadas con el carrito, las cookies de Google Analytics (_ga, _gid, _gat) y varias cookies de seguimiento de herramientas de marketing. De estas, solo la cookie de sesión de PrestaShop importa para el comportamiento de la caché. Las cookies de analytics y seguimiento deben eliminarse de la solicitud antes de la búsqueda en caché para que no impidan el caching.

En tu subrutina VCL vcl_recv, elimina las cookies no esenciales:

sub vcl_recv {
  # Eliminar cookies de Google Analytics y otros rastreadores
  set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_ga|_gid|_gat|__utm[a-z]+|_fbp|_gcl_[a-z]+)=[^;]*", "");
  # Eliminar encabezado de cookie vacío
  if (req.http.Cookie ~ "^\s*$") {
    unset req.http.Cookie;
  }
}

Decidir qué cachear

No todas las páginas de PrestaShop deben cachearse. El VCL debe distinguir entre solicitudes cacheables y no cacheables.

Cachear siempre: Páginas de producto para visitantes anónimos, páginas de listado de categorías, páginas CMS (acerca de, términos, contacto), la página de inicio, páginas de fabricantes y proveedores, páginas del mapa del sitio.

Nunca cachear: La página del carrito, las páginas de checkout (todos los pasos), el área de cuenta del cliente (pedidos, direcciones, información personal), las páginas de login y registro, cualquier página para un cliente conectado, solicitudes POST, solicitudes AJAX que modifican el estado (añadir al carrito, actualizar cantidad).

La lógica VCL para esto típicamente comprueba la ruta de la URL y la presencia de cookies de sesión:

sub vcl_recv {
  # No cachear solicitudes POST
  if (req.method == "POST") {
    return (pass);
  }
  # No cachear área de administración
  if (req.url ~ "^/admin") {
    return (pass);
  }
  # No cachear checkout y carrito
  if (req.url ~ "(cart|order|login|my-account|module/)" ) {
    return (pass);
  }
  # No cachear si el cliente tiene artículos en el carrito
  if (req.http.Cookie ~ "PrestaShop-") {
    return (pass);
  }
  return (hash);
}

Establecer la duración de la caché

En la subrutina vcl_backend_response, controlas cuánto tiempo Varnish cachea cada respuesta. PrestaShop envía encabezados Cache-Control que típicamente dicen no-cache o private porque asume que cada respuesta puede contener contenido personalizado. Necesitas sobrescribirlos para las páginas que sabes que son seguras para cachear:

sub vcl_backend_response {
  # Cachear páginas de producto y categoría por 1 hora
  if (bereq.url ~ "^/([0-9]+-|[a-z]+-[0-9]+)") {
    set beresp.ttl = 1h;
    unset beresp.http.Set-Cookie;
  }
  # Cachear activos estáticos por 1 día
  if (bereq.url ~ "\.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf)$") {
    set beresp.ttl = 1d;
    unset beresp.http.Set-Cookie;
  }
}

Eliminar Set-Cookie de las respuestas cacheadas es crítico. Si una respuesta cacheada incluye un encabezado Set-Cookie, Varnish no la cacheará por defecto, e incluso si se le obliga a cachear, establecería la misma cookie de sesión para cada visitante, causando secuestro de sesión (session hijacking).

Invalidación de caché con solicitudes PURGE

Cuando el precio de un producto cambia, se añade un nuevo producto o se actualiza el contenido, la versión cacheada debe invalidarse. Varnish soporta solicitudes PURGE: un método HTTP especial que le indica a Varnish que elimine una URL específica de su caché.

Configurar el soporte PURGE

Añade el manejo de PURGE a tu VCL:

acl purge {
  "127.0.0.1";
  "localhost";
}

sub vcl_recv {
  if (req.method == "PURGE") {
    if (!client.ip ~ purge) {
      return (synth(405, "Not allowed."));
    }
    return (purge);
  }
}

La ACL restringe las solicitudes PURGE a localhost, impidiendo que usuarios externos vacíen tu caché.

Disparar purgas desde PrestaShop

PrestaShop no envía nativamente solicitudes PURGE. Necesitas un módulo o hook personalizado que detecte cuándo cambia el contenido cacheable y envíe una solicitud PURGE a Varnish. El módulo se engancha a eventos de PrestaShop como actionProductUpdate, actionCategoryUpdate y actionCMSPageUpdate. Cuando estos eventos se disparan, el módulo envía una solicitud HTTP PURGE a la URL correspondiente en el servidor Varnish.

Para una actualización de producto, el módulo purgaría la URL del producto, las URLs de las categorías a las que pertenece el producto (porque las páginas de listado de categorías muestran precios y disponibilidad de productos) y potencialmente la página de inicio si muestra productos destacados. Esta cascada de purgas es necesaria para evitar que datos obsoletos aparezcan en cualquier parte del sitio.

Invalidación basada en BAN

Para escenarios donde muchas URLs necesitan purgarse a la vez (una actualización de precios a nivel de sitio, un cambio de diseño, un nuevo banner promocional), las solicitudes PURGE individuales son impracticables. Varnish soporta bans, que son reglas de invalidación basadas en patrones. Un ban le indica a Varnish que descarte cualquier objeto cacheado que coincida con un patrón:

sub vcl_recv {
  if (req.method == "BAN") {
    if (!client.ip ~ purge) {
      return (synth(405, "Not allowed."));
    }
    ban("req.url ~ " + req.http.X-Ban-Pattern);
    return (synth(200, "Banned."));
  }
}

Enviar una solicitud BAN con el encabezado X-Ban-Pattern: /category/ invalidaría todas las páginas de categoría cacheadas en una sola operación.

Edge Side Includes (ESI) para bloques dinámicos

Muchas páginas de PrestaShop contienen una mezcla de contenido estático y dinámico. El listado de productos en una página de categoría es el mismo para cada visitante, pero el encabezado que muestra el contador del carrito es personalizado. Sin ESI, no puedes cachear la página en absoluto porque el encabezado dinámico hace que toda la respuesta sea específica del visitante.

Los Edge Side Includes resuelven esto permitiéndote marcar secciones de la página como fragmentos recuperados por separado. Varnish ensambla la página final a partir de fragmentos cacheados y no cacheados.

Cómo funciona ESI

En tu plantilla Smarty, en lugar de renderizar el widget del carrito directamente, incluyes una etiqueta ESI:

<esi:include src="/module/cartwidget/ajax" />

Cuando Varnish procesa la página cacheada, encuentra la etiqueta ESI y realiza una solicitud separada al backend para ese fragmento. El cuerpo principal de la página se sirve desde la caché, mientras que el widget del carrito se obtiene fresco de PrestaShop. La respuesta ensamblada incluye tanto el cuerpo cacheado como el widget del carrito actualizado.

Habilita el procesamiento ESI en tu VCL:

sub vcl_backend_response {
  set beresp.do_esi = true;
}

Consideraciones ESI para PrestaShop

Implementar ESI requiere modificar tus plantillas de PrestaShop para separar el contenido dinámico en fragmentos compatibles con ESI. Cada fragmento necesita su propio endpoint URL que devuelva solo el HTML para ese bloque. Los fragmentos que típicamente son dinámicos y necesitan tratamiento ESI incluyen el widget resumen del carrito (conteo de artículos, total), el saludo al cliente ("Hola, Juan"), cualquier recomendación personalizada de productos, el enlace de login/logout y los productos vistos recientemente.

El esfuerzo requerido para implementar ESI correctamente es significativo. Cada fragmento dinámico necesita un controlador dedicado, las plantillas requieren reestructuración y las reglas de caching para cada fragmento necesitan ajuste individual. Esta es una de las razones por las que Varnish se considera una optimización avanzada — funciona mejor cuando la aplicación está diseñada teniéndolo en cuenta.

Comprobaciones de salud del backend

Varnish puede monitorear la salud de tu servidor backend y actuar cuando se vuelve no disponible. Esto se configura en la definición del backend:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .probe = {
    .url = "/ping.php";
    .timeout = 2s;
    .interval = 5s;
    .window = 5;
    .threshold = 3;
  }
}

Varnish envía una solicitud a /ping.php cada 5 segundos. Si 3 de las últimas 5 comprobaciones fallan, Varnish marca el backend como enfermo. Mientras el backend está enfermo, Varnish puede servir contenido cacheado obsoleto (modo grace) en lugar de devolver errores a los visitantes. Esto significa que tu tienda permanece parcialmente disponible incluso cuando el backend PHP se cae o se reinicia.

La configuración del modo grace determina cuánto tiempo Varnish servirá contenido obsoleto:

sub vcl_backend_response {
  set beresp.grace = 6h;
}

Con un grace de 6 horas, si tu backend cae, los visitantes verán páginas cacheadas (aunque tengan hasta 6 horas de antigüedad) en lugar de páginas de error. Los precios de los productos podrían estar ligeramente desactualizados, pero la tienda sigue funcional mientras solucionas el problema del backend.

Benchmarks de rendimiento

La diferencia de rendimiento entre sin caché, PHP FPC y Varnish es sustancial y medible.

Sin caché (PrestaShop puro): Una página de producto típica de PrestaShop tarda 200-800 milisegundos en generarse, dependiendo del hardware del servidor, el número de módulos cargados y la cantidad de consultas a la base de datos. Bajo carga, los tiempos de respuesta aumentan porque los workers PHP están saturados. Un solo servidor puede manejar 20-50 usuarios simultáneos antes de que los tiempos de respuesta se vuelvan inaceptables.

Módulo PHP FPC: Los aciertos de caché se sirven en 30-100 milisegundos porque PHP aún se inicia y el framework se inicializa parcialmente. Bajo carga, el rendimiento es mucho mejor porque las respuestas cacheadas requieren un tiempo de procesamiento PHP mínimo. Un solo servidor puede manejar 200-500 usuarios simultáneos dependiendo de la configuración. Los fallos de caché aún toman el tiempo completo de renderizado.

Varnish: Los aciertos de caché se sirven en 1-5 milisegundos. Bajo carga, Varnish mismo puede manejar miles de conexiones simultáneas porque está escrito en C y diseñado específicamente para este tipo de carga de trabajo. El servidor backend solo maneja los fallos de caché, que son una pequeña fracción del tráfico total en un sistema correctamente configurado. El mismo hardware que lucha con 50 usuarios simultáneos sin caché puede manejar 5.000 o más con Varnish.

Estos números ilustran por qué Varnish vale la complejidad de configuración para tiendas de alto tráfico. La mejora de rendimiento no es incremental — es de un orden de magnitud.

Requisitos de hosting

Varnish tiene requisitos de hosting específicos que no todos los entornos de hosting PrestaShop pueden satisfacer.

Acceso al servidor

Necesitas acceso root para instalar y configurar Varnish. Los planes de hosting compartido no soportan Varnish porque requiere su propio proceso escuchando en un puerto e interceptando todo el tráfico HTTP. Necesitas un VPS, servidor dedicado o instancia en la nube donde controles la pila completa del servidor.

Memoria

Varnish almacena su caché en RAM. La cantidad de RAM que necesitas depende del número de páginas únicas en tu catálogo y el tamaño de cada respuesta cacheada. Una fórmula aproximada: el número de páginas cacheables multiplicado por el tamaño promedio de página te da el tamaño mínimo de caché. Una tienda con 5.000 productos, 200 categorías y un tamaño promedio de página de 50KB necesita aproximadamente 260MB de caché RAM. Añade la sobrecarga para Varnish mismo y deberías asignar al menos 512MB. Para catálogos más grandes, 1-2GB es lo habitual.

Configuración de puertos

En una configuración estándar, Varnish escucha en el puerto 80 (el puerto HTTP por defecto) y reenvía los fallos de caché al servidor web en un puerto diferente (comúnmente 8080). Esto significa que necesitas reconfigurar Apache o Nginx para escuchar en el puerto 8080 en lugar del 80. Si usas HTTPS (y deberías), típicamente colocas Nginx delante de Varnish para manejar la terminación SSL: Nginx en el puerto 443 termina SSL y reenvía a Varnish en el puerto 80, que reenvía los fallos de caché a Apache o PHP-FPM en el puerto 8080.

Ejemplo de configuración Docker

Ejecutar Varnish en Docker junto a un contenedor PrestaShop es una forma limpia de añadir Varnish a una configuración existente sin modificar el sistema host.

Configuración Docker Compose

Una configuración básica de Docker Compose con Varnish, Nginx para SSL y PrestaShop:

services:
  varnish:
    image: varnish:7.4
    ports:
      - "80:80"
    volumes:
      - ./varnish/default.vcl:/etc/varnish/default.vcl:ro
    environment:
      - VARNISH_SIZE=512m
    depends_on:
      - prestashop
  prestashop:
    image: prestashop/prestashop:8
    expose:
      - "80"
    environment:
      - DB_SERVER=db
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=secretpassword
      - MYSQL_DATABASE=prestashop

En esta configuración, Varnish es el punto de entrada en el puerto 80. El contenedor PrestaShop no expone su puerto al host, solo a la red Docker. El host del backend VCL sería prestashop (el nombre del servicio Docker) en el puerto 80.

VCL para Docker

La definición del backend VCL para Docker usa el nombre del servicio en lugar de localhost:

backend default {
  .host = "prestashop";
  .port = "80";
}

El DNS interno de Docker resuelve el nombre del servicio a la IP del contenedor. El resto de la configuración VCL permanece igual que en una configuración sin Docker.

Almacenamiento de caché en Docker

Por defecto, la imagen Docker de Varnish usa almacenamiento en memoria (malloc), que es ideal para el rendimiento. La variable de entorno VARNISH_SIZE controla cuánta memoria Varnish asigna para su caché. Establece este valor en uno que quepa dentro de los límites de memoria de tu contenedor dejando espacio para el propio proceso Varnish.

Para una caché persistente que sobreviva a los reinicios del contenedor, puedes usar almacenamiento basado en archivos montando un volumen, pero esto rara vez es necesario. La caché se calienta rápidamente (en minutos de recibir tráfico) y el almacenamiento basado en archivos es más lento que el almacenamiento en memoria.

Monitorización del rendimiento de Varnish

Varnish proporciona herramientas integradas para monitorizar el rendimiento de la caché.

El comando varnishstat muestra estadísticas en tiempo real incluyendo la tasa de aciertos de caché, conexiones al backend y uso de memoria. La métrica más importante es la tasa de aciertos, que debería ser del 85% o superior para una configuración bien ajustada. Si tu tasa de aciertos está por debajo del 70%, revisa tus reglas VCL porque demasiadas solicitudes están pasando al backend.

El comando varnishlog muestra logs detallados por solicitud, que son invaluables para depurar por qué solicitudes específicas no se están cacheando. Puedes filtrar por patrón de URL, código de respuesta o estado de acierto/fallo de caché.

El comando varnishtop muestra una lista clasificada de las entradas de log más frecuentes, ayudándote a identificar patrones en los fallos de caché o errores.

Errores comunes

Olvidar eliminar cookies

La mala configuración de Varnish más común con PrestaShop es no eliminar las cookies de analytics y seguimiento. Estas cookies están presentes en prácticamente cada solicitud y hacen que cada solicitud sea única desde la perspectiva de Varnish, resultando en una tasa de aciertos del 0%. Elimina siempre las cookies que no necesitas para la variación de caché.

Cachear contenido personalizado

Si tu VCL es demasiado agresivo, cacheará páginas que contienen contenido personalizado (saludo del usuario conectado, contenido del carrito) y las servirá a otros visitantes. Esto causa serios problemas de usabilidad y potenciales problemas de privacidad. Pasa siempre las solicitudes que contienen cookies de sesión al backend.

No invalidar al cambiar contenido

Sin un mecanismo de purga adecuado, los cambios de contenido en el back office no serán visibles hasta que las páginas cacheadas expiren naturalmente. Para una tienda con cambios activos de inventario, esto significa que los visitantes podrían ver productos agotados, precios incorrectos o descripciones desactualizadas. Implementa soporte PURGE o BAN e intégralo con los hooks de actualización de PrestaShop.

Ignorar HTTPS

Varnish no maneja SSL de forma nativa. Debes colocar un proxy de terminación SSL (Nginx, HAProxy o un balanceador de carga en la nube) delante de Varnish. No planificar esto en tu arquitectura conduce a problemas de contenido mixto (mixed content), bucles de redirección o la imposibilidad de servir tráfico HTTPS en absoluto.

¿Es Varnish adecuado para tu tienda?

Varnish es una herramienta poderosa, pero no es la elección correcta para cada tienda PrestaShop. Añade complejidad operativa: otro servicio que monitorizar, otro lenguaje de configuración que aprender, otra capa en tu proceso de depuración. Los beneficios son claros y medibles para las tiendas que los necesitan, pero vienen con un coste en tiempo de configuración, mantenimiento y dificultad de resolución de problemas.

Si tu tienda sirve menos de 50.000 páginas vistas al día y tu servidor maneja la carga cómodamente con un módulo FPC, Varnish es complejidad innecesaria. Si tu tienda enfrenta regularmente picos de tráfico que sobrecargan tu servidor, sirve un alto volumen de tráfico de navegación anónima o necesita los tiempos de respuesta más rápidos posibles para SEO o experiencia de usuario, Varnish proporciona un nivel de rendimiento que ninguna solución de caching basada en PHP puede igualar.

Comienza con una optimización adecuada de PrestaShop (optimización de consultas, auditoría de módulos, PHP OPcache, optimización de imágenes) y un módulo FPC. Si esas optimizaciones no son suficientes, Varnish es el siguiente paso en la escalera de escalado del rendimiento.