Migración a PrestaShop 9: Guía completa de actualización

Por qué actualizar a PrestaShop 9

PrestaShop 9 es el mayor cambio arquitectónico desde el salto de la versión 1.6 a la 1.7. No se trata simplemente de un cambio de versión — es una modernización fundamental de la plataforma. Si usted está ejecutando PrestaShop 1.7 u 8.x, la pregunta no es si debería actualizar, sino cuándo y cómo hacerlo correctamente.

Esto es lo que PrestaShop 9 ofrece:

Symfony 6.4 LTS bajo el capó

PrestaShop 9 actualiza de Symfony 4.4 (PS 8.x) a Symfony 6.4 LTS. Esta es una versión con soporte a largo plazo, lo que significa que recibirá parches de seguridad y correcciones de errores hasta noviembre de 2027. La actualización de Symfony trae inyección de dependencias moderna, enrutamiento mejorado, mejor manejo de errores y un ciclo de vida de solicitudes significativamente más rápido.

Para los propietarios de tiendas, esto significa una base más estable y segura. Para los desarrolladores, significa acceso a componentes y patrones modernos de Symfony en torno a los cuales el ecosistema PHP se ha estandarizado.

PHP 8.2+ requerido

PrestaShop 9 requiere PHP 8.2 como mínimo, con soporte completo para PHP 8.3. Esto no es arbitrario — PHP 8.2+ incorpora clases de solo lectura, fibers, un sistema de tipos mejorado y mejoras significativas de rendimiento. Las pruebas de rendimiento muestran una ejecución entre un 5 y un 15% más rápida en comparación con PHP 7.4, con menor uso de memoria en general.

Si usted todavía utiliza PHP 7.4 u 8.0, la actualización a PHP 8.2+ por sí sola hará que su tienda sea notablemente más rápida — incluso antes de modificar PrestaShop.

Twig en todas partes del panel de administración

El back office ha completado su migración de Smarty a Twig. Cada página de administración ahora funciona con plantillas Twig, lo que significa un renderizado más rápido, mejor seguridad (escapado automático de la salida) y un motor de plantillas que está realmente mantenido y bien documentado. Los controladores de administración heredados aún funcionan a través de una capa de compatibilidad, pero la dirección está clara: Twig es el presente y el futuro.

Hummingbird como tema predeterminado

El tema Classic es reemplazado por Hummingbird como tema predeterminado del front office. Hummingbird está construido sobre Bootstrap 5.3, utiliza propiedades personalizadas CSS modernas y es significativamente más ligero que Classic. Está diseñado pensando primero en el rendimiento — paquetes CSS más pequeños, menos JavaScript y mejores puntuaciones de Core Web Vitals desde el primer momento.

Mejoras de seguridad

Symfony 6.4 incorpora un componente de seguridad completamente renovado. El hash de contraseñas utiliza algoritmos modernos (bcrypt/argon2), la protección CSRF es más robusta y el sistema de autenticación se basa en el bundle de seguridad de Symfony en lugar del enfoque heredado basado en cookies de PrestaShop. Las vulnerabilidades de inyección SQL y XSS en las rutas de código heredado han sido eliminadas sistemáticamente.

PrestaShop 9 no es una actualización cosmética. Cambia cómo funciona la plataforma en su núcleo. Por eso exactamente necesita abordar la actualización de forma metódica — la recompensa es una tienda más rápida, más segura y más fácil de mantener, pero solo si realiza la migración correctamente.

Antes de empezar: lista de verificación de requisitos previos

No toque su tienda en producción hasta que haya verificado cada elemento de esta lista. Omitir los requisitos previos es la causa número uno de actualizaciones fallidas.

Requisitos del servidor

• PHP 8.2 o 8.3 — verifique con php -v en su servidor. PHP 8.1 NO funcionará.
• MySQL 8.0+ o MariaDB 10.4+ — verifique con mysql --version. MySQL 5.7 ya no es compatible.
• Extensiones PHP requeridas: intl, gd, curl, zip, mbstring, openssl, pdo_mysql, fileinfo, dom, json
• Composer 2.x — necesario para la gestión de dependencias durante la actualización
• Al menos 256MB de memory_limit en PHP — el proceso de actualización consume mucha memoria
• max_execution_time de al menos 600 segundos — las tiendas grandes necesitan tiempo para las migraciónes de base de datos

Para verificar rápidamente su configuración de PHP:

# Check PHP version
php -v

# Check loaded extensions
php -m | grep -E "(intl|gd|curl|zip|mbstring|openssl|pdo_mysql)"

# Check memory limit and execution time
php -i | grep -E "(memory_limit|max_execution_time)"

# Check MySQL version
mysql --version

