Compatibilidad con PrestaShop 9: Todos nuestros módulos están listos

PrestaShop 9 ya está aquí. ¿Tu pila de módulos está preparada?

PrestaShop 9 llegó con la revisión arquitectónica más significativa desde que la plataforma adoptó Symfony por primera vez en la versión 1.7. He estado preparando nuestros módulos para este lanzamiento desde las primeras builds alfa, y en ese proceso aprendí exactamente qué se rompe, qué se degrada silenciosamente y qué deben comprobar los propietarios de tiendas antes de siquiera pensar en hacer clic en “Actualizar”.

Esto no es un resumen de changelog. Esta es la guía práctica que me habría gustado tener cuando abrí por primera vez una beta de PrestaShop 9 y vi cómo la mitad de los módulos de terceros de mi tienda de prueba lanzaban errores 500. Ya seas propietario de una tienda evaluando tu pila de módulos, un desarrollador freelance preparando la migración de un cliente, o una agencia gestionando docenas de instalaciones de PrestaShop, esta guía te acompaña a través del proceso completo de auditoría de compatibilidad.

Qué cambió realmente en PrestaShop 9 (y por qué rompe cosas)

Antes de poder auditar tus módulos, necesitas entender qué cambió PrestaShop 9 a nivel arquitectónico. Estos no son cambios cosméticos. Son cambios fundamentales que afectan a cada módulo que interactúa con el back office, la capa de base de datos o el tema del front-end.

Symfony 6.4: El cambio grande

PrestaShop saltó de Symfony 4.4 a Symfony 6.4. Eso no es una actualización incremental. Es un salto a través de dos versiones mayores de Symfony, cada una de las cuales introdujo su propio conjunto de deprecaciones y eliminaciones. Para los desarrolladores de módulos, la consecuencia más crítica es cómo funcionan los controladores.

En Symfony 4.4, podías usar $this->get('service_name') dentro de los controladores para obtener cualquier servicio del contenedor. En Symfony 6.4, los controladores deben definirse como servicios con inyección de dependencias adecuada. El antiguo FrameworkBundleAdminController todavía funciona en PrestaShop 9, pero está oficialmente deprecado y se eliminará en PrestaShop 10. Cualquier módulo que extienda esta clase está viviendo de tiempo prestado.

Lo que esto significa para ti: si las páginas de administración de un módulo funcionan hoy en PrestaShop 9 pero usan el patrón de controlador legacy, podrían dejar de funcionar completamente en PrestaShop 10. Lo que quieres son módulos que ya hayan migrado a PrestaShopAdminController con inyección por constructor.

Bibliotecas eliminadas de las que probablemente dependes

PrestaShop 9 eliminó varias bibliotecas de su core que los módulos usaban previamente de forma gratuita:

• Guzzle HTTP client fue reemplazado por el cliente HTTP de Symfony. Cualquier módulo que haga llamadas a APIs externas a través de Guzzle lanzará un error fatal de “class not found” a menos que incluya su propia copia.
• SwiftMailer fue reemplazado por Symfony Mailer. Los módulos que envían emails directamente (notificaciones de pedidos, alertas, informes) necesitan usar la nueva interfaz del mailer.
• Tactician command bus fue reemplazado por Symfony Messenger. Los módulos que usan patrones CQRS con Tactician necesitan una reescritura completa de su manejo de comandos/consultas.

La parte engañosa: estos fallos no siempre aparecen inmediatamente. Un módulo puede instalarse y mostrar su página de configuración perfectamente, pero fallar en el momento en que intenta enviar una petición HTTP o despachar un comando. No detectarás esto en una prueba rápida de “¿se instala?”.

Se eliminaron 33 hooks

PrestaShop 9 eliminó 33 hooks. No es una errata. Treinta y tres puntos de integración de los que los módulos dependían anteriormente simplemente ya no existen. Las eliminaciones se dividen en tres categorías:

