Actualizar PrestaShop sin romper módulos, tema ni pedidos

Actualizar PrestaShop es una tarea que muchas tiendas aplazan hasta que algo las obliga, normalmente porque el hosting retira una versión de PHP o porque una pasarela de pago deja de funcionar. Cuanto más se espera, mayor es el salto y más piezas pueden fallar a la vez. En esta guía repasamos qué revisar antes de empezar y en qué orden hacerlo para que la tienda siga cobrando pedidos.

Qué supone actualizar PrestaShop según el salto de versión

El riesgo depende mucho de la distancia entre la versión que tienes y la de destino. A grandes rasgos hay tres tipos de salto:

• Parche dentro de la misma versión menor, por ejemplo entre dos 8.2.x: corrige errores y vulnerabilidades. Suele dar pocos problemas, pero también se prueba.
• Versión menor dentro de la misma rama, como de 8.1 a 8.2: puede cambiar hooks, plantillas del back office y alguna dependencia.
• Cambio de rama, de 1.7 a 8 o de 8 a 9: cambian los requisitos de PHP y componentes internos, y es donde más sufren los módulos y temas antiguos.

La rama 9 se publicó en 2025, se apoya en Symfony 6.4 y ya tiene varias versiones menores. Trae además un tema nuevo, Hummingbird, que en la 9.0 no era el tema por defecto. Mientras tanto, la rama 8.2 ha seguido recibiendo versiones de seguridad, así que quedarse en 8.2 actualizada es una opción razonable mientras preparas el salto.

El módulo oficial de actualización, Update Assistant (antes conocido como 1-Click Upgrade), trabaja con tiendas a partir de 1.7. Que el módulo permita un salto grande no garantiza que tus módulos y tu tema lo aguanten. Si vienes de 1.7, muchas veces compensa pasar primero a 8, estabilizar la tienda y después plantear la 9. Si la instalación arrastra demasiados parches, valora también montar una instalación limpia y migrar los datos.

PHP y servidor: el requisito que decide el orden

Cada versión de PrestaShop funciona con un rango concreto de PHP, y ese rango marca el orden de los pasos. Según la documentación oficial:

• PrestaShop 1.7.8 funciona hasta PHP 7.4, que es la versión recomendada para esa rama, y no admite PHP 8.
• PrestaShop 8.0 a 8.2 admite desde PHP 7.2 hasta PHP 8.1.
• La rama 9 exige como mínimo PHP 8.1, y la versión máxima admitida varía según la versión menor.

Esto obliga a ir por escalones. Una tienda en 1.7.8 con PHP 7.4 actualiza primero a 8.x sin tocar PHP, después sube PHP a 8.1 y solo entonces puede plantearse la 9. El problema más habitual es el contrario: el hosting cambia la versión de PHP por su cuenta y la tienda deja de cargar. Antes de empezar, consulta la tabla de compatibilidad de la versión exacta de destino y confirma con tu proveedor de hosting qué versiones de PHP y de MySQL o MariaDB puedes usar y cuándo cambian.

Revisa también los módulos de pago que vienen cifrados. Algunos solo funcionan con las versiones de PHP para las que el fabricante los preparó, y fallan en cuanto cambias PHP aunque PrestaShop sea compatible.

Inventario de módulos, overrides y tema

Antes de tocar nada, haz una lista de lo que hay instalado. Es la parte más aburrida y la que más problemas evita.

Módulos

Para cada módulo, activo o desactivado, anota:

• De dónde viene: Addons, otro marketplace o desarrollo propio.
• Versión instalada y si existe una versión compatible con la de destino.
• Fecha de su última actualización y si el autor sigue respondiendo.
• Si alguien lo usa todavía.

Los que nadie usa se desinstalan antes de actualizar. Los abandonados obligan a decidir entre sustituirlos, adaptarlos o reescribirlos; en módulo PrestaShop propio o comprado explicamos cómo valorarlo.

Overrides

En la carpeta override están las clases y controladores del núcleo que algún módulo, o alguien a mano, ha sobrescrito. Tras una actualización la clase original puede cambiar mientras el override sigue ejecutando el código viejo, y el resultado son errores difíciles de rastrear. Revisa qué overrides hay, qué módulo los creó y si hoy existe un hook que permita hacer lo mismo. Los overrides que no pertenecen a ningún módulo son los más peligrosos, porque nadie recuerda por qué están ahí. Sustituirlos por un módulo PrestaShop a medida que use hooks suele ser la salida más estable.

