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 (core, módulos, tema) y qué implican: ver publicación
Capítulo 2/7 – Cada cuánto revisar y actualizar tu PrestaShop (rutina y calendario realista): ver publicación
Resumen del capitulo anterior 2/7: definimos una rutina práctica de mantenimiento (semanal/mensual/trimestral) y criterios claros para decidir cuándo actualizar (seguridad, compatibilidad, cambios críticos) sin improvisar ni “romper la tienda”.
Antes de actualizar: checklist de seguridad y copias (para poder volver atrás)
Actualizar sin red es el motivo número 1 de los “sustos” en PrestaShop. No porque el sistema sea malo, sino porque una actualización es un cambio real en código, base de datos y dependencias: si algo falla, necesitas volver al estado anterior de forma rápida y limpia.
En este post vamos a montar esa “red”: un checklist de seguridad y copias, con ejemplos, para que cualquier actualización (módulo, tema o core) tenga un plan de vuelta atrás.
El objetivo: poder deshacer en minutos (no en horas)
Antes de tocar nada, hazte esta pregunta:
Si la tienda se rompe, ¿puedo volver exactamente al estado anterior en 10–15 minutos?
Si la respuesta es “no”, tu prioridad no es actualizar: es preparar backup y recuperación.
Copia “de verdad”: qué hay que guardar sí o sí
Una copia útil para PrestaShop no es solo “descargar la base de datos”. Necesitas cubrir estas piezas:
Base de datos (obligatorio)
Ahí vive todo: pedidos, clientes, catálogo, configuraciones, módulos…
MySQL/MariaDB dump completo
Incluye rutinas y triggers si los hay (dependiendo del hosting)
Ideal: un dump con compresión (
.sql.gz) para ahorrar espacio
Archivos del proyecto (obligatorio)
Sin los archivos, no hay tienda aunque tengas la base de datos.
/config//modules//themes//override/(si existe)/classes/(si has tocado cosas)/translations//mails/(si personalizaste plantillas de correo)
Archivos subidos por el usuario (muy importante)
/img/(productos, categorías, marcas…)/upload/(ficheros subidos)/download/(productos descargables)/files/(si existe según versión/configuración)
Ejemplo típico de desastre: “restauré el código y la DB, pero faltan imágenes”. Eso es porque no se guardó
/img.
Configuración del servidor (recomendado)
En muchas incidencias, el problema aparece por PHP o el web server:
Versión de PHP y extensiones
Configuración Nginx/Apache
php.ini(memoria, upload limits, max_execution_time)Cron (tareas programadas)
Redis/Memcached si lo usas
No siempre hace falta “backupear” todo esto, pero sí tenerlo documentado o versionado.
Copia rápida vs copia completa
Puedes tener dos niveles (ideal si actualizas a menudo):
Copia rápida (para módulos pequeños)
Dump de DB
Backup de
/modules/y/config/(mínimo)Backup de
/themes/si hay cambios de tema
Copia completa (para core o cambios sensibles)
Dump DB completo
Copia completa de la carpeta de PrestaShop
Copia de ficheros de usuario (
/img,/upload,/download)Snapshot del servidor si es VPS (lo mejor)
Regla práctica:
Actualización de core = copia completa
Módulo de pago/envíos = copia completa
Módulo menor = copia rápida (pero siempre DB)
Tu “botón rojo”: cómo restaurar (plan de vuelta atrás)
Una copia sin procedimiento de restauración es una falsa seguridad. Define un plan como este:
Poner la tienda en mantenimiento
Restaurar ficheros (o desplegar backup)
Restaurar base de datos
Vaciar caché (PrestaShop + cache server si hay)
Probar:
home
ficha de producto
carrito
checkout
área cliente
Quitar mantenimiento
Consejo: escribe estos pasos en un documento interno y úsalo siempre. El día del susto, te salva.
Staging: la mejor “copia” es probar antes
Si puedes elegir una sola medida, elige esta: un entorno de staging (clon de la tienda) para probar actualizaciones.
Qué debe tener un staging decente
Misma versión de PHP
Mismos módulos y tema
Copia de base de datos y ficheros (idealmente recientes)
Bloqueo de emails y pasarelas reales (para no enviar correos ni cobrar)
Qué pruebas hacer en staging (mínimo)
Login cliente
Carrito + checkout (simulado)
Confirmación de pedido
Back-office: listado de pedidos, catálogo, módulo actualizado
Rendimiento básico (que no vaya lento o con errores 500)
Si staging va bien, la actualización en producción pasa de “miedo” a “rutina”.
Checklist previo a actualizar (cópialo tal cual)
Antes de actualizar, confirma:
Hay backup de DB hecho hoy y validado (archivo existe y pesa “lo esperado”).
Hay backup de archivos (o snapshot) listo.
Tienes un plan de rollback escrito.
Sabes qué estás actualizando y por qué (módulo X / core Y).
Estás en una ventana de baja actividad (si es producción).
Modo mantenimiento preparado y acceso al servidor confirmado.
Tienes acceso a logs (PHP/Nginx/Apache/PrestaShop).
Errores típicos y cómo evitarlos
“Hice backup… pero no sé restaurar”
Solución: ensaya una restauración en staging una vez. A partir de ahí, todo cambia.
“Actualicé y se rompió el back-office”
Suele ser:
caché
incompatibilidad del módulo/tema
override conflictivo
PHP sin memoria suficiente
Con staging + rollback, esto deja de ser un drama.
“El backup está corrupto”
Solución: valida siempre:
el dump abre / se descomprime
el tamaño es razonable
se puede importar (al menos en staging)
Cierre
En este capítulo hemos montado lo más importante: la red de seguridad. A partir de aquí, actualizar deja de ser “arriesgarse” y pasa a ser un proceso controlado: pruebas, despliegas y, si algo falla, vuelves atrás.
En el Capítulo 4/7 vamos a ver el siguiente gran punto que provoca sustos: compatibilidades (módulos/tema/core) y cómo detectarlas antes de actualizar, con un método sencillo para evitar el clásico “actualicé y el checkout dejó de funcionar”. ver capítulo 4: Actualiza PrestaShop en un entorno de pruebas (staging): el paso que evita el 90% de los sustos