• Hooks del legacy de la página de producto (toda la antigua interfaz de edición de productos se eliminó, llevándose todos sus hooks): actionAdminProductsControllerXxx, actionAdminActivateAfter/Before, actionAdminDeactivateAfter/Before, actionAdminDeleteAfter/Before, y actionAdminSortAfter/Before
• Hooks del controlador de login (ahora gestionados por la seguridad de Symfony): actionAdminLoginControllerBefore, actionAdminLoginControllerLoginBefore/After, actionAdminLoginControllerForgotBefore/After, y actionAdminLoginControllerResetBefore/After
• Hooks de layout vinculados al ciclo de vida del antiguo AdminController (initHeader, initContent, initFooter, display) están efectivamente muertos porque PrestaShop 9 gestiona el layout a través de componentes Twig

Si un módulo registra cualquiera de estos hooks, no se caerá, pero el hook simplemente nunca se ejecuta. El módulo pierde funcionalidad silenciosamente. Esto es posiblemente peor que un crash porque podrías no notar durante semanas que una funcionalidad dejó de funcionar.

PHP 8.1 mínimo, PHP 8.4 recomendado

PrestaShop 9 requiere PHP 8.1 como mínimo. Esto elimina las tiendas que todavía ejecutan PHP 7.4 u 8.0. Más importante aún, significa que los módulos deben manejar las características de PHP 8.1+ y una verificación de tipos más estricta. Las funciones que anteriormente devolvían tipos mixtos ahora necesitan declaraciones explícitas de tipo de retorno. Los parámetros nullable necesitan el prefijo ? o union types. Los días de la tipificación flexible de PHP han terminado.

Pruebo todos nuestros módulos contra PHP 8.1, 8.2, 8.3 y 8.4 específicamente porque cada versión menor de PHP introduce nuevos avisos de deprecación que pueden llenar tus registros y, en entornos con reporte de errores estricto, causar advertencias visibles para los clientes.

Gestión avanzada de stock: eliminada

Todo el sistema de gestión avanzada de stock fue eliminado de PrestaShop 9. Esto incluye pedidos a proveedores, almacenes y la antigua interfaz de gestión de stock. Si alguno de tus módulos interactúa con datos de almacén, hooks de pedidos a proveedores o la API de gestión avanzada de stock, se romperán. Esta eliminación también afecta a las tablas de la base de datos, por lo que los módulos que consultan tablas relacionadas con el stock directamente obtendrán errores SQL.

Deprecación del singleton Context

El singleton Context que todo desarrollador de PrestaShop conoce y ama (o tolera) está siendo eliminado progresivamente. PrestaShop 9 introdujo servicios de contexto dedicados: EmployeeContext, ShopContext, CurrencyContext, CountryContext, LanguageContext y otros. Los módulos que usan Context::getContext() todavía funcionan, pero los módulos construidos con prácticas modernas deberían estar migrando a estos servicios dedicados.

La función de traducción ya no escapa HTML

Este es un cambio sutil pero peligroso. La función trans() en PrestaShop 9 ya no escapa automáticamente las entidades HTML. En versiones anteriores, pasar entrada de usuario a través de trans() proporcionaba una capa de protección contra XSS casi por accidente. En PrestaShop 9, los módulos deben usar explícitamente htmlspecialchars() en cualquier contenido dinámico pasado a las traducciones. Los módulos que no actualicen esto están potencialmente introduciendo vulnerabilidades de seguridad.

Tema Hummingbird y Bootstrap 5

PrestaShop 9 viene con el tema Hummingbird como predeterminado, construido sobre Bootstrap 5. PrestaShop 9.1 además actualizó a Bootstrap 5.3.3. Para cualquier módulo que renderice plantillas front-end, esto significa:

• Los nombres de clase de Bootstrap 4 ya no funcionan (por ejemplo, .no-gutters pasa a ser .g-0, .custom-checkbox pasa a ser .form-check)
• Los atributos data tienen namespace (data-toggle pasa a ser data-bs-toggle)
• jQuery está oficialmente deprecado en Hummingbird y se eliminará en la próxima versión mayor del tema. Los módulos que dependen de jQuery para funcionalidad front-end necesitan un plan de migración a JavaScript vanilla
• Los selectores CSS basados en clases específicas de PrestaShop están siendo reemplazados por atributos data-ps-*

