Cómo comprobar si un módulo es compatible con PrestaShop 9
Que un módulo se instale o no genere un error inmediato no significa necesariamente que sea completamente compatible con PrestaShop 9. La compatibilidad debe comprobarse frente a la versión de destino, el código utilizado y las funciones reales de la tienda.
Qué significa realmente que un módulo sea compatible con PrestaShop 9
La compatibilidad de un módulo debe evaluarse en varios niveles.
Un módulo puede declarar compatibilidad con PrestaShop 9, instalarse correctamente y no producir errores visibles, pero fallar únicamente cuando se ejecuta una función concreta.
Por ejemplo, un módulo de transporte puede cargar correctamente en el Back Office y fallar al calcular un envío. Un importador puede funcionar aparentemente bien hasta que se ejecuta mediante cron.
Una comprobación completa debería combinar compatibilidad declarada, revisión técnica, comprobaciones automáticas y pruebas funcionales.
Esta guía forma parte de nuestra guía técnica sobre PrestaShop 9.
Comprobar la versión declarada por el módulo
ps_versions_compliancy
Los módulos pueden indicar las versiones mínimas y máximas de PrestaShop
para las que han sido desarrollados mediante la propiedad
ps_versions_compliancy.
Esta declaración es útil como primera señal, pero no sustituye una prueba real.
Versión actual del módulo
No basta con comprobar el nombre del módulo. También debe conocerse la versión exacta instalada.
Un mismo módulo puede disponer de versiones antiguas para PrestaShop 1.7 u 8 y versiones posteriores específicamente adaptadas a PrestaShop 9.
Compatibilidad declarada por el desarrollador
Cuando procede de un proveedor externo debe revisarse su documentación actual y comprobar que la compatibilidad se refiere realmente a la versión de destino.
Una declaración comercial tampoco garantiza que todas las configuraciones particulares de la tienda funcionen sin cambios.
Qué comprueba Update Assistant
Update Assistant realiza comprobaciones sobre los módulos instalados antes de actualizar una tienda y analiza su situación respecto a la versión de destino.
Módulos compatibles
Cuando existe información suficiente puede determinar que el módulo dispone de una versión adecuada para la versión objetivo.
Después siguen siendo necesarias las pruebas funcionales.
Módulos incompatibles
Un módulo identificado como incompatible debe estudiarse antes de continuar.
Hay que determinar si puede actualizarse, adaptarse, sustituirse o eliminarse y comprobar si almacena datos que deban conservarse.
Compatibilidad incierta
En módulos propios, privados o poco documentados puede no existir información automática suficiente para determinar su compatibilidad.
Compatibilidad desconocida no significa necesariamente incompatibilidad: significa que el módulo necesita una revisión manual.
Un módulo desactivado también puede ser un problema
No conviene asumir que basta con desactivar un módulo incompatible antes de actualizar.
Determinadas partes modernas de PrestaShop pueden llegar a cargar clases o servicios asociados a módulos aunque estos no estén activos de la misma forma que en páginas legacy.
Por eso: desactivado no significa necesariamente inocuo durante una actualización.
La compatibilidad debe resolverse antes de modificar producción.
Revisar el código del módulo
PHP
El código debe ser compatible con la versión de PHP utilizada por la versión concreta de PrestaShop 9.
Conviene revisar funciones eliminadas, tipos, propiedades, librerías antiguas y dependencias externas.
Clases y métodos del core
Un módulo puede depender directamente de métodos o clases del core. Si utiliza código que fue deprecado y posteriormente eliminado, puede dejar de funcionar aunque el resto del módulo sea correcto.
Tipado y prototipos
Cambios en firmas de métodos y tipos pueden afectar especialmente a módulos y overrides desarrollados hace varios años.
Dependencias eliminadas
Si un módulo depende directamente de una librería que anteriormente formaba parte del core, debe comprobarse si sigue disponible o si el propio módulo tiene que incorporar una alternativa.
Hooks y PrestaShop 9
Los hooks continúan siendo una pieza fundamental del sistema de extensiones de PrestaShop, pero su compatibilidad debe comprobarse según el módulo real.
Hooks existentes
Si el módulo utiliza hooks que siguen disponibles y sus parámetros continúan siendo compatibles, esa parte del desarrollo puede seguir funcionando sin cambios.
Hooks eliminados
Los módulos que dependan de hooks obsoletos o retirados necesitan buscar una alternativa o modificar su implementación.
Páginas modernas y Symfony
PrestaShop dispone de mecanismos para integrar hooks tradicionales dentro de áreas modernizadas basadas en Symfony.
Esto facilita conservar compatibilidad con desarrollos existentes, pero no convierte todos los hooks históricos en permanentes.
Symfony y módulos PrestaShop 9
Un módulo compatible con PrestaShop 9 no necesita estar completamente reescrito en Symfony.
PrestaShop mantiene una arquitectura híbrida donde pueden convivir componentes legacy con servicios y controladores modernos.
Servicios
Los módulos pueden definir servicios propios para separar lógica y reducir dependencias innecesarias.
Controllers
Los módulos que amplían áreas modernas del Back Office deben comprobar controladores, rutas y mecanismos de extensión utilizados.
Dependency Injection
La inyección de dependencias permite desarrollar componentes más mantenibles y facilita su evolución.
Código legacy y moderno
Un módulo legacy bien desarrollado puede seguir funcionando correctamente.
El problema aparece cuando depende de componentes eliminados, métodos internos o comportamientos que han cambiado.
No tiene sentido reescribir automáticamente código funcional únicamente porque PrestaShop utilice progresivamente más componentes Symfony.
Overrides y modificaciones del core
Un módulo puede registrar correctamente sus hooks y al mismo tiempo instalar un override incompatible con PrestaShop 9.
Conviene localizar:
- overrides de clases;
- overrides de controladores;
- modificaciones de plantillas;
- cambios directos del core;
- parches históricos.
También debe comprobarse si el problema que resolvía originalmente ese override sigue existiendo.
Un override puede ser técnicamente migrable y, al mismo tiempo, completamente innecesario en la nueva versión.
Módulos que afectan a áreas críticas
No todos los módulos tienen el mismo nivel de riesgo.
Checkout y pagos
Deben realizarse pedidos comprobando importe, moneda, retorno de pasarela, estados, emails y confirmación.
Transporte
Hay que verificar zonas, rangos, restricciones, cálculo de portes y funcionamiento dentro del checkout.
Pedidos
Los módulos que modifican pedidos deben comprobarse tanto en front office como en Back Office.
Stock
Las integraciones de stock requieren pruebas específicas porque un error puede no ser visible navegando por la tienda.
ERP e integraciones
Deben probarse de extremo a extremo procesos de pedidos, clientes, stock, precios, facturación y sincronización.
Importadores y tareas cron
No basta con comprobar que el módulo aparece correctamente en Module Manager.
Hay que ejecutar realmente importadores, exportadores, cron, comandos CLI, APIs y procesos programados.
Cómo probar un módulo antes de actualizar producción
Staging
La prueba debe realizarse sobre un entorno que reproduzca suficientemente versión, base de datos, módulos, tema, PHP y configuraciones relevantes.
Instalación y configuración
Comprobar que el módulo carga, actualiza su versión correctamente, conserva configuración y no genera errores en Back Office.
Pruebas funcionales
La funcionalidad debe ejecutarse realmente.
Un importador se prueba importando; un módulo de pago realizando un pago; un transportista calculando un envío; una integración ejecutando la sincronización.
Logs y modo debug
Durante las pruebas conviene revisar errores PHP, logs de PrestaShop, excepciones, JavaScript y deprecaciones relevantes.
Desinstalación y rollback
En módulos críticos también interesa saber qué ocurre si hay que retirarlos: datos eliminados, configuraciones, tablas y overrides.
Qué hacer con un módulo incompatible
Actualizarlo
La primera opción es comprobar si el desarrollador publica una versión compatible.
Adaptarlo
Si el código sigue siendo mantenible y la funcionalidad es necesaria, puede adaptarse a PrestaShop 9.
Sustituirlo
Cuando existe una alternativa mantenida puede resultar más eficiente migrar el proceso hacia otro módulo.
Desarrollar un módulo propio
Si la funcionalidad es específica del negocio puede tener sentido encapsularla mediante un desarrollo propio.
En JUSARA LAB trabajamos este tipo de necesidades mediante módulos PrestaShop a medida .
Eliminarlo si ya no es necesario
Una actualización mayor es también una oportunidad para retirar módulos que llevan años instalados sin aportar valor real.
Compatibilidad entre versiones de PrestaShop 9
La expresión “compatible con PrestaShop 9” no debería interpretarse como una garantía ilimitada para todas las versiones futuras de la rama.
La compatibilidad debe comprobarse frente a la versión concreta de destino, especialmente cuando el módulo interactúa estrechamente con Back Office, checkout, pedidos, base de datos, Symfony o APIs.
Por eso, antes de una actualización conviene trabajar siempre con la versión exacta que se utilizará en producción.
Módulos propios y PrestaShop 9
Los módulos propios tienen la ventaja de que disponemos del código y podemos decidir cómo evolucionarlo.
Antes de actualizar conviene revisar:
- compatibilidad PHP;
- ps_versions_compliancy;
- hooks;
- overrides;
- controladores;
- servicios;
- consultas SQL;
- dependencias;
- Smarty o Twig;
- JavaScript;
- cron y CLI;
- integraciones externas.
Después debe probarse la funcionalidad completa en staging.
En nuestros proyectos los desarrollos propios se plantean como componentes independientes del core para facilitar mantenimiento, actualizaciones y evolución futura.
Auditoría de módulos antes de actualizar
En una tienda con muchos módulos resulta útil crear una matriz de compatibilidad.
Para cada módulo puede registrarse:
- nombre y versión instalada;
- función;
- criticidad;
- versión compatible disponible;
- compatibilidad conocida o incierta;
- adaptación necesaria;
- datos almacenados;
- decisión final.
El resultado permite separar módulos que pueden mantenerse, módulos que deben actualizarse, desarrollos que necesitan adaptación y componentes que conviene retirar.
Cuando existen numerosos módulos propios, overrides o integraciones, una auditoría técnica de PrestaShop permite determinar el alcance antes de modificar producción.
Módulos dentro de una actualización o migración a PrestaShop 9
La compatibilidad de módulos debe estudiarse dentro del proceso completo de evolución de la tienda.
Si el proyecto ya está sobre PrestaShop 8 puedes consultar: cómo actualizar PrestaShop 8 a PrestaShop 9 .
Si parte de una instalación antigua: cómo migrar PrestaShop 1.7 a PrestaShop 9 .
¿Necesitas adaptar un módulo a PrestaShop 9?
Antes de sustituir o reescribir un desarrollo conviene revisar qué hace, qué datos utiliza y qué parte del código necesita realmente adaptación.