Requisitos de versión de PrestaShop

• Primero debe estar en PrestaShop 8.1 o 8.2. No se admiten actualizaciones directas desde 1.7.x o 1.6.x a 9.x.
• Si está en PS 1.7.x, actualice primero a 8.2, estabilice y luego actualice a 9.x.
• Si está en PS 1.6.x — deténgase. Necesita una reconstrucción completa, no una actualización. Consulte la sección “Instalación limpia” más abajo.

Auditoría de compatibilidad de módulos

Aquí es donde la mayoría de las actualizaciones fallan. Antes de actualizar, necesita saber cuáles de sus módulos son compatibles con PS9 y cuáles no.

1. Haga una lista completa de cada módulo instalado (Back Office → Módulos → Gestor de módulos)
2. Para cada módulo de terceros, contacte al proveedor y pregunte: “¿La versión X.Y es compatible con PrestaShop 9?”
3. Para cualquier módulo que no tenga compatibilidad confirmada, necesita un plan: actualizarlo, reemplazarlo o eliminarlo
4. Preste especial atención a los módulos de pago — una pasarela de pago incompatible significa cero ingresos

No asuma que un módulo es compatible porque “funcionaba en PS 8.” PrestaShop 9 elimina APIs y cambia el comportamiento del núcleo. Un módulo que funcionaba perfectamente en 8.2 puede fallar en 9.0 porque llama a una función que ya no existe.

Compatibilidad del tema

• Si está usando el tema predeterminado Classic, necesitará cambiar a Hummingbird o a un tema de terceros compatible con PS9
• Si está usando un tema comprado, verifique la compatibilidad con PS9 con el desarrollador del tema
• Los temas personalizados basados en Classic necesitarán una revisión significativa — la estructura de plantillas ha cambiado
• Los temas hijo de Hummingbird son la ruta recomendada de cara al futuro

Momento oportuno para el negocio

• Nunca actualice durante períodos de máximas ventas (Black Friday, Navidad, promociones importantes)
• Programe la actualización durante su período de menor tráfico — normalmente entre semana, a primera hora de la mañana
• Reserve al menos 48 horas de tiempo de monitoreo después de la actualización antes de su próximo pico de ventas
• Tenga un plan de reversión preparado (se detalla más abajo)

Haga copias de seguridad de todo primero

Esto no es opcional. Esto no es “recomendado.” Este es el paso más importante de todos. Si su actualización falla y no tiene una copia de seguridad, perderá su tienda. Punto.

Copia de seguridad de la base de datos

La base de datos contiene todo lo que importa — productos, clientes, pedidos, configuraciónes, ajustes de módulos. Haga una copia de seguridad con mysqldump:

# Standard mysqldump � works on any server
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

# If your database is large (>1GB), add compression
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop | gzip > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql.gz

Si su PrestaShop se ejecuta en Docker:

# Replace 'my-shop-db' with your actual database container name
docker exec my-shop-db mysqldump -u root -p'YOUR_PASSWORD' --single-transaction --quick prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

Explicación de las opciones:

• --single-transaction — toma una instantánea consistente sin bloquear tablas (crítico para InnoDB)
• --quick — recupera las filas una a una en lugar de almacenarlas en memoria (esencial para tablas grandes)
• --lock-tables=false — evita bloquear las tablas durante el volcado para que su tienda siga en línea

Verifique que su copia de seguridad funciona importándola en una base de datos de prueba:

# Create a test database and import the backup
mysql -u root -p -e "CREATE DATABASE prestashop_backup_test;"
mysql -u root -p prestashop_backup_test < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# Check that it imported correctly
mysql -u root -p prestashop_backup_test -e "SELECT COUNT(*) FROM ps_product; SELECT COUNT(*) FROM ps_orders;"

# Clean up
mysql -u root -p -e "DROP DATABASE prestashop_backup_test;"

Copia de seguridad de archivos

Haga una copia de seguridad del directorio completo de PrestaShop — todos los archivos PHP, temas, módulos, imágenes subidas, todo:

# Full file backup with tar
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /var/www/html/

# If you want to exclude cache and logs (they're regenerated anyway)
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz \
  --exclude='var/cache' \
  --exclude='var/logs' \
  /var/www/html/

Para tiendas basadas en Docker, haga una copia de seguridad del volumen montado:

tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /path/to/docker/html/

Almacene sus copias de seguridad en al menos dos ubicaciones — el propio servidor Y una ubicación externa (su máquina local, un almacenamiento en la nube o un servidor diferente). Una copia de seguridad que solo existe en el mismo disco que su tienda no es una copia de seguridad real.

Notas de configuración

Antes de empezar, documente estos ajustes (los necesitará si tiene que reconfigurar):

