Overrides en PrestaShop: cuándo son aceptables y cómo evitarlos

Un override es una clase en la carpeta override/ que extiende una clase del núcleo (por ejemplo class Cart extends CartCore) y reescribe alguno de sus métodos. PrestaShop la carga en lugar de la original gracias a su autocargador y al índice de clases (var/cache/prod/class_index.php).

Por qué dan tantos problemas

• Firmas que cambian. Si el núcleo cambia los parámetros o los tipos de un método en una versión nueva, tu override deja de ser compatible y PHP lanza un error fatal al cargar la clase. En el paso a PrestaShop 9.1 varios métodos pasaron a aceptar tipos anulables explícitos, y los overrides antiguos dejaron de compilar.
• Dos módulos, un método. Solo un módulo puede sobrescribir un mismo método. El segundo que lo intenta falla en la instalación con el mensaje «the method X in the class Y is already overridden».
• Siguen activos aunque desactives el módulo. El override vive en override/, no en la carpeta del módulo. Desactivar el módulo no lo apaga; hay que desinstalarlo.
• Se pierden en silencio. Si una actualización o un despliegue vacía la carpeta, la tienda sigue funcionando pero sin la lógica que dependía del override.

Cómo saber qué overrides tienes

Cada override instalado por un módulo lleva un comentario de cabecera con el nombre del módulo:

/*
* module: mimodulo
* date: 2026-09-22 01:12:36
* version: 1.4.0
*/
public function getPackageShippingCost(...)

Un listado rápido desde la raíz de la tienda:

grep -rho "module: [a-z0-9_]*" override/ | sort | uniq -c

Los ficheros sin esa marca los puso alguien a mano: son los más peligrosos, porque nadie sabe por qué están.

Alternativas, de mejor a peor

1. Un hook. Casi todo lo que se hace con overrides en tiendas antiguas tiene hoy un hook: pintar algo en el carrito, modificar opciones de pago, reaccionar al guardar un objeto.
2. Decorar un servicio de Symfony. En el back office de PrestaShop 8 y 9 muchas piezas son servicios. Puedes envolver uno con el tuyo desde el services.yml de tu módulo sin tocar el original.
3. Sobrescribir una plantilla en el tema, si el cambio es visual.
4. Un override, solo cuando no hay otra vía, lo más pequeño posible y documentado.

Nuestra regla

Cuando un cliente nos pide una funcionalidad, el override es el último recurso. Si no queda más remedio, lo instala el propio módulo (nunca a mano), lleva su cabecera y aparece en la documentación de la tienda. Así, dentro de dos años, quien actualice sabrá qué hay y por qué.