Una migración de versión mayor rara vez se juega en el núcleo de PrestaShop, que se actualiza correctamente en la mayoría de los casos. Se juega en tus módulos. En una tienda que cuenta cuarenta, basta con que uno solo toque el proceso de compra y ya no sea compatible para bloquear toda la migración.
La auditoría de módulos debe por tanto preceder a todo lo demás, incluido el presupuesto.
Lo que cambia realmente
PrestaShop 9 se apoya en versiones más recientes de PHP y de Symfony, lo que provoca tres familias de rupturas.
Las rupturas ligadas a PHP. Tipado más estricto, propiedades dinámicas obsoletas, funciones retiradas. Un módulo escrito hace cinco años y nunca retomado produce errores fatales, no avisos.
Las rupturas ligadas al framework. Los módulos que extienden controladores Symfony o que declaran servicios deben seguir la nueva versión. Es el caso de los módulos recientes y bien construidos, paradójicamente más expuestos que los puramente legacy.
Las rupturas propias de PrestaShop. Métodos eliminados de las clases históricas, hooks retirados o renombrados, cambios en las plantillas del tema por defecto.
El inventario, primer entregable
Antes de cualquier manipulación, produce una tabla con una fila por módulo y seis columnas.
- Nombre técnico y versión instalada.
- Editor, y su existencia actual. Un editor desaparecido es un módulo condenado.
- Fecha de la última actualización disponible. Más allá de dieciocho meses sin publicación, considera el módulo abandonado mientras no se demuestre lo contrario.
- Compatibilidad anunciada con la versión destino, distinguiendo lo que está escrito en la ficha de producto de lo que se ha probado realmente.
- Criticidad: ¿el módulo toca el pago, el proceso de compra, el catálogo, o solo una visualización secundaria?
- Presencia de overrides, visible en la carpeta de sobrecargas. Es el mejor indicador de fragilidad.
Esta tabla se rellena en media jornada y determina todo el resto del proyecto.
Las cuatro categorías
Cada módulo cae en una de ellas, y el tratamiento difiere.
Compatible y mantenido. Actualizas y pruebas. Es el caso más simple, y rara vez representa la mayoría.
Compatibilidad anunciada pero no verificada. La mención en la ficha de producto no equivale a una prueba de aceptación. Estos módulos deben probarse con prioridad, porque una incompatibilidad descubierta tarde cuesta un aplazamiento.
Abandonado. Dos salidas: encontrar un reemplazo, o hacer retomar el código. Retomarlo solo tiene sentido si la funcionalidad es específica de tu actividad.
Reemplazable por funciones nativas. Categoría sistemáticamente subestimada. Cada versión mayor integra funciones que antes existían en forma de módulo. Una migración es el buen momento para desinstalar lo que ya no sirve.
En las auditorías reales, este último filtro retira a menudo entre cinco y diez módulos de la lista, lo que aligera otro tanto el proyecto.
Verificador de Enlaces Rotos PrestaShop 8 y 9 — Enlaces Muertos e Imágenes FaltantesEncuentra los enlaces muertos y las imágenes rotas antes que tus clientes€59,00
Las trampas técnicas más frecuentes
Para los desarrolladores y las agencias, cuatro rupturas vuelven constantemente en los módulos que hay que retomar.
El método de traducción disponible directamente en los controladores ha desaparecido: hay que pasar por la instancia del módulo. Las sobrecargas de métodos cuya firma ha cambiado producen errores de compatibilidad, en particular en los métodos de renderizado utilizados para las respuestas asíncronas. Las llamadas asíncronas a los controladores de administración históricos han cambiado de forma y exigen que los parámetros se pasen de otra manera. Y los módulos que escribían directamente en tablas del núcleo chocan con la evolución del esquema.
Ninguna de estas correcciones es compleja por separado. El coste viene del número.
El entorno de pruebas
No negociable, y sin embargo se salta con regularidad.
Debe apoyarse en una copia reciente de la base de producción, no en un juego de demostración. La mayoría de las incompatibilidades aparecen sobre datos reales: productos con cien combinaciones, clientes con direcciones incompletas, pedidos en estados olvidados.
Dos precauciones: anonimiza los datos de clientes antes de copiar, y desactiva todo envío de correo desde ese entorno. Una prueba de migración que envía dos mil correos de cambio de estado a clientes reales es una historia verdadera y frecuente.
El plan de pruebas
Prueba recorridos, no páginas. Seis recorridos cubren lo esencial.
Un pedido completo como visitante no registrado, con pago real en entorno de pruebas. Un pedido con una cuenta existente y una dirección guardada. Una adición al carrito desde una página de categoría con filtros activos. Una búsqueda interna seguida de una compra. Una devolución o una solicitud de postventa. Y del lado de la administración, la creación de un producto con combinaciones y la validación de un pedido.
Cada recorrido debe jugarse en escritorio y en móvil. Cuenta una jornada para el conjunto, a repetir tras cada corrección significativa.
El cambio y el después
Prevé la migración fuera de los periodos comerciales, con una ventana de vuelta atrás definida y probada. Una copia de seguridad que nunca se ha restaurado no cuenta.
Los días siguientes, se imponen tres controles. Los registros de error del servidor, que revelan las incompatibilidades que las pruebas no encontraron. Los enlaces e imágenes rotos, porque un cambio de versión puede afectar a las rutas de imágenes y a las URL reescritas. Y el seguimiento de los pedidos, a comparar con el nivel habitual: una caída brusca señala un bloqueo en el proceso de compra que nadie ha reportado.
Sobre este último punto, el Verificador de Enlaces Rotos para PrestaShop resulta útil tanto en fase de pruebas como después del cambio: detecta los enlaces internos rotos y las imágenes ausentes que la migración ha podido producir, tanto en PrestaShop 8 como en PrestaShop 9.