Mantenimiento de módulos en PrestaShop 9: overrides, hooks y compatibilidad

El reto real: mantener módulos en producción sobre PrestaShop 9

La migración a PrestaShop 9 no termina con la actualización del core. El verdadero desafío comienza cuando los módulos que mantienen tu tienda operativa —pasarelas de pago, integraciones logísticas, módulos de marketing, funcionalidades custom— necesitan adaptarse a una arquitectura que ha cambiado de raíz.

PrestaShop 9 ha reconstruido su back office sobre Symfony 6.4 y Twig, ha introducido una nueva Admin API basada en API Platform, y ha modificado el sistema de hooks y eventos. Estos cambios, aunque positivos para el futuro de la plataforma, generan un trabajo significativo de adaptación en los módulos existentes. En este artículo abordamos los problemas más comunes y las estrategias para resolverlos.

En qué punto está PrestaShop 9 a finales de 2026

Cuando publicamos la primera versión de este artículo, PrestaShop 9 era todavía una rama joven y la mayoría de tiendas seguían en 1.7 o en 8.x. El panorama ha cambiado: PrestaShop 9.1 se publicó el 23 de marzo de 2026 y con ella Hummingbird 2.0 pasó a ser el tema por defecto del front office, con más de un 95 % de cumplimiento de los requisitos de accesibilidad de la EAA. La rama 9.1 ha ido recibiendo parches hasta la 9.1.5, publicada el 25 de agosto de 2026, que es la última versión planificada de esa serie antes de PrestaShop 9.2 —disponible hoy solo en beta y, por tanto, fuera de producción—.

Para quien mantiene módulos, esto tiene tres consecuencias muy concretas:

• El rango de PHP se ha ampliado. PrestaShop 9 exige PHP 8.1 como mínimo y en la rama 9.1 el soporte llega hasta PHP 8.5. Un módulo que declare un techo de PHP 8.1 o 8.2 dará problemas en instalaciones nuevas.
• Symfony 6.4 es LTS hasta noviembre de 2027. Es una buena noticia: la base sobre la que reescribes tus overrides no se va a mover en un par de años.
• Solo la rama menor más reciente recibe parches. La política de mantenimiento de PrestaShop es agresiva: cuando sale una versión menor nueva, la anterior deja de recibir correcciones, incluidas las de seguridad. Quedarse en 9.0 no es ir con calma, es quedarse sin parches.

Si todavía estás valorando el salto, tienes el detalle de la versión en nuestro repaso de novedades de PrestaShop 9 y el procedimiento completo en la guía de migración de PrestaShop 1.7 a 9. Si vienes de 8.x, en qué cambió en PrestaShop 8 para los desarrolladores está el contexto de por dónde empezó esta reconstrucción.

Overrides: el punto crítico de la migración

Por qué los overrides ya no funcionan igual

En versiones anteriores de PrestaShop, los overrides eran la forma habitual de modificar el comportamiento del core sin tocar directamente los archivos originales. Se podían sobrescribir clases, controladores y plantillas simplemente colocando un archivo con el mismo nombre en la carpeta override.

Con PrestaShop 9, gran parte del back office ha sido migrado a controladores Symfony. Esto significa que los overrides de controladores legacy simplemente no se ejecutan porque esos controladores ya no existen. El código sigue ahí pero es ignorado por el sistema.

Esto no es un bug, es una consecuencia directa de la modernización de la plataforma. La solución pasa por reescribir esos overrides como módulos que utilicen el sistema de servicios y eventos de Symfony.

Cómo identificar overrides problemáticos

El primer paso es auditar la carpeta override de tu instalación. Para cada archivo encontrado, necesitas determinar si el controlador o clase que sobrescribe sigue existiendo en PrestaShop 9 o ha sido reemplazado por un componente Symfony. Si ha sido reemplazado, el override necesita ser transformado.

PrestaShop 9 incluye herramientas de diagnóstico que alertan sobre overrides potencialmente incompatibles, pero nuestra experiencia nos dice que una revisión manual por parte de un desarrollador experimentado es imprescindible para detectar problemas sutiles que las herramientas automáticas no captan.

Hooks: qué ha cambiado y qué sigue igual