• Su archivo app/config/parameters.php (credenciales de la base de datos, configuración del correo, clave de cookies)
• Su archivo .htaccess (especialmente si ha añadido reglas de reescritura personalizadas)
• Configuración SMTP/correo electrónico del back office
• Claves API y configuración de la pasarela de pago
• Configuraciones de tareas programadas (cron jobs)
• Cualquier configuración personalizada del servidor (reglas de Nginx, configuración de pools PHP-FPM)

Tome capturas de pantalla de las páginas de configuración críticas del back office. Cuando algo sale mal durante la actualización, tener una referencia visual de “cómo se veía antes” es invaluable.

Proceso de actualización paso a paso

Existen dos caminos legítimos hacia PrestaShop 9: la actualización in situ usando el módulo oficial, o una instalación limpia con migración de datos. Cada uno tiene su lugar.

Enfoque 1: Módulo de actualización automática (1-Click Upgrade)

La ruta de actualización oficial utiliza el módulo autoupgrade (también llamado “1-Click Upgrade”). Este módulo gestióna el reemplazo de archivos, la migración de la base de datos y la limpieza posterior a la actualización de forma automática.

Preparación

1. Instale o actualice el módulo 1-Click Upgrade a su última versión desde el PrestaShop Marketplace
2. Vaya a Back Office → Módulos → 1-Click Upgrade
3. El módulo mostrará su versión actual y los objetivos de actualización disponibles
4. Ejecute la Lista de verificación previa a la actualización — el módulo verificará la compatibilidad de su servidor y señalará posibles problemas

Active el modo de mantenimiento

# Or do it from the back office: Shop Parameters ? General ? Maintenance ? Enable
# Make sure to whitelist your own IP address

Esto es esencial. Usted no quiere que los clientes realicen pedidos mientras la base de datos está siendo migrada.

Ejecute la actualización

1. En el módulo 1-Click Upgrade, seleccione su versión objetivo (PrestaShop 9.x)
2. Elija “Major upgrade” como canal de actualización
3. Revise las opciones de actualización:
   • Hacer copia de seguridad de archivos y base de datos — active esta opción (doble seguridad, incluso si ya hizo la copia de seguridad manualmente)
   • Desactivar módulos no nativos — active esta opción para prevenir conflictos de módulos durante la actualización
   • Regenerar plantillas de correo electrónico — actívelo si no las ha personalizado
4. Haga clic en “Upgrade PrestaShop now”
5. NO cierre la pestaña del navegador, NO navegue a otra página — espere a que el proceso se complete

La actualización puede tardar desde 5 minutos (tienda pequeña) hasta más de 30 minutos (catálogo grande, muchos módulos). Verá un registro de progreso mostrando cada paso.

Después de que se complete la actualización