Tema

Comprueba si el tema es un tema hijo o si se modificó directamente, qué plantillas de módulos sobrescribe y si el autor ofrece versión para la rama de destino. Un tema pensado para 1.7 puede funcionar en 8 con ajustes y necesitar bastante más trabajo en 9.

Copia de seguridad y entorno de pruebas

La actualización se ensaya entera en una copia antes de tocar la tienda real. Para que el ensayo sirva:

• Haz copia de archivos y base de datos y comprueba que se puede restaurar, restaurándola precisamente en el entorno de pruebas.
• Monta la copia con las mismas versiones de PHP y de base de datos que tendrá producción después de actualizar.
• Protege el entorno con contraseña y ponlo fuera del índice de los buscadores.
• Desactiva en la copia los correos a clientes, pon las pasarelas en modo de pruebas y desconecta o redirige a sus entornos de prueba el ERP, el almacén y los transportistas.

Este último punto se olvida a menudo. Una copia conectada al ERP real puede crear pedidos duplicados o enviar correos a clientes que no han comprado nada. Si tu instalación es multitienda, añade las comprobaciones que explicamos en PrestaShop multitienda sin cambios cruzados.

Orden de los pasos para actualizar en producción

Cuando el ensayo en la copia sale limpio, se repite en producción con este orden:

• Documenta cada error del ensayo y cómo se resolvió, para aplicar las mismas correcciones.
• Actualiza los módulos que tengan una versión compatible con la versión actual y con la de destino.
• Elige una franja de poca actividad, avisa al equipo y congela los cambios de catálogo y precios.
• Activa el modo mantenimiento y haz una copia final justo antes de empezar.
• Ejecuta la actualización con Update Assistant, desde el panel o desde la línea de comandos. En tiendas con mucho catálogo la línea de comandos evita depender de los límites de tiempo del navegador.
• Cambia la versión de PHP si este escalón lo requiere.
• Vacía la caché, revisa los overrides y aplica las correcciones anotadas.
• Haz las pruebas de pedido antes de quitar el modo mantenimiento.

Decide el día anterior, con calma, hasta qué hora se sigue intentando y en qué momento se restaura la copia.

Pruebas de pedido después de actualizar

Que la portada cargue dice poco del estado de la tienda. Antes de abrir, comprueba que se puede comprar y que el pedido llega a donde tiene que llegar. Como mínimo, prueba:

• Alta de cliente, inicio de sesión y recuperación de contraseña.
• Carrito con un producto con combinaciones y con un descuento aplicado.
• Cada transportista activo, con un par de direcciones distintas.
• Cada método de pago, en modo de pruebas o con una compra real de importe bajo que luego reembolsas.
• Correo de confirmación, factura en PDF y cambios de estado del pedido.
• Envío del pedido al ERP o al almacén, si existe esa conexión.
• Buscador, filtros de categoría y páginas de producto con más tráfico.
• En el back office, edición de un producto, creación de un pedido manual y las importaciones habituales.

Durante los días siguientes, revisa los registros de errores de PHP y de PrestaShop. Muchos fallos aparecen solo con una combinación concreta de carrito o con un módulo que se ejecuta por la noche.

Checklist antes de actualizar PrestaShop

• Versión actual y versión de destino decididas, con el escalón intermedio si hace falta.
• Versiones de PHP y base de datos confirmadas con el hosting para cada escalón.
• Inventario de módulos con su compatibilidad, y los que sobran desinstalados.
• Overrides revisados, con su origen y su alternativa.
• Compatibilidad del tema confirmada con su autor o probada en la copia.
• Copia restaurada y entorno de pruebas aislado de clientes, pagos y ERP.
• Ensayo completo documentado.
• Franja horaria, responsable y punto de vuelta atrás acordados.
• Lista de pruebas de pedido preparada.

Si un módulo del que depende la venta no tiene versión compatible, aplaza el cambio de rama, sigue aplicando los parches de seguridad de tu rama actual y resuelve ese módulo primero. Si prefieres que alguien haga el inventario y el ensayo contigo, en mantenimiento PrestaShop empezamos por ese diagnóstico antes de tocar la tienda.