En qué orden actualizar PrestaShop, PHP, tema y módulos sin romper la tienda

Una tienda PrestaShop tiene cuatro piezas que envejecen a ritmos distintos: el núcleo, la versión de PHP del servidor, el tema y los módulos. Cada una tiene sus propias versiones y cada una exige algo de las otras. Si las actualizas en cualquier orden, tarde o temprano llegas a una combinación que no funciona: un módulo que no arranca con el PHP nuevo, un tema que llama a una función que el núcleo ya no tiene o un núcleo que no se instala porque el PHP es demasiado antiguo.

La buena noticia es que el orden correcto casi siempre se deduce de una sola regla. Vamos con ella y con el procedimiento completo.

La regla: no pasar nunca por una combinación sin soporte

Cada versión de PrestaShop admite un intervalo de versiones de PHP. Cada módulo y cada tema declaran (o deberían declarar) con qué versiones de PrestaShop y de PHP funcionan. Actualizar bien consiste en ir dando pasos de forma que, después de cada paso, todas las piezas sigan dentro de lo que soportan.

Eso tiene una consecuencia práctica: casi nunca puedes saltar directamente al final. Si tu tienda está en una versión antigua con un PHP antiguo, y la versión de destino exige un PHP más moderno que la de origen no soporta, necesitas un paso intermedio. A veces es una versión intermedia del núcleo; a veces, un PHP intermedio que admitan las dos.

Antes de tocar nada: inventario

Haz una tabla con todo lo que tiene la tienda. Sin ella, el orden es una adivinanza.

• Versión exacta del núcleo y versión de PHP que usa la web (que puede no ser la misma que la del terminal del servidor).
• Tema: si es el de serie, uno comprado o uno a medida, si tiene tema hijo y quién lo mantiene.
• Módulos instalados, con versión, autor y de dónde se descargaron. Marca los que ya no usas: no hay que actualizarlos, hay que retirarlos.
• Overrides en la carpeta override/. Son los primeros en romperse cuando cambia el núcleo, porque sustituyen clases enteras o métodos que pueden haber cambiado de firma.
• Integraciones externas: ERP, pasarelas, marketplaces, transportistas. Cada una es un módulo o un script que también depende de versiones.

Para cada módulo, apunta la última versión compatible con tu núcleo actual y con el de destino. Los que no tengan versión para el destino son el verdadero trabajo del proyecto: hay que buscar un sustituto, pedírsela al autor o adaptarlos.

El orden que funciona en la mayoría de casos

1. Copia completa de ficheros y base de datos, y comprueba que se puede restaurar.
2. Retira lo que sobra. Módulos desinstalados que siguen en disco, módulos instalados que nadie usa, overrides huérfanos. Cada pieza que quitas es una pieza menos que actualizar y probar.
3. Actualiza los módulos dentro de tu versión actual hasta la última versión que la soporte. Muchas veces esa misma versión ya funciona también en el núcleo de destino, y así el salto grande se hace con módulos modernos.
4. Actualiza el tema a la última versión compatible con tu núcleo actual, si el fabricante la tiene. Si es un tema a medida, revisa antes las plantillas que más cambian entre versiones: checkout, carrito y ficha de producto.
5. Actualiza el núcleo, primero a la última revisión de tu rama y después, si toca, a la rama siguiente.
6. Cambia la versión de PHP a la más moderna que soporte el núcleo nuevo y que admitan todos tus módulos.
7. Vuelve a revisar módulos y tema: algunos tienen una versión específica para la rama nueva que solo se puede instalar cuando el núcleo ya está actualizado.

Por qué en una copia, y no en producción

Todo lo anterior se ensaya primero en una copia de la tienda, con los mismos ficheros, la misma base de datos y, a ser posible, el mismo PHP y la misma configuración de servidor. En la copia puedes equivocarte, volver atrás y repetir. En producción, cada intento fallido lo ven tus clientes.

Durante el ensayo, apunta cada paso con el detalle suficiente para repetirlo: qué módulo se actualizó, en qué orden, qué ajuste hubo que tocar a mano, qué fichero del tema se corrigió. El día del cambio no se improvisa: se repite la lista.

Qué probar después de cada paso

• Portada, una categoría con filtros, una ficha con combinaciones y el buscador.
• Alta de cliente, inicio de sesión y recuperación de contraseña.
• Un pedido completo con cada método de pago, en el modo de pruebas de cada pasada, hasta ver el pedido en el estado correcto.
• Los correos que salen al cliente (sin que lleguen a nadie de verdad: en la copia el correo debe estar capturado).
• Back-office: listado de pedidos, ficha de un pedido, factura en PDF, edición de un producto.
• El registro de errores de PHP y el de PrestaShop: lo que no rompe la página también cuenta.

Qué suele romperse

• Overrides que redefinen métodos del núcleo que han cambiado. El síntoma es un error fatal nada más actualizar, a veces solo en una página concreta.
• Módulos de pago con versiones antiguas que usan hooks o clases retirados. Son los más delicados, porque el fallo puede estar en el retorno de la pasarela: el cliente paga y el pedido no se crea.
• Plantillas del tema que esperan variables que el núcleo ya no envía o que se llaman distinto.
• Funciones de PHP retiradas o comportamientos que pasan de aviso a error al subir de versión. Un módulo que funcionaba con avisos silenciados puede dejar de funcionar del todo.
• Cachés que conservan clases compiladas de la versión anterior. Vaciarlas forma parte del procedimiento, no es un truco de última hora.

La ventana del cambio

Con el ensayo hecho, elige cuándo aplicarlo en producción:

• Un momento de poco tráfico que tú puedas mirar en tus estadísticas, no el que suponen todos.
• Lejos de campañas y de días de envío fuerte. No actualices la víspera de rebajas ni un viernes por la tarde si el lunes no hay nadie para mirar.
• Con la gente disponible: quien hace el cambio, quien prueba los pagos y quien puede llamar al hosting si hace falta.
• Con un plan de vuelta atrás escrito: qué copia se restaura, cuánto tarda, y a partir de qué síntoma se decide volver. Si la tienda ha recibido pedidos entre la copia y la vuelta atrás, hay que saber cómo recuperarlos.

Pon la tienda en mantenimiento durante el cambio, dejando tu IP con acceso para probar, y no la abres hasta haber completado la misma lista de pruebas que en el ensayo.

Después del cambio

Los primeros días son de vigilancia. Revisa el registro de errores, compara los pedidos con los cobros de la pasarela y pregunta al equipo de atención si llegan consultas raras. Muchos fallos de una actualización no aparecen en la primera hora, sino cuando alguien usa por primera vez una función poco habitual: un cupón concreto, un transportista que solo sale para ciertas provincias o una factura rectificativa.

Y deja apuntado el estado final en el inventario. La siguiente actualización empieza por ahí, y será mucho más corta si no dejas pasar años entre una y otra.

Cómo resolverlo en PrestaShop

En Rekire hacemos este trabajo a diario, desde una actualización de revisión dentro de la misma rama hasta una migración entre versiones mayores. Con un bono de horas de soporte (20 o 50 horas, según el tamaño de la tienda) preparamos el inventario de núcleo, PHP, tema y módulos, montamos la copia de pruebas, ensayamos el orden de actualización con su lista de pruebas y aplicamos el cambio en producción en la ventana que elijas. Las horas se consumen según el trabajo real, así que puedes empezar por el inventario y decidir después hasta dónde llegar.