# Clear all caches � this is not optional
rm -rf var/cache/*

# If using CLI (recommended):
php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

# Fix file permissions
chown -R www-data:www-data /var/www/html/var/
chown -R www-data:www-data /var/www/html/themes/
chmod -R 755 /var/www/html/var/

Reactive los módulos uno por uno

Si eligió desactivar los módulos no nativos durante la actualización, no los active todos a la vez. Actívelos uno a la vez:

1. Active el módulo
2. Verifique el front office y el back office en busca de errores
3. Si funciona, pase al siguiente módulo
4. Si causa algún problema, desactívelo y contacte al proveedor del módulo

Este enfoque metódico le indica exactamente qué módulo causó el problema, en lugar de quedarse mirando una tienda rota con 30 módulos activados sin saber cuál es el culpable.

Enfoque 2: Instalación limpia + Migración de datos

A veces el camino más limpio es empezar de cero. Instale PrestaShop 9 desde cero y migre sus datos. Este enfoque requiere más trabajo pero le proporciona una instalación impoluta sin ningún lastre heredado.

Cuándo elegir la instalación limpia

• Está actualizando desde PS 1.6.x (la actualización in situ no es compatible con saltos tan grandes)
• Su tienda actual tiene años de overrides acumulados, modificaciones y tablas de módulos abandonados
• De todos modos quiere cambiar de tema
• Su base de datos se ha inflado con carritos abandonados, registros antiguos y datos huérfanos
• Intentos previos de actualización han fallado

El proceso

1. Instale PrestaShop 9 desde cero en un nuevo directorio o servidor
2. Configure su tema (Hummingbird o un tema compatible con PS9)
3. Instale sus módulos (solo versiones compatibles con PS9)
4. Migre sus datos utilizando alguna de estas opciones:
   • Importación CSV de PrestaShop para productos, categorías y clientes
   • Migración directa de base de datos usando scripts SQL personalizados
   • Herramientas de migración de terceros
5. Reconfigure las pasarelas de pago, envíos, impuestos y correo electrónico
6. Pruebe todo en la nueva instalación
7. Cambie el DNS o intercambie el document root cuando esté listo

Migración de datos mediante importación CSV

La herramienta de importación integrada de PrestaShop (Back Office → Parámetros avanzados → Importar) gestióna:

• Categorías
• Productos (con combinaciones, imágenes, características y stock)
• Clientes
• Direcciones
• Fabricantes y Proveedores

Exporte desde su tienda antigua, limpie los archivos CSV e importe en la nueva. Esto es tedioso para catálogos grandes, pero ofrece el resultado más limpio.

Migración de datos mediante SQL

Para desarrolladores experimentados, la migración directa por SQL es más rápida para grandes conjuntos de datos:

# Export specific tables from old database
mysqldump -u root -p old_prestashop \
  ps_product ps_product_lang ps_product_shop \
  ps_category ps_category_lang ps_category_shop \
  ps_customer ps_address \
  ps_image ps_image_lang ps_image_shop \
  ps_stock_available \
  > ~/migration_data.sql

# You'll need to review and adjust the SQL for schema changes between versions
# Column names, table structures, and foreign keys may differ

La migración por SQL requiere un conocimiento profundo del esquema de la base de datos de PrestaShop. Si no se siente cómodo escribiendo y depurando SQL complejo, utilice el método de importación CSV o contrate a un desarrollador. Una migración SQL mal ejecutada puede corromper sus datos de formas extremadamente difíciles de soluciónar.

¿Qué enfoque es mejor?

Para la mayoría de los propietarios de tiendas que ejecutan PS 8.x con un número razonable de módulos bien mantenidos, la actualización automática es la opción correcta. La instalación limpia tiene sentido cuando viene de una versión muy antigua o quiere aprovechar la oportunidad para hacer limpieza.

Compatibilidad de módulos: qué se rompe en PrestaShop 9

Esta sección es para desarrolladores y propietarios de tiendas con curiosidad técnica. Comprender qué ha cambiado le ayuda a evaluar si sus módulos sobrevivirán a la actualización.

Plantillas Smarty eliminadas del panel de administración

Este es el cambio más importante que rompe la compatibilidad. En PS 8.x, los controladores de administración heredados aún podían usar plantillas Smarty (archivos .tpl) para sus páginas de back office. En PS 9, el panel de administración es completamente basado en Twig. Los controladores heredados son envueltos por un LegacyController de Symfony que renderiza su salida a través de Twig.

Lo que esto significa en la práctica:

• Los módulos con páginas de administración personalizadas que usan AdminController + Smarty aún funcionan, pero se renderizan dentro del nuevo diseño Twig a través de una capa de compatibilidad
• Los overrides de plantillas de administración (archivos en override/controllers/admin/templates/) pueden no funcionar como se espera
• Las variables Smarty asignadas en initContent() pueden perderse porque LegacyController envuelve el renderizado de forma diferente — la variable Smarty content necesita ser reasignada explícitamente
• El método display() de AdminController ya no es llamado por PS 9 — LegacyController lo omite por completo

Cambios en el sistema de overrides

PrestaShop ha estado desaconsejando los overrides desde PS 1.7, y PS 9 endurece aún más las restricciones:

• Los overrides de clases del núcleo aún funcionan técnicamente pero son cada vez más frágiles a medida que más código del núcleo se traslada a servicios de Symfony
• Los overrides de controladores son poco fiables — la capa de enrutamiento de Symfony puede no cargarlos como se espera
• Los overrides de plantillas en directorios override/ están obsoletos para las páginas de administración
• El enfoque recomendado ahora son los hooks, los decoradores de Symfony y los suscriptores de eventos

Si tiene módulos que dependen en gran medida de overrides, son los que más probablemente fallarán durante la actualización. Revise el directorio override/ en la carpeta de cada módulo.

Cambios en los hooks

PrestaShop 9 añade nuevos hooks y modifica algunos existentes:

• Varios hooks heredados en el área de administración han sido eliminados o renombrados
• Hay nuevos hooks disponibles para las páginas de administración basadas en Symfony
• Los hooks del front office siguen siendo ampliamente compatibles (Hummingbird utiliza los mismos puntos de hook que Classic)
• El orden de ejecución de los hooks puede cambiar en algunos casos — si su módulo depende de ser llamado antes o después de otro hook, pruébelo

Funciones obsoletas en controladores heredados

Varios patrones de controladores de administración que funcionaban en PS 8.x se comportan de forma diferente en PS 9:

• $this->l() (la función de traducción) ha sido eliminada de los controladores de administración — use $this->module->l('string', 'ControllerClassName') en su lugar
• Tools::displayPrice() ha sido eliminada — use Context::getContext()->getCurrentLocale()->formatPrice($amount, $currencyIsoCode)
• Las propiedades $this->meta_title, $this->fields_list y $this->bulk_actions del controlador de administración deben asignarse DESPUÉS de llamar a parent::__construct() porque la referencia del módulo no está disponible antes de eso
• El directorio de administración ahora es backoffice/ por defecto (no admin-dev ni una cadena aleatoria) — las rutas de administración codificadas de forma fija dejarán de funcionar

Cómo verificar si sus módulos están listos para PS9

Para cada módulo instalado:

1. Consulte el sitio web del proveedor — busque declaraciones explícitas de compatibilidad con PS 9
2. Busque overrides — mire dentro de modules/sumodulo/override/. Cualquier archivo ahí es una señal de alerta.
3. Busque llamadas a funciones obsoletas — busque en los archivos PHP del módulo:
   • Tools::displayPrice(
   • $this->l( en archivos de controladores de administración
   • Clases AdminController con métodos display() complejos
   • Rutas de directorio de administración codificadas de forma fija
4. Revise el archivo config.xml o el archivo PHP principal del módulo buscando la configuración ps_versions_compliancy — ¿incluye 9.x?

# Quick command to find potential PS9 issues in a module
# Run this from inside the module directory

# Check for overrides
find override/ -type f 2>/dev/null && echo "WARNING: Module uses overrides"

# Check for removed functions
grep -rn "Tools::displayPrice" *.php controllers/ classes/ 2>/dev/null
grep -rn '$this->l(' controllers/admin/ 2>/dev/null

# Check version compatibility declaration
grep -A2 "ps_versions_compliancy" *.php

Migración del tema: Hummingbird es ahora el predeterminado

PrestaShop 9 viene con Hummingbird como tema predeterminado, reemplazando a Classic. Si está usando Classic o un tema basado en Classic, necesita un plan de migración.

Qué cambió en Hummingbird

• Bootstrap 5.3 reemplaza a Bootstrap 4 — los nombres de clases, el sistema de cuadrícula y las clases de utilidad han cambiado
• Propiedades personalizadas CSS se utilizan ampliamente para la personalización del tema — los colores, el espaciado y la tipografía se configuran mediante variables CSS en lugar de variables SCSS
• Menos JavaScript — Hummingbird depende más de las funciones nativas del navegador y menos de los plugins de jQuery
• Sistema de compilación moderno — compilación de recursos basada en Webpack con tree shaking adecuado
• Diseño responsive-first — el diseño móvil es la base, el escritorio es la mejora (a diferencia de Classic que era desktop-first)

Si está usando el tema Classic

El tema Classic no está incluido en PS 9. Sus opciones son:

1. Cambiar a Hummingbird — el camino más sencillo. Cree un tema hijo para sus personalizaciónes.
2. Comprar un tema compatible con PS9 — muchos proveedores de temas han lanzado versiones para PS9.
3. Portar sus personalizaciónes de Classic a un tema hijo de Hummingbird — esto requiere trabajo de desarrollo frontend pero le da el mejor resultado a largo plazo.

Crear un tema hijo de Hummingbird

Un tema hijo le permite personalizar Hummingbird sin modificar los archivos del tema principal (para que sus cambios sobrevivan a las actualizaciones del tema):

# Create child theme directory structure
mkdir -p themes/my-child-theme/assets/css
mkdir -p themes/my-child-theme/templates

Cree themes/my-child-theme/config/theme.yml:

parent: hummingbird
name: my-child-theme
display_name: My Custom Theme
version: 1.0.0
author:
  name: Your Name

Añada sus estilos personalizados en themes/my-child-theme/assets/css/custom.css. Hummingbird carga automáticamente custom.css de los temas hijo con la prioridad más baja (se carga en último lugar), de modo que sus estilos anulan los del tema padre.

Para anular una plantilla específica, cópiela desde themes/hummingbird/templates/ a la misma ruta relativa en su tema hijo. Solo copie los archivos que necesita cambiar — todo lo demás se hereda automáticamente del tema padre.

Si está usando un tema comprado

Contacte al proveedor de su tema y haga estas preguntas específicas:

• ¿Hay una versión compatible con PS9 disponible?
• ¿Está basado en Hummingbird o es un tema independiente?
• ¿Mi licencia actual del tema cubre la versión para PS9?
• ¿Cuál es la ruta de migración desde la versión actual?

Si el proveedor no tiene una versión para PS9 y no puede darle un plazo, empiece a planificar su cambio a Hummingbird ahora.

Lista de verificación posterior a la actualización

Ha completado la actualización y su back office se carga. No celebre todavía. Verifique sistemáticamente cada función crítica de su tienda.

Pruebas del front office

Pruebas del back office

Verificación de la pasarela de pago

Esto merece su propia sección porque impacta directamente en los ingresos. Para CADA método de pago:

1. Realice un pedido de prueba real (o use el modo sandbox si está disponible)
2. Verifique que el pago se registra en el panel del proveedor de pagos
3. Verifique que el estado del pedido se actualiza correctamente en PrestaShop
4. Pruebe los reembolsos si su flujo de trabajo los requiere
5. Compruebe las URLs de webhook/IPN — la actualización puede haber cambiado las estructuras de URL

Verificación de envíos

• Verifique que todos los transportistas muestran tarifas correctas para las diferentes zonas
• Pruebe los umbrales de envío gratuito
• Si utiliza cálculo de tarifas de transportista en tiempo real (basado en API), verifique que la conexión aún funciona
• Compruebe que la introducción de números de seguimiento y los correos de notificación funcionan

Tareas programadas (Cron Jobs)

Verifique cada tarea automatizada que se ejecuta de forma programada:

• Correos de carritos abandonados
• Sincronización de stock
• Generación de feeds (Google Shopping, Facebook, etc.)
• Generación del sitemap
• Actualizaciones de tipos de cambio de divisas
• Cualquier script cron personalizado

Las URLs de cron frecuentemente cambian entre versiones principales. Actualice las entradas de su crontab:

# Check your current cron jobs
crontab -l

# PS 9 cron URLs may have changed � verify each one loads correctly
curl -s -o /dev/null -w "%{http_code}" "https://yourshop.com/modules/yourmodule/cron.php?token=XXXXX"

Verificación SEO

• Compruebe que las URLs amigables siguen funcionando (páginas de categorías, páginas de productos)
• Verifique que su sitemap se genera correctamente
• Compruebe que robots.txt es correcto
• Pruebe las páginas de aterrizaje clave que tienen buen posicionamiento — asegúrese de que aún existen en las mismas URLs
• Si las URLs cambiaron, configure redirecciónes 301 inmediatamente

Problemas comunes de actualización y soluciónes

Pantalla blanca de la muerte

El problema más común posterior a la actualización. Usted ve una página en blanco sin ningún mensaje de error.

Solución:

1. Active el modo de depuración editando config/defines.inc.php:

   define('_PS_MODE_DEV_', true);

2. Recargue la página — ahora debería ver el error PHP real
3. Si aún ve la pantalla blanca, revise los registros de errores de PHP:

   # Apache
   tail -50 /var/log/apache2/error.log
   
   # Nginx + PHP-FPM
   tail -50 /var/log/php-fpm/error.log
   
   # PrestaShop's own log
   tail -50 /var/www/html/var/logs/prod.log

4. Causas comunes:
   • Memoria PHP agotada — aumente memory_limit en php.ini a 512M
   • Extensión PHP faltante — instale la extensión requerida y reinicie PHP
   • Problema de permisos de archivos — ejecute chown -R www-data:www-data /var/www/html/var/

Error 500 Internal Server Error

Generalmente causado por problemas de .htaccess o configuración de PHP después de la actualización.

Solución:

# Check if .htaccess is the problem � temporarily rename it
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

# If the site loads without .htaccess, regenerate it from back office:
# Shop Parameters ? Traffic & SEO ? Generate .htaccess file

# Or manually restore the default PS 9 .htaccess

También verifique:

• Que Apache mod_rewrite está habilitado: a2enmod rewrite && systemctl restart apache2
• Que su virtual host de Apache permite overrides de .htaccess: AllowOverride All
• Que la versión de PHP es realmente 8.2+ para el proceso web (no solo para CLI)

Conflictos de módulos después de la actualización

Síntomas: el back office se carga parcialmente, errores en secciones específicas, errores de JavaScript en la consola.

Solución — el método de aislamiento:

1. Desactive TODOS los módulos no nativos:

   # Via database if back office is broken
   mysql -u root -p prestashop -e "UPDATE ps_module SET active = 0 WHERE name NOT IN ('ps_banner','ps_contactinfo','ps_emailsubscription','ps_featuredproducts','ps_imageslider','ps_linklist','ps_mainmenu','ps_searchbar','ps_sharebuttons','ps_socialfollow','ps_wirepayment','ps_checkpayment');"

2. Limpie la caché: rm -rf var/cache/*
3. Verifique que la tienda funciona solo con módulos nativos
4. Active los módulos uno a la vez, limpiando la caché entre cada uno
5. Cuando encuentre el módulo problemático, actualícelo, reemplácelo o contacte al proveedor

Traducciones faltantes o rotas

Después de la actualización, algunas cadenas de traducción pueden faltar o mostrarse como claves sin procesar (como Modules.YourModule.SomeString).

Solución:

• Vaya a Internacional → Traducciones y exporte/importe su paquete de idiomas
• Para traducciones de módulos, restablezca las traducciones del módulo: desinstale y reinstale el módulo (nota: esto puede restablecer la configuración — haga una copia de seguridad primero)
• PrestaShop 9 utiliza el sistema de traducciones de Symfony de forma más intensiva — los archivos de traducción de estilo antiguo (en modules/sumodulo/translations/) pueden necesitar conversión

Problemas de caché

La caché obsoleta está detrás de una cantidad sorprendente de problemas posteriores a la actualización. En caso de duda, límpielo todo:

# Nuclear cache clear
rm -rf var/cache/*

# Symfony cache rebuild
php bin/console cache:clear --env=prod --no-warmup
php bin/console cache:warmup --env=prod --no-optional-warmers

# Fix ownership after cache rebuild
chown -R www-data:www-data var/

# Also clear your browser cache � old cached JS/CSS can cause phantom issues

Imágenes que no se muestran

Las rutas de imágenes o el sistema de recuperación de imágenes pueden cambiar entre versiones.

Solución:

• Regenere las miniaturas: Diseño → Configuración de imágenes → Regenerar miniaturas
• Verifique que los permisos del directorio img/ son correctos
• Si utiliza un CDN, purgue la caché del CDN
• Verifique que el nuevo formato de URL de imágenes coincide con lo que su tema espera

El inicio de sesión del administrador no funciona

Los algoritmos de hash de contraseñas cambiaron en PS 9 (MigratingPasswordHasher de Symfony con bcrypt/argon2). En la mayoría de los casos, las contraseñas existentes funcionarán porque el hasher migra automáticamente en el primer inicio de sesión. Pero si no puede acceder:

# Reset admin password � PS 9 requires Symfony's password hasher
# Do NOT use raw MD5 or direct SQL UPDATE on the password field

# Instead, use PrestaShop's CLI (if available):
php bin/console prestashop:user:change-password --email=admin@yourshop.com

# Or create a temporary PHP script to reset the password properly
# (delete this file immediately after use!)

Nunca deje scripts de restablecimiento de contraseñas en su servidor. Créelos, úselos, elimínelos — todo en una sola sesión. Un script de restablecimiento olvidado es una vulnerabilidad de seguridad.

Cuándo contratar a un desarrollador vs. hacerlo usted mismo

Sea honesto sobre sus habilidades técnicas. Una actualización fallida puede costarle días de ingresos y confianza de los clientes. Aquí tiene una guía realista:

Probablemente puede hacerlo usted mismo si:

• Está actualizando de PS 8.2 a 9.x (un salto de versión)
• Tiene menos de 10 módulos de terceros, todos confirmados como compatibles con PS9
• Está usando un tema estándar (Classic → Hummingbird, o un tema comprado con soporte para PS9)
• Se siente cómodo con SSH, línea de comandos y operaciónes de base de datos
• Tiene un entorno de staging funcional para probar primero
• Su tienda no tiene overrides personalizados ni modificaciones del núcleo

Debería contratar a un desarrollador si:

• Está actualizando desde PS 1.6.x o versiones tempranas de 1.7.x (gran diferencia de versión)
• Tiene más de 20 módulos, especialmente si algunos usan overrides
• Tiene un tema personalizado que necesita portarse a Hummingbird
• Su tienda tiene modificaciones personalizadas del núcleo o archivos de override
• No se siente cómodo con la línea de comandos u operaciónes de base de datos
• Su tienda genera ingresos diarios significativos y el tiempo de inactividad es costoso
• Ha intentado la actualización en staging y ha encontrado problemas que no puede resolver

Qué buscar en un desarrollador

• Experiencia específica en PrestaShop — no solo “desarrollador PHP” o “desarrollador de comercio electrónico.” La arquitectura de PrestaShop es única, y los desarrolladores genéricos dedicarán horas facturables aprendiendo cosas que un especialista en PS ya conoce.
• Experiencia específica en PS 9 — pregunte si han completado actualizaciones a PS 9 anteriormente. La migración a Symfony 6.4 tiene problemas específicos.
• Un plan de proyecto claro — deberían proponer: auditoría → actualización en staging → pruebas → actualización en producción → monitoreo.
• Soporte posterior a la actualización — los problemas suelen surgir 1-2 semanas después de la actualización cuando se activan casos extremos. Asegúrese de que el soporte está incluido.

Rangos de precios típicos

Estas son estimaciones aproximadas basadas en tarifas de mercado en 2025-2026:

• Actualización simple (PS 8.x → 9.x, pocos módulos, tema estándar): 500-1500 EUR
• Actualización media (PS 1.7.x → 9.x, portado de tema personalizado, módulos moderados): 2000-5000 EUR
• Actualización compleja (PS 1.6.x → 9.x, reconstrucción completa, muchos módulos personalizados): 5000-15000+ EUR

Estos precios reflejan la realidad de que una actualización de versión principal no es una operación de un solo clic. Si alguien le cotiza 200 EUR por una actualización de PS 1.6 a PS 9, o no comprende el alcance o va a tomar atajos que le costarán más después.

Plan de reversión: si las cosas salen mal

Usted hizo copias de seguridad (¿verdad?). Así es como usarlas si la actualización falla de forma catastrófica.

Reversión desde la actualización automática

Si utilizó el módulo 1-Click Upgrade y este creó su propia copia de seguridad:

1. Navegue a Back Office → Módulos → 1-Click Upgrade
2. Haga clic en “Rollback” y seleccione la copia de seguridad previa a la actualización
3. El módulo restaurará tanto los archivos como la base de datos

Si el back office es completamente inaccesible, necesitará restaurar manualmente:

Reversión manual — Base de datos

# Drop the current (broken) database and recreate it
mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"

# Import your backup
mysql -u root -p prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# For Docker:
docker exec -i my-shop-db mysql -u root -p'PASSWORD' -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
docker exec -i my-shop-db mysql -u root -p'PASSWORD' prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

Reversión manual — Archivos

# Remove the upgraded files
rm -rf /var/www/html/*

# Restore from your backup
tar -xzf ~/prestashop_files_pre_ps9_XXXXXXXX_XXXXXX.tar.gz -C /

# Fix permissions
chown -R www-data:www-data /var/www/html/

# Clear cache
rm -rf /var/www/html/var/cache/*

Verifique que la reversión funcionó

1. Acceda al front office — ¿se carga su tienda?
2. Acceda al back office — ¿puede iniciar sesión?
3. Revise algunos pedidos — ¿los datos están intactos?
4. Realice un pedido de prueba — ¿funciona el checkout?
5. Desactive el modo de mantenimiento una vez que todo esté confirmado como funcional

Después de una reversión, NO intente la actualización inmediatamente de nuevo. Analice primero qué salió mal. Revise los registros de la actualización, identifique el paso que falló, investigue el error específico y corrija la causa raíz en su entorno de staging antes de volver a tocar la producción.

La emergencia de “no tengo copia de seguridad”

Si no hizo copias de seguridad (sucede — no pretendamos que no), sus opciones son limitadas pero no nulas:

• Copias de seguridad del proveedor de hosting: Muchos proveedores mantienen copias de seguridad diarias durante 7-30 días. Revise su panel de hosting o contacte al soporte inmediatamente.
• Logs binarios de la base de datos: Si el registro binario de MySQL está habilitado, la recuperación a un punto en el tiempo puede ser posible. Esto requiere experiencia avanzada.
• La copia de seguridad del módulo autoupgrade: Si marcó “crear copia de seguridad” durante la actualización, busque en /admin/autoupgrade/backup/ los archivos de copia de seguridad propios del módulo.
• Aceptar y seguir adelante: Si la recuperación no es posible, concéntrese en arreglar la tienda actualizada en lugar de intentar volver atrás. A veces, avanzar es el único camino.

Resumen: la ruta de actualización de un vistazo

1. Auditar — verifique los requisitos del servidor, compatibilidad de módulos, compatibilidad del tema
2. Copia de seguridad — base de datos (mysqldump), archivos (tar), notas de configuración
3. Staging — pruebe la actualización completa en un entorno de staging primero
4. Programar — elija un período de bajo tráfico con tiempo de margen para problemas
5. Actualizar — modo de mantenimiento activado, ejecute la actualización, limpie las cachés
6. Probar — front office, back office, checkout, pagos, envíos, correos electrónicos
7. Monitorear — vigile los registros de errores durante 48 horas después de salir a producción
8. Limpiar — desactive el modo de depuración, elimine archivos temporales, actualice la documentación

PrestaShop 9 es una mejora significativa respecto a sus predecesores. La base de Symfony 6.4, el requisito de PHP 8.2+ y el panel de administración basado en Twig crean una plataforma más estable, más rápida y más fácil de mantener. La actualización requiere una planificación cuidadosa, pero el resultado merece el esfuerzo — un motor de comercio electrónico moderno que le servirá bien durante los próximos años.

Tómese su tiempo, pruebe exhaustivamente y no omita las copias de seguridad. Su yo del futuro se lo agradecerá.