Overrides en PrestaShop: riesgos, hooks y cómo auditarlos

Los overrides en PrestaShop permiten sustituir métodos de las clases y los controladores del núcleo sin editar los archivos originales. Durante años fueron la forma rápida de cambiar cómo se calcula un precio, qué datos pide el registro o qué pasa al guardar un pedido, y muchas tiendas acumulan bastantes, unos instalados por módulos y otros añadidos a mano, que suelen dar problemas al actualizar. Repasamos cómo funcionan, por qué fallan al actualizar, qué alternativas hay con hooks y servicios y cómo auditar los que ya tiene tu tienda.

Qué es un override en PrestaShop

Las clases del núcleo de PrestaShop se llaman, por ejemplo, ProductCore o CartCore, y el resto del código usa Product o Cart. Si no hay override, Product es una extensión vacía de ProductCore. Si creas un archivo en la carpeta override/classes que define Product extendiendo ProductCore, PrestaShop usa tu versión, y los métodos que escribas sustituyen a los originales.

Lo mismo vale para los controladores de la tienda y del back office, para la clase principal de un módulo y para sus controladores. Un módulo puede traer sus propios overrides: al instalarlo, PrestaShop copia sus métodos a la carpeta override de la raíz, y al desinstalarlo los retira. Los que alguien puso a mano no tienen a nadie que los retire. PrestaShop guarda en caché el índice de clases, así que después de añadir o quitar un override hay que vaciar la caché para que se tenga en cuenta.

No hay que confundirlo con sobrescribir plantillas de módulos desde el tema, que es una práctica normal y se hace mejor en un tema hijo. Un override de PHP cambia la lógica del núcleo; una plantilla en el tema cambia lo que se ve.

Por qué los overrides rompen al actualizar PrestaShop

Un override sustituye un método entero. Lo habitual es copiar el método original, cambiar dos líneas y dejar el resto igual. A partir de ese momento la tienda ejecuta la copia, y cualquier corrección que PrestaShop haga en el método original, incluidas las de seguridad, no llega nunca a ejecutarse. Nada avisa: la versión corregida del método simplemente no se usa.

Otros fallos sí dan error, y suelen aparecer tras un cambio de versión:

• La firma del método cambia en el núcleo (parámetros nuevos, tipos declarados) y el override ya no es compatible. En PHP 8 esto produce un error fatal y la página no carga.
• El método o la clase desaparecen o cambian de sitio, y el override queda huérfano o rompe la carga de clases.
• Partes del back office han pasado a Symfony. Un override de un controlador antiguo de una página migrada deja de aplicarse sin avisar, porque la página ya usa otro código.

Además, los overrides son exclusivos. Si dos módulos quieren sobrescribir el mismo método, uno de los dos no podrá instalar su override o alguien acabará fusionándolos a mano. Por eso PrestaShop los desaconseja en módulos que se distribuyen y no los admite en los módulos de sus partners. En la guía para actualizar PrestaShop sin romper módulos explicamos dónde encaja su revisión dentro del plan de actualización.

Hooks: la alternativa a los overrides en PrestaShop

Los hooks son puntos del código donde PrestaShop avisa a los módulos de que algo ocurre o les pide contenido. Hay dos familias. Los de visualización, como los de la ficha de producto o el carrito, permiten añadir contenido en un sitio concreto. Los de acción se disparan antes o después de un evento, como guardar un objeto, validar un pedido o cambiar su estado, y permiten ejecutar lógica propia.

Muchos overrides se escribieron para cosas que hoy se resuelven con un hook. Imagina un override de la clase Customer que envía los datos de cada cliente nuevo a un CRM: lo mismo se consigue con un módulo enganchado al hook que se dispara después de crear el cliente, sin tocar la clase. Si el CRM cambia, cambias el módulo, y una actualización del núcleo no lo afecta mientras el hook siga existiendo.

En las páginas del back office que ya usan Symfony hay hooks para modificar listados y formularios, por ejemplo para añadir una columna al listado de pedidos o un campo al formulario de cliente. Para la lógica que no tiene hook, la vía documentada es proponerlo en el repositorio del proyecto o buscar otro punto de entrada; un override sigue siendo posible, pero conviene que sea la excepción y que esté documentado.

Servicios de Symfony y clases propias en lugar de overrides

En la parte de PrestaShop que funciona con Symfony, un módulo puede declarar servicios en sus archivos de configuración. Puede sustituir un servicio existente con el mismo nombre, o decorarlo: el servicio nuevo envuelve al original, que sigue disponible para llamarlo. La decoración es la opción más segura, porque solo cambias lo que necesitas y el resto del comportamiento sigue siendo el del núcleo.

Hay que saber dónde funciona cada cosa. El back office migrado tiene acceso al contenedor completo de Symfony, mientras que las páginas de la tienda siguen usando controladores antiguos con un contenedor más limitado. Un servicio pensado para el back office no está disponible en la tienda si no se declara también para ella.

Para datos nuevos, la recomendación oficial es una tabla propia con su clase de modelo dentro del módulo, en lugar de añadir campos a Product o Customer mediante un override. Así los datos del módulo viven en el módulo y se instalan y desinstalan con él. Si estás valorando si te compensa un desarrollo así, en PrestaShop: módulo propio o comprado tienes los criterios.

Cómo auditar los overrides de tu tienda

La auditoría se hace en una copia de la tienda, no en producción. El objetivo es saber qué hay, de dónde viene y qué se puede quitar antes de la próxima actualización.

Para el listado, revisa las subcarpetas de override (clases, controladores y módulos) y anota cada método sobrescrito. Para saber el origen, busca el mismo archivo dentro de la carpeta override de cada módulo instalado. PrestaShop suele dejar un comentario con el nombre del módulo encima de los métodos que instala, aunque no siempre está y no conviene fiarse solo de eso. Lo que no aparece en ningún módulo es manual, y es lo que más cuidado necesita porque nadie recuerda para qué está.

Después compara cada método con el original de tu versión y con el de la versión a la que quieres actualizar. Si el override es una copia con un par de líneas cambiadas, ya sabes qué hace en realidad. En el apartado de rendimiento de los parámetros avanzados hay, según la versión, una opción para desactivar todos los overrides. Activarla en la copia y repetir un pedido de prueba muestra rápido qué depende de ellos.

Con esa información, cada override acaba en uno de estos destinos:

• Se elimina, porque pertenece a un módulo desinstalado o hace algo que ya no se usa.
• Se sustituye por un hook, un servicio decorado o una clase propia dentro de un módulo PrestaShop a medida.
• Se mantiene de momento, con una nota de qué hace, por qué no tiene alternativa y qué hay que revisar en cada actualización.

Tras cada cambio, vacía la caché y prueba un pedido completo con cada método de pago y transportista. Si la tienda es multitienda, prueba también en cada escaparate.

Checklist antes de tocar los overrides de tu tienda

• Copia de la tienda restaurada, protegida y desconectada de pagos reales, ERP y correos a clientes.
• Listado de overrides con su método, su origen y la fecha en que se añadió si se conoce.
• Comparación con el núcleo de tu versión actual y de la versión de destino.
• Módulos que instalan overrides identificados, con su versión y si siguen mantenidos.
• Alternativa decidida para cada override: hook, servicio, clase propia o mantenerlo documentado.
• Pruebas de pedido completas después de cada retirada.
• Documento final con los overrides que se quedan y por qué.

Si quieres que hagamos esa revisión contigo, en mantenimiento PrestaShop empezamos por este inventario antes de actualizar o de tocar ningún módulo.