Cómo auditar tus módulos instalados: un proceso paso a paso

Ahora que entiendes lo que cambió, aquí está el proceso sistemático que uso para evaluar la compatibilidad de los módulos. No necesitas ser desarrollador para seguir la mayoría de estos pasos.

Paso 1: Inventariar tus módulos

Ve a tu back office de PrestaShop, navega a Módulos > Gestor de módulos y exporta o haz una captura de pantalla de tu lista completa de módulos instalados. Para cada módulo, anota:

• Nombre del módulo y versión actual
• Nombre del proveedor/desarrollador
• Fecha de la última actualización
• Si es un módulo gratuito, un módulo de pago de PrestaShop Addons o un módulo de terceros

Categoriza cada módulo según lo crítico que es para tu negocio. Un módulo de pasarela de pago es crítico. Un widget de compartir en redes sociales es un complemento. Esta priorización determina tu cronograma de actualización.

Paso 2: Comprobar las declaraciones de compatibilidad del proveedor

Para cada proveedor de módulos, busca una declaración explícita de compatibilidad con PrestaShop 9. Esto es lo que debes buscar y cuáles son las señales de alerta:

Señales positivas:

• El proveedor tiene un artículo de blog o entrada de changelog que menciona específicamente la compatibilidad con PrestaShop 9.0 y 9.1
• La versión del módulo se actualizó después de la fecha de lanzamiento de PrestaShop 9
• El proveedor menciona pruebas contra Symfony 6.4 y PHP 8.1+
• Se mantiene la compatibilidad retroactiva con PrestaShop 8.x (muestra que entienden el soporte multi-versión)

Señales de alerta:

• No se menciona PrestaShop 9 en ningún lugar del sitio del proveedor
• La última actualización del módulo fue anterior a las versiones alfa de PrestaShop 9
• Los otros módulos del proveedor tampoco se han actualizado (sugiere una línea de productos abandonada)
• La descripción del módulo menciona “Compatible con PrestaShop 1.7” sin ninguna referencia a 8.x o 9.x

Paso 3: Inspeccionar el código del módulo en busca de patrones problemáticos conocidos

Si tienes conocimientos básicos de PHP, o los tiene tu desarrollador, abre los archivos del módulo y busca estos patrones específicos que están garantizados a causar problemas en PrestaShop 9:

