Actualizar PrestaShop sin romper la tienda: guía paso a paso

Para actualizar PrestaShop sin romper la tienda hay que seguir siempre el mismo orden: copia completa de ficheros y base de datos, ensayo de la actualización en una copia de la tienda, actualización real en una franja de poco tráfico y revisión del checkout, el correo y los módulos antes de dar el trabajo por terminado. El asistente oficial hace la parte mecánica; lo que evita los sustos es todo lo que va alrededor.

Este artículo va de las actualizaciones «de mantenimiento»: dentro de la misma rama (8.1 a 8.2) o a la siguiente versión menor (9.0 a 9.1). Un salto de 1.6 o 1.7 a 9 es otra cosa, un proyecto de migración, y lo tratamos aparte.

Actualizar o migrar: no es lo mismo

Se usan como sinónimos y no lo son, y confundirlos lleva a planificar mal:

• Actualizar es cambiar el núcleo de PrestaShop por una versión más reciente sobre la misma tienda. Los datos, el tema y los módulos se quedan; la base de datos se adapta con los scripts de la versión nueva.
• Migrar es llevar la tienda a una versión con cambios de fondo (o a otro servidor), donde el tema, parte de los módulos y los overrides se rehacen y lo que se conserva son sobre todo los datos.

Entre versiones cercanas, actualizar es lo normal y lo recomendable. Cuanto más tiempo pasa sin hacerlo, más se parece cada actualización a una migración: más módulos sin versión compatible, más cambios acumulados en el tema y más distancia en la versión de PHP.

Antes de tocar nada: el inventario

Diez minutos de inventario ahorran horas el día de la actualización. Apunta:

• Versión actual de PrestaShop y de PHP, y qué versión de PHP pide la versión a la que vas. Consulta los requisitos de esa versión antes de nada: si el servidor no los cumple, primero va el cambio de PHP, probado también en copia.
• Tema: si es el de serie, un tema hijo o un tema comprado, y si alguien ha editado sus plantillas directamente.
• Módulos de terceros, con su versión y si el autor declara compatibilidad con la versión de destino.
• Overrides en la carpeta override/: cada uno es código que sustituye una parte del núcleo y que puede dejar de encajar.
• Cambios a mano en ficheros del núcleo: líneas añadidas en config/, reglas en el .htaccess, protección por contraseña de la carpeta del administrador. La actualización los sobrescribe.
• Integraciones que llaman a la tienda: ERP, marketplaces, transportistas, el webservice.

La copia completa, y comprobada

El asistente de actualización ofrece hacer su propia copia, y está bien que la haga, pero no debería ser la única. Antes de empezar, haz una copia tuya de todos los ficheros y de la base de datos, guárdala fuera del servidor y comprueba que se puede restaurar. Una copia que nadie ha restaurado nunca es una esperanza, no una copia.

El ensayo en una copia de la tienda

La regla que más disgustos evita: la actualización se hace primero en una copia, en otro servidor o en un entorno local, con los mismos ficheros y la misma base de datos que producción. Ahí se ve qué módulo falla, qué plantilla del tema da error y cuánto tarda el proceso, que es el dato que necesitas para elegir la franja horaria buena.

En la copia conviene desactivar todo lo que pueda salir a la calle: el correo (que vaya a un buzón de pruebas y no a tus clientes), las pasarelas de pago (en modo pruebas), las tareas programadas que hablan con terceros y las integraciones que envían pedidos al ERP. Una copia de la tienda con el correo real configurado puede escribir a clientes de verdad con un simple cambio de estado de pedido.

Durante la actualización: lo que hemos visto fallar

El asistente oficial de PrestaShop (el módulo de actualización en un clic) funciona bien en la mayoría de tiendas, pero hay situaciones que se repiten en tiendas reales:

• Cerrar el navegador a mitad. El asistente avanza por pasos desde la propia página del back-office. Si se cierra la pestaña o se corta la conexión, el proceso se para. Deja el ordenador conectado y sin tocar hasta que termine; si se interrumpe, se puede reanudar por consola, pero es mejor no llegar ahí.
• Integraciones que siguen llamando. El modo mantenimiento oculta la tienda a los clientes, pero no corta el webservice. Un ERP que sigue sincronizando durante la actualización puede ir regenerando la caché mientras el asistente la borra, y el proceso se detiene. Pausa las integraciones antes de empezar.
• Poca memoria en la consola. En algunos alojamientos, el PHP de la línea de comandos tiene menos memoria que el de la web. Si la actualización se lanza por consola, comprueba ese límite antes.
• Ficheros del núcleo sustituidos. La actualización reemplaza ficheros como config/config.inc.php o el .htaccess de la carpeta del administrador. Lo que se hubiera añadido a mano ahí desaparece sin aviso, incluida una protección por contraseña del panel. Guárdalo antes y repónlo después.
• Base de datos incompleta. En alguna subida de versión menor hemos visto que la tienda actualizada no tenía todas las tablas o ajustes que sí trae una instalación nueva de esa versión, y el escaparate fallaba en muchas páginas. Por eso el ensayo tiene que recorrer la tienda entera, no solo la portada.

Al terminar, es normal que el back-office cierre la sesión: hay que volver a entrar.

Después de actualizar: la lista de comprobación

Una actualización no está terminada cuando el asistente dice que ha ido bien, sino cuando has comprobado esto:

Cada cuánto actualizar

Las versiones de mantenimiento corrigen fallos y, a menudo, problemas de seguridad. Lo sano es no dejar pasar mucho tiempo desde que sale una versión de tu rama, con el ensayo previo de siempre. Una tienda que se actualiza de forma regular tiene actualizaciones pequeñas y predecibles; una que se toca cada varios años acumula cambios y cada actualización es un proyecto.

Lo mismo vale para los módulos y para PHP: ir al día por partes es más barato que ponerse al día de golpe. Si la tienda lleva tiempo sin tocarse, lo prudente es empezar con una revisión que diga qué hay instalado y qué orden seguir.

Cuándo pedir ayuda

Una actualización menor en una tienda con tema de serie y pocos módulos la puede hacer alguien con experiencia en el back-office, siempre con copia y ensayo. Conviene que la haga un técnico cuando hay overrides, un tema muy personalizado, integraciones con ERP o marketplaces, o un volumen de pedidos que no permite que la tienda falle ni una mañana. En el servicio de migraciones y actualizaciones de PrestaShop hacemos el ensayo en una copia, te decimos qué se rompe antes de tocar producción y dejamos la tienda revisada. Y si prefieres que alguien se ocupe de esto de forma periódica, el mantenimiento de PrestaShop incluye las actualizaciones con su copia y su comprobación.

Preguntas frecuentes

¿Se puede actualizar PrestaShop sin perder datos?

Sí. Una actualización conserva productos, clientes y pedidos, porque adapta la base de datos existente. Aun así, haz siempre una copia completa antes: es lo que te protege si el proceso se interrumpe.

¿Cuánto tarda una actualización de PrestaShop?

Depende del tamaño de la tienda y del servidor. El ensayo en una copia te da el tiempo real, y con él eliges una franja de poco tráfico para hacerlo en producción.

¿Tengo que actualizar los módulos también?

Normalmente sí, sobre todo los que el autor marca como compatibles solo con versiones concretas. Comprueba la compatibilidad de cada uno antes de actualizar el núcleo.

¿Qué hago si la actualización falla a mitad?

No vuelvas a lanzarla a ciegas. Revisa en qué paso se quedó: a veces se puede reanudar, y si no, se restaura la copia y se repite el ensayo para saber qué la ha parado.