Este post pertenece a una serie de posts explicativos de Actualizaciones en PrestaShop sin sustos. Puedes ver los posts previos en estos enlaces:
Capítulo 1/7: Tipos de actualizaciones en PrestaShop: cuáles hay y por qué importan. Ver publicación.
Capítulo 2/7: Cada cuánto actualizar PrestaShop: frecuencia recomendada y señales de alerta. Ver publicación.
Capítulo 3/7: Copias de seguridad y vuelta atrás en minutos. Ver publicación.
Capítulo 4/7: Entorno de pruebas: el paso que evita el 90% de los sustos. Ver publicación.
Por qué necesitas un plan de riesgos (aunque “solo” vayas a actualizar)
Actualizar sin un plan de contingencia es como hacer cambios en producción sin copia de seguridad: puede salir bien… hasta que no sale. En PrestaShop, los fallos más comunes tras una actualización no vienen del core, sino de módulos, tema, overrides o incompatibilidades de PHP. La diferencia entre “un susto” y “un incidente serio” suele estar en una cosa: tener un rollback claro, rápido y probado.
En este capítulo vamos a ver cómo preparar esa red de seguridad: qué riesgos son los más habituales, cómo detectarlos antes, y cómo volver atrás en minutos si algo falla.
Los riesgos típicos al actualizar PrestaShop (y cómo se manifiestan)
Estos son los escenarios que más vemos en tienda real:
Pantalla en blanco / error 500
Causas frecuentes:
PHP incompatible (subes versión sin que tema/módulos estén listos)
overrides rotos o duplicados
módulo incompatible que revienta una clase/servicio
Síntoma: admin o front no carga, 500 en servidor.
Admin funciona, pero el front está roto
Causas frecuentes:
tema no compatible con la versión
assets compilados mal / caché antigua
módulos de checkout o de rendimiento incompatibles
Síntoma: carrito o checkout fallan, elementos descuadrados, JS roto.
Checkout falla o se bloquean pedidos
Causas frecuentes:
módulos de pago/envío incompatibles
cambios en hooks/plantillas
módulos que interceptan el proceso de pedido
Síntoma: no se puede pagar, errores al confirmar pedido.
Rendimiento empeora
Causas frecuentes:
cachés desconfiguradas
módulos nuevos consumiendo más
consultas más pesadas (o índices que faltan)
Síntoma: página lenta, timeouts, CPU alta.
Preparación mínima para poder volver atrás rápido
Un rollback efectivo no se improvisa en medio del caos. Necesitas estas 3 piezas:
Backup de base de datos justo antes
Export de MySQL/MariaDB (idealmente con
--single-transaction)Verifica que el dump se puede restaurar (aunque sea en staging)
Snapshot del código (tienda completa)
Incluye:
/modules/themes/override/config/img(importante)/translations.htaccessy configs del servidor si aplican
Recomendación práctica: comprime la carpeta de la tienda completa con timestamp.
Un “punto de retorno” controlado
Lo más robusto:
snapshot a nivel infraestructura (VM snapshot / volumen / backup del hosting)
o un deploy por releases (carpeta
releases/+ symlinkcurrent/)
Si no tienes eso, puedes hacerlo “manual”, pero asegúrate de poder restaurar:
archivos + base de datos + cachés limpias
Plan de rollback: qué significa “volver atrás” en PrestaShop
Rollback real = volver al estado anterior sin dejar restos.
Checklist de rollback completo:
Modo mantenimiento ON
Restaurar carpeta de tienda (archivos) o volver a release anterior
Restaurar base de datos
Limpiar cachés:
/var/cache/(según versión)Smarty cache/compile si aplica
Confirmar:
admin abre
front carga
checkout funciona
Modo mantenimiento OFF
💡 Importante: si has permitido pedidos durante el cambio, rollback puede “perder” pedidos nuevos al restaurar la BD. Por eso, en ventanas de actualización, lo habitual es bloquear compras (mantenimiento) durante el cambio.
Cómo reducir el riesgo antes de tocar producción
“Preflight” de compatibilidad (10 minutos que ahorran horas)
Lista de módulos críticos (pago, envío, checkout, facturación, rendimiento, marketplace)
Comprobar compatibilidad con:
versión de PrestaShop objetivo
versión PHP objetivo
Revisar overrides: cuantos más overrides, más riesgo
Ensayo en staging con “prueba real”
No vale con “abre la home”.
Prueba mínima obligatoria:
navegar categorías y ficha de producto
añadir al carrito
pasar checkout
simular pago (modo sandbox si es posible)
comprobar emails de pedido
login admin + creación/edición producto
revisar logs de servidor
Ventana y plan de comunicación
elegir una franja de baja venta (madrugada o tramo valle)
avisar a negocio (si hay campaña activa, no es buen momento)
plan de “si pasa X hacemos Y” escrito (aunque sea en un doc simple)
Ejemplo de “plan de actualización” con salida de emergencia
Un ejemplo sencillo que puedes replicar:
Objetivo: actualizar 8.1.3 → 8.1.6 y actualizar 3 módulos críticos
Ventana: 30–45 minutos
mantenimiento ON
backup BD + snapshot carpeta tienda
update en staging (ya hecho) → OK
update en producción
limpiar cachés + revisar front + checkout
si falla checkout:
rollback inmediato (archivos + BD)
mantenimiento OFF
monitorizar 30–60 min (logs + primer pedido)
Así de simple. Lo importante no es que sea largo, es que exista.
Señales para decidir “paro y vuelvo atrás”
No intentes arreglar “en caliente” durante una ventana si:
hay error 500 persistente
checkout bloqueado
admin inaccesible
módulos críticos no cargan
el problema no se identifica en 10–15 minutos
En esos casos, el mejor resultado suele ser:
rollback
investigar con calma en staging
reintentar cuando esté validado
Cierre
Actualizar con seguridad no es solo “hacer backups”: es tener un plan claro de riesgo y rollback, ensayar en staging y saber cuándo parar. Con esto, la mayoría de actualizaciones dejan de ser una lotería y se convierten en un procedimiento repetible.
En el Capítulo 6 vamos a entrar en la parte más práctica: cómo ejecutar la actualización paso a paso (core, módulos y tema) y qué revisar justo después para asegurar que la tienda queda estable. Ver capítulo 6: Checklist post-actualización: cómo validar tu tienda sin perder ventas.