Busca $this->get( en los controladores de administración — Este es el patrón legacy de acceso a servicios de Symfony 4.4. Funciona en PrestaShop 9 pero está deprecado. Los módulos que lo usan no se han modernizado.

Busca use GuzzleHttp — Si el módulo importa Guzzle pero no lo incluye en su propio directorio vendor, se romperá en PrestaShop 9 donde Guzzle fue eliminado del core.

Busca Swift_ o SwiftMailer — Misma situación. SwiftMailer fue eliminado del core.

Busca Tools::displayPrice — Este fue deprecado. Los módulos deberían usar el servicio Locale para el formateo de precios.

Busca data-toggle= en archivos .tpl — Atributos data de Bootstrap 4. Estos deberían ser data-bs-toggle= para compatibilidad con Hummingbird.

Busca $.ajax o $(document) en archivos .js — Uso de jQuery. Todavía funciona en el tema Classic pero se romperá en Hummingbird cuando se elimine jQuery.

Paso 4: Configurar un entorno de staging

Nunca pruebes la compatibilidad de módulos en tu tienda en producción. Aquí está la configuración mínima de staging:

1. Clona tu base de datos de producción a una base de datos separada (o usa la función de staging de tu proveedor de hosting)
2. Instala PrestaShop 9 limpio o usa el módulo de actualización en tu instalación clonada
3. Instala tus módulos uno a uno, comprobando el registro de errores después de cada instalación. El orden importa: instala primero los módulos de pago y envío, luego los de SEO y después los cosméticos
4. Prueba la funcionalidad principal de cada módulo, no solo “¿carga la página de configuración?”. Realiza un pedido de prueba. Ejecuta una importación de productos. Genera un sitemap. Lo que sea que el módulo realmente haga en producción

Consejo profesional: Revisa tu registro de errores PHP (/var/log/php_errors.log o el registro de errores de tu hosting) después de cada instalación de módulo. Muchos problemas de compatibilidad aparecen como avisos de deprecación o advertencias de PHP en lugar de crashes directos. La advertencia de hoy es el error fatal de mañana.

Paso 5: Probar el renderizado front-end en ambos temas

Si estás usando PrestaShop 9 con el nuevo tema Hummingbird, prueba cada módulo que produzca cualquier salida en el front end. Presta especial atención a:

• Modificaciones de la página de checkout (formularios de módulos de pago, selección de transportista, validación de dirección)
• Widgets de la página de producto (reseñas, listas de deseos, guías de tallas, campos personalizados)
• Hooks de cabecera y pie de página (mega menús, barras de búsqueda, vistas previas del carrito)
• Filtros y ordenación de la página de categoría

Si te quedas con el tema Classic, tu riesgo de compatibilidad front-end es menor, pero los cambios de Bootstrap 5 todavía pueden afectar a los módulos que inyectan su propio CSS.

Qué preguntar a tus proveedores de módulos

Cuando contactes a un proveedor de módulos sobre la compatibilidad con PrestaShop 9, no preguntes simplemente “¿es compatible?”. Esa pregunta te da una respuesta sí/no que podría ser incorrecta. En su lugar, haz estas preguntas específicas:

1. “¿Se ha probado el módulo en PrestaShop 9.0 Y 9.1?” — La versión 9.1 introdujo cambios adicionales que rompen cosas (Bootstrap 5.3.3, deprecación de jQuery, nuevos cambios de hooks). Probar solo en 9.0 no es suficiente.
2. “¿El módulo sigue soportando PrestaShop 8.x con el mismo archivo ZIP?” — Si el proveedor requiere una versión separada para PrestaShop 9, eso es una carga de mantenimiento para ti. Un módulo bien construido gestiona la detección de versión internamente.
3. “¿Han migrado de los patrones deprecados de Symfony 4.4?” — Si el proveedor no entiende esta pregunta, eso te dice algo sobre su profundidad técnica.
4. “¿El módulo usa jQuery en el front end?” — Si sí, pregunta sobre su cronograma de migración a JavaScript vanilla antes de que Hummingbird elimine el soporte de jQuery.
5. “¿Cuál es su rango de versiones PHP probadas?” — Quieres escuchar 8.1 a 8.4, no solo “PHP 8”.

El marco de decisión de actualización

Basándome en mi experiencia actualizando entornos de prueba y ayudando a propietarios de tiendas a evaluar su preparación, aquí tienes un marco práctico para decidir cuándo actualizar:

Actualiza ahora si:

• Todos tus módulos tienen compatibilidad confirmada con PrestaShop 9 por parte de sus proveedores
• Ya estás ejecutando PHP 8.1+
• Tienes un entorno de staging donde has probado la ruta completa de actualización
• Tu tema es Classic, Hummingbird o un tema hijo de cualquiera de los dos

Espera 3-6 meses si:

• Uno o dos módulos no críticos carecen de confirmación de compatibilidad
• Tu tema es un tema de terceros muy personalizado (los proveedores de temas a menudo se retrasan en el soporte de versiones mayores)
• Dependes de la gestión avanzada de stock (necesitas encontrar flujos de trabajo de reemplazo primero)

No actualices todavía si:

• Módulos críticos (pago, envío, integración ERP) no tienen declaración de compatibilidad con PrestaShop 9
• Estás ejecutando PHP 7.4 u 8.0 (necesitas una actualización de PHP primero, que es un proyecto en sí mismo)
• Tu proveedor de módulos ha estado en silencio durante más de un año (el módulo puede estar abandonado)

Cómo preparamos nuestros módulos (un caso de estudio real)

En mypresta.rocks, empecé a probar contra las builds alfa de PrestaShop 9 meses antes del lanzamiento estable. Así fue realmente el proceso, porque creo que es instructivo para entender qué significa realmente “compatible”.

Fase 1: Escaneo automatizado de compatibilidad

Ejecuté análisis estático en todos los módulos buscando los patrones que describí anteriormente: uso de controladores legacy, importaciones de bibliotecas eliminadas, llamadas a funciones deprecadas, clases de Bootstrap 4 en plantillas y uso de jQuery en archivos JavaScript. Esto produjo una lista priorizada de cambios necesarios.

Fase 2: Migración a Symfony 6.4

Se revisó cada controlador de administración en busca de patrones de acceso al contenedor de servicios. Donde los módulos usaban $this->get(), migramos a inyección por constructor. Donde los módulos extendían el controlador base deprecado, actualizamos la clase padre. Esta fue la fase más laboriosa porque toca la arquitectura central de cada módulo con interfaz de administración.

Fase 3: Auditoría de hooks

Cruzamos cada registro de hook en cada módulo contra la lista de 33 hooks eliminados. Donde los módulos usaban hooks eliminados, migramos a hooks de reemplazo o implementamos registro condicional de hooks basado en la versión que automáticamente usa el hook correcto para la versión detectada de PrestaShop.

Fase 4: Pruebas multi-versión

Cada módulo fue probado en PrestaShop 1.7.6, 1.7.7, 1.7.8, 8.0, 8.1, 9.0 y 9.1. En cada versión, probamos con PHP 8.1, 8.2, 8.3 y 8.4. Un único archivo ZIP de módulo funciona en todas estas combinaciones porque el módulo detecta la versión de PrestaShop en tiempo de ejecución y adapta su comportamiento en consecuencia.

Esto es lo que significa realmente “compatible hacia atrás” en la práctica. No son dos compilaciones separadas. Es un único código base que gestiona las diferencias de versión internamente.

Fase 5: Pruebas de tema front-end

Cada módulo con salida front-end fue probado en el tema Classic y en el tema Hummingbird. Se verificaron los nombres de clase de Bootstrap, los atributos data y el JavaScript en ambos. Donde se requirieron diferencias en las plantillas, usamos la detección de versión integrada de PrestaShop para cargar la plantilla apropiada.

El resultado: todos los módulos de mypresta.rocks son completamente compatibles con PrestaShop 9.0 y 9.1, manteniendo la compatibilidad retroactiva con PrestaShop 1.7.6+ y todas las versiones 8.x. Sin descargas separadas, sin pasos especiales de instalación, sin “edición PrestaShop 9” con precio diferente.

Problemas comunes después de la actualización y cómo solucionarlos

Incluso con módulos compatibles, podrías encontrar estos problemas después de actualizar a PrestaShop 9:

Pantalla blanca / Error 500 después de la instalación del módulo

Normalmente causado por una dependencia de Composer faltante. Comprueba tu registro de errores PHP en busca de errores “Class not found”. La solución es actualizar el módulo (si el proveedor tiene una nueva versión) o añadir manualmente la biblioteca faltante al directorio vendor del módulo.

Las páginas de administración cargan pero faltan funcionalidades

Este es el problema de la eliminación silenciosa de hooks. El módulo se instaló correctamente, pero sus hooks ya no se ejecutan en PrestaShop 9. Comprueba los registros de hooks del módulo contra la lista de hooks eliminados. Contacta al proveedor para una versión actualizada que use los hooks de reemplazo.

Estilo front-end roto en Hummingbird

Cambios de nombres de clase de Bootstrap 4 a 5. El módulo funciona en Classic pero se ve roto en Hummingbird. Esto requiere actualizaciones de plantilla por parte del proveedor del módulo. Como solución temporal, puedes cambiar al tema Classic mientras esperas a que el proveedor actualice.

Errores JavaScript en la consola del navegador

A menudo causados por la dependencia de jQuery en un entorno Hummingbird. Comprueba la consola de desarrollador del navegador (F12) en busca de errores “$ is not defined” o “jQuery is not defined”. La solución a largo plazo es JavaScript vanilla, pero a corto plazo puedes incluir jQuery manualmente en los assets de tu tema.

Las notificaciones por email dejaron de funcionar

Si un módulo envía emails a través de SwiftMailer directamente en lugar de la función de correo de PrestaShop, se romperá en PrestaShop 9 donde SwiftMailer fue reemplazado por Symfony Mailer. Contacta al proveedor para una actualización.

PrestaShop 9.1: Cambios adicionales a vigilar

PrestaShop 9.1 introdujo su propio conjunto de cambios sobre el 9.0. Si estás actualizando directamente al 9.1 (recomendado, ya que es la última versión estable), ten en cuenta estos factores adicionales de compatibilidad:

• Theme::getDefaultTheme() ya no devuelve la cadena codificada “classic”. Los módulos que asumían que el tema por defecto es Classic necesitan actualización.
• El hook displaySearch fue eliminado de Hummingbird porque causaba conflictos en las páginas 404. Los módulos que se enganchan a displaySearch para la personalización de la búsqueda front-end necesitan usar hooks alternativos.
• Las bibliotecas de gráficos D3 y NVD3 fueron actualizadas a versiones más recientes. Los widgets del dashboard que usan estas bibliotecas pueden renderizarse incorrectamente.
• Los selectores JavaScript migraron a la convención data-ps-*, reemplazando los selectores basados en clases. Los módulos que usan querySelector con nombres de clase específicos de PrestaShop pueden dejar de apuntar a los elementos correctos.

Tu lista de verificación previa a la actualización

Imprime esto, pégalo en tu pared y no actualices hasta que cada elemento esté marcado:

1. Inventariar todos los módulos instalados con nombres de proveedor y versiones actuales
2. Comprobar el sitio web de cada proveedor en busca de declaraciones de compatibilidad con PrestaShop 9
3. Actualizar todos los módulos a sus últimas versiones (incluso antes de actualizar PrestaShop)
4. Configurar un entorno de staging con una copia de tu base de datos de producción
5. Instalar PrestaShop 9.1 en staging
6. Instalar los módulos uno a uno, comprobando los registros de errores después de cada uno
7. Probar la funcionalidad principal de cada módulo (no solo “¿carga la página de configuración?”)
8. Probar el renderizado front-end en tu tema activo
9. Ejecutar un pedido de prueba completo a través del checkout
10. Comprobar los registros de errores PHP en busca de advertencias de deprecación
11. Verificar el envío de emails desde todos los módulos que envían notificaciones
12. Hacer copia de seguridad de todo: base de datos, archivos y configuración
13. Programar la actualización durante las horas de menor tráfico
14. Mantener tu copia de seguridad de PrestaShop 8.x disponible durante al menos 30 días después de la actualización

Reflexiones finales

PrestaShop 9 es una mejora significativa. Symfony 6.4 trae mejor rendimiento, prácticas PHP modernas y una arquitectura más mantenible. El tema Hummingbird es más rápido y más accesible que Classic. La nueva API de administración abre posibilidades que antes no estaban disponibles.

Pero nada de eso importa si tus módulos se rompen durante la actualización. Tómate el tiempo para auditar correctamente. Usa un entorno de staging. Exige a tus proveedores declaraciones de compatibilidad explícitas, no respuestas vagas de “debería funcionar”.

Si buscas módulos que han sido rigurosamente probados en PrestaShop 1.7.6 a 9.1, echa un vistazo al catálogo de módulos de mypresta.rocks. Cada módulo se entrega como un único ZIP que funciona en todas las versiones soportadas, y la compatibilidad con PrestaShop 9 está incluida con cada licencia, no se vende como una actualización separada.

¿Tienes preguntas sobre tu escenario específico de actualización? Contáctanos y te ayudaré a evaluar tu pila de módulos.