Hooks deprecados y nuevos hooks

El sistema de hooks sigue siendo el mecanismo principal de extensión de PrestaShop, pero la migración a Symfony ha traído cambios importantes. Algunos hooks asociados a controladores legacy han sido deprecados o eliminados, mientras que se han introducido nuevos hooks vinculados a los controladores Symfony.

Los hooks del front office generalmente se mantienen estables, ya que el sistema de renderizado de plantillas no ha sufrido cambios tan drásticos. Sin embargo, los hooks del back office son los que más cambios han experimentado.

Para cada módulo, es necesario verificar la lista de hooks que utiliza y comprobar su estado en PrestaShop 9. La documentación oficial incluye una tabla de equivalencias entre hooks legacy y los nuevos hooks Symfony.

Eventos Symfony como alternativa

Además de los hooks tradicionales, PrestaShop 9 permite utilizar el sistema de eventos de Symfony para interceptar acciones del sistema. Esto abre posibilidades que antes requerían overrides: puedes escuchar eventos de creación, modificación o eliminación de cualquier entidad del sistema y ejecutar lógica personalizada en respuesta.

Para módulos nuevos, recomendamos utilizar eventos Symfony siempre que sea posible, reservando los hooks clásicos para compatibilidad con el front office.

Estrategias de mantenimiento para módulos en producción

Versionado y testing

Todo módulo en producción debería tener un sistema de control de versiones (Git) y un conjunto de pruebas automatizadas. Antes de actualizar PrestaShop, ejecuta las pruebas del módulo contra la nueva versión en un entorno de staging. Los fallos que detectes aquí son problemas que no llegarán a producción.

Compatibilidad dual: mantener soporte para 1.7 y 9

Si mantienes módulos que necesitan funcionar tanto en PrestaShop 1.7 como en 9 (por ejemplo, durante un período de transición), la estrategia más efectiva es utilizar detección de versión para cargar el código apropiado. PrestaShop proporciona constantes que permiten verificar la versión del core en tiempo de ejecución.

Monitorización continua

Los módulos en producción necesitan monitorización activa. Un módulo que funciona correctamente hoy puede fallar mañana después de una actualización menor de PrestaShop, un cambio en la configuración del servidor o una interacción inesperada con otro módulo.

Implementamos sistemas de logging específicos para módulos críticos que registran errores, tiempos de ejecución y anomalías, permitiendo detectar problemas antes de que afecten a la operativa de la tienda.

Módulos de terceros: qué hacer cuando no se actualizan

Uno de los escenarios más frustrantes es depender de un módulo de terceros cuyo desarrollador no ha actualizado para PrestaShop 9. En estos casos, las opciones son buscar una alternativa compatible, contactar al desarrollador para solicitar la actualización (aportando información técnica sobre los problemas), o adaptar el módulo internamente si la licencia lo permite.

En Keliam hemos tenido que adaptar módulos de terceros para clientes que no podían esperar a que el desarrollador original publicara una actualización. Es un trabajo delicado que requiere conocimiento profundo tanto del módulo como de la nueva arquitectura de PrestaShop 9.

Desarrollo de módulos nuevos: buenas prácticas para PrestaShop 9

Si estás desarrollando un módulo nuevo para PrestaShop 9, estas son las prácticas que recomendamos: utilizar servicios Symfony en lugar de overrides, implementar la interfaz de comandos CQRS para operaciones complejas, registrar endpoints en la Admin API si el módulo necesita ser accesible externamente, escribir pruebas PHPUnit para la lógica de negocio, y seguir las convenciones de nomenclatura de PrestaShop para hooks y configuraciones.

Dependencias que PrestaShop 9 ha dejado de incluir

Un fallo que aparece una y otra vez en las auditorías no tiene que ver con hooks ni con overrides, sino con librerías que antes venían incluidas en el core y ahora no. PrestaShop 9 ha soltado lastre de dependencias, y cualquier módulo que las usara sin declararlas deja de funcionar con un class not found en cuanto se instala.

Las dos que rompen más módulos son:

• guzzlehttp/guzzle, sustituida internamente por el cliente HTTP de Symfony. Cualquier módulo que llame a una API externa con Guzzle tiene que empaquetarla en su propio composer.json o migrar a HttpClientInterface.
• swiftmailer/swiftmailer, sustituida por Symfony Mailer. Afecta a módulos de notificaciones, de facturación y a cualquier integración que enviara correo por su cuenta. De paso, en la configuración de correo ha desaparecido la opción de cifrado SSL: solo quedan TLS o sin cifrado.

La lista no acaba ahí: también han salido del core league/tactician-bundle, pear/archive_tar, sensio/framework-extra-bundle, soundasleep/html2text y varios componentes de Symfony (inflector, notifier, rate-limiter, semaphore, uid y workflow). Ninguna es exótica: son exactamente las que un módulo de tamaño medio acaba usando.

Detectarlo sin esperar al error en producción es sencillo: revisa los use de cada módulo y comprueba, uno a uno, que cada namespace externo está declarado como dependencia propia. Es el tipo de revisión que hacemos de serie en una auditoría de código, porque el coste de encontrarlo tarde es desproporcionado respecto al de buscarlo antes.

Ojo también con Node: PrestaShop 9 exige Node 20 como mínimo para compilar assets. Si tu pipeline de build sigue anclado a Node 16, el módulo compilará en local y fallará en el servidor de integración.

Controladores como servicios: el cambio que más módulos rompe

Si hay un cambio de PrestaShop 9 que conviene entender bien antes de tocar nada, es este: los controladores del back office se declaran ahora como servicios de Symfony. La consecuencia inmediata es que $this->get('nombre_del_servicio') ha dejado de funcionar dentro de los controladores modernos. Las dependencias se inyectan por el constructor o como parámetros del método, y punto.

En paralelo, la clase base FrameworkBundleAdminController está deprecada y desaparecerá en PrestaShop 10. Su reemplazo es PrestaShopAdminController. Que la vieja siga funcionando hoy no es una invitación a dejarlo para más adelante: es exactamente la clase de deuda técnica que convierte la siguiente actualización mayor en un proyecto de semanas.

Métodos del ciclo de vida que ya no se llaman

El layout del back office se ha reconstruido con componentes Twig, y eso deja fuera de juego una serie de métodos que muchos módulos sobrescribían: AdminController::run(), initHeader(), initContent(), initFooter() y display() ya no se invocan en las pantallas migradas. Un override sobre cualquiera de ellos no da error: simplemente no se ejecuta. Es el peor de los escenarios, porque el módulo parece instalado y correcto.

En las plantillas han desaparecido además las variables Smarty viewport_scale e inline_js. Si tu módulo inyectaba JavaScript aprovechando inline_js, esa parte hay que reescribirla con los hooks de setMedia.

Sesiones del back office en el servidor

El login y la autorización del back office han pasado de apoyarse en Context::$cookie a usar sesiones gestionadas en servidor, con muy pocos datos del lado del navegador. Es una mejora de seguridad clara —va en la línea de los controles técnicos que pide una certificación como la ISO 27001—, pero rompe cualquier módulo que leyera o escribiera datos de sesión directamente en la cookie del contexto.

Firmas de métodos más estrictas

Por último, PrestaShop 9 ha endurecido los type hints de controladores y servicios. Un override que redefina un método con una firma ligeramente distinta ya no pasa desapercibido: produce un error fatal de PHP en el arranque. Es molesto, pero es un fallo ruidoso, y esos son los buenos.

Checklist de compatibilidad módulo a módulo

Cuando entramos a mantener una tienda con veinte o treinta módulos instalados no revisamos el sitio en bloque: revisamos cada módulo contra la misma lista. Es lo único que evita que algo se cuele.

1. Rango de PHP. ¿El módulo declara compatibilidad de 8.1 a 8.5? ¿Usa alguna función retirada en 8.2 o 8.3?
2. Dependencias propias. ¿Están en su composer.json todas las librerías que el core ya no trae?
3. Overrides. ¿Cuántos hay, sobre qué clases, y siguen existiendo esas clases en la versión 9.x instalada?
4. Hooks. ¿Los hooks registrados siguen disparándose? Un hook que ya no existe se registra sin error y nunca se ejecuta.
5. Plantillas. ¿Quedan referencias a variables Smarty retiradas o a plantillas del back office migradas a Twig?
6. Admin API. Si el módulo expone datos al exterior, ¿está registrado en el kernel de la Admin API con su configuración de caché propia? En la guía de la Admin API de PrestaShop 9 desarrollamos este punto.

Esos seis puntos son, con diferencia, los que más incidencias generan. El resto —traducciones, permisos, assets— suele resolverse solo.

Cinco errores frecuentes al adaptar módulos a PrestaShop 9

1. Actualizar el core y los módulos a la vez

Es tentador aprovechar la ventana de mantenimiento para hacerlo todo de golpe. El problema es que, cuando algo falla, no sabes si lo ha roto el core o un módulo. Actualiza primero el core en staging con los módulos en su versión actual, anota qué se rompe, y solo entonces toca los módulos.

2. Dar por buena la detección automática de incompatibilidades

El Update Assistant, a partir de la versión 7.6.0, incorpora detección de módulos incompatibles y ayuda bastante. Pero solo detecta lo que puede detectar de forma estática: los overrides que no dan error y simplemente dejan de ejecutarse no aparecen en ningún informe.

3. Probar en un staging que no se parece a producción

Misma versión menor de PrestaShop, misma versión de PHP, mismo conjunto de módulos y un volumen de datos realista. Un staging con tres productos y PHP 8.1 no dice absolutamente nada sobre una tienda con 40.000 referencias corriendo en PHP 8.3.

4. Migrar los overrides tal cual

Un override suele ser un parche acumulado a lo largo de años. Pasarlo a un servicio línea por línea perpetúa lógica que en muchos casos ya no hace falta. El momento de la migración es la mejor —y a veces la única— oportunidad de revisar qué hace realmente ese código.

5. Olvidarse del rendimiento

Los suscriptores de eventos de Symfony son cómodos, y por eso es fácil acabar enganchando lógica pesada a eventos que se disparan en cada petición. Después de migrar, mide: en una tienda en producción, un listener mal colocado se nota. Tienes el detalle en la guía de optimización de rendimiento en PrestaShop y en nuestro repaso de métricas y herramientas de auditoría de rendimiento.

Preguntas frecuentes

¿Los overrides han desaparecido de PrestaShop 9?

No. El mecanismo de overrides sigue existiendo y funciona sobre las clases legacy que se mantienen. Lo que ocurre es que buena parte del back office ya no pasa por esas clases, así que un override sobre un controlador migrado a Symfony se carga pero nunca llega a ejecutarse.

¿Puedo quedarme en PrestaShop 9.0 y actualizar más adelante?

Técnicamente sí, pero solo la rama menor más reciente recibe parches de bug y de seguridad. Quedarse en 9.0 con la 9.1 publicada significa quedarse sin correcciones de seguridad, que es justo lo contrario de lo que busca quien aplaza una actualización.

¿Cómo sé si un módulo de terceros es compatible antes de comprarlo?

Mira tres cosas: la versión máxima de PrestaShop declarada en el config.xml del módulo, la fecha del último cambio publicado y si el desarrollador documenta el rango de PHP soportado. Si el módulo no menciona la 9.1, asume que no se ha probado en 9.1.

¿Merece la pena esperar a PrestaShop 9.2?

Para una tienda en producción, no. En el momento de escribir esto la 9.2 está en beta y la propia PrestaShop desaconseja usarla en producción. Lo razonable es estar en la última 9.1.x y planificar el salto a 9.2 cuando tenga versión estable y los módulos críticos la declaren.

¿Cuánto trabajo es adaptar un módulo a medida?

Depende casi por completo de cuántos overrides tenga y de si tocan el back office. Un módulo que solo use hooks del front office suele adaptarse en horas; uno que sobrescriba controladores de administración puede ser una reescritura. Por eso el inventario de la primera fase no es burocracia: es lo que permite presupuestar.

Cómo puede ayudarte Keliam

El mantenimiento de módulos en PrestaShop es una de nuestras especialidades. Trabajamos con tiendas en producción que requieren estabilidad, rendimiento y evolución continua. Si necesitas adaptar módulos a PrestaShop 9, desarrollar módulos a medida o establecer un servicio de mantenimiento recurrente, contacta con nuestro equipo.