Fecha de entrega estimada

Checkout Revolution muestra las opciones de envío proporcionadas por sus módulos de transportista, incluyendo cualquier información sobre tiempo de entrega que proporcionen. Si su módulo de transportista incluye fechas estimadas de entrega, aparecerán. El módulo de checkout en sí no calcula fechas de entrega — esa lógica pertenece a los módulos de envío/transportista.

Learn more in our one-page checkout guide.

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

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.

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.

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.

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

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

Rendimiento admin PrestaShop: por que el back office es lento

Un back office PrestaShop lento es uno de los problemas mas frustrantes. Esta guia identifica las causas mas comunes y proporciona soluciones concretas.

Las causas mas comunes

1. Conexion API PrestaShop Addons

Causa numero uno. El back office hace peticiones HTTP a addons.prestashop.com. Cuando esta API es lenta, todo tu back office espera.

Solucion - Desconectarse de la cuenta Addons o desactivar las llamadas API.

2. Modo debug activado

Desactiva todas las caches y recompila los templates en cada peticion.

define('_PS_MODE_DEV_', false);

3. Demasiados modulos instalados

Cada modulo agrega sobrecarga. Desinstalar modulos no utilizados.

4. Base de datos grande sin optimizar

DELETE FROM ps_cart WHERE id_cart NOT IN (
    SELECT id_cart FROM ps_orders
) AND date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

OPTIMIZE TABLE ps_cart, ps_connections, ps_guest;

5. Limitaciones del hosting compartido

Recomendacion: VPS con 2+ CPU, 4 GB RAM, SSD y PHP 8.1+.

6. OPcache no activado

opcache.enable = 1
opcache.memory_consumption = 256

7. Widgets del dashboard lentos

Simplificar el dashboard. Eliminar widgets innecesarios.

8. Gran catalogo de productos

Reducir productos por pagina a 20-50.

Checklist de optimizacion

1. Desactivar modo debug
2. Compilacion de templates: "Nunca recompilar"
3. Activar cache (Redis preferido)
4. Activar OPcache
5. Desconectar de API Addons
6. Desinstalar modulos no usados
7. Limpiar la base de datos
8. Simplificar dashboard
9. Cambiar a VPS/dedicado
10. Usar PHP 8.1+

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

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

Por que las combinaciones causan problemas de rendimiento

Arquitectura de la base de datos

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

El problema del crecimiento exponencial

Limites practicos

Solucion 1 - Reestructurar el catalogo

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

Solucion 2 - Optimizacion de base de datos y servidor

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

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

Solucion 3 - Carga progresiva de combinaciones

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

Solucion 4 - Estrategias de cache

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

Cuando evitar las combinaciones completamente

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

Recomendaciones por cantidad de combinaciones

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.