Override in PrestaShop: quando sono accettabili e come evitarli

Un override è una classe nella cartella override/ che estende una classe del core (per esempio class Cart extends CartCore) e riscrive alcuni dei suoi metodi. PrestaShop la carica al posto dell'originale grazie al suo autoloader e all'indice delle classi (var/cache/prod/class_index.php).

Perché danno così tanti problemi

• Firme che cambiano. Se il core cambia i parametri o i tipi di un metodo in una nuova versione, il tuo override non è più compatibile e PHP lancia un errore fatale al caricamento della classe. Nel passaggio a PrestaShop 9.1 diversi metodi hanno iniziato ad accettare tipi nullable espliciti, e i vecchi override hanno smesso di compilare.
• Due moduli, un metodo. Solo un modulo può sovrascrivere uno stesso metodo. Il secondo che ci prova fallisce all'installazione con il messaggio «the method X in the class Y is already overridden».
• Restano attivi anche se disattivi il modulo. L'override vive in override/, non nella cartella del modulo. Disattivare il modulo non lo spegne; bisogna disinstallarlo.
• Si perdono in silenzio. Se un aggiornamento o un deploy svuota la cartella, il negozio continua a funzionare ma senza la logica che dipendeva dall'override.

Come sapere quali override hai

Ogni override installato da un modulo ha un commento d'intestazione con il nome del modulo:

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

Un elenco rapido dalla root del negozio:

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

I file senza quel segno li ha messi qualcuno a mano: sono i più pericolosi, perché nessuno sa perché ci sono.

Alternative, dalla migliore alla peggiore

1. Un hook. Quasi tutto ciò che si fa con gli override nei negozi vecchi oggi ha un hook: mostrare qualcosa nel carrello, modificare le opzioni di pagamento, reagire al salvataggio di un oggetto.
2. Decorare un servizio di Symfony. Nel back office di PrestaShop 8 e 9 molti pezzi sono servizi. Puoi avvolgerne uno con il tuo dal services.yml del tuo modulo senza toccare l'originale.
3. Sovrascrivere un template nel tema, se la modifica è visiva.
4. Un override, solo quando non c'è altra strada, il più piccolo possibile e documentato.

La nostra regola

Quando un cliente ci chiede una funzionalità, l'override è l'ultima risorsa. Se non c'è alternativa, lo installa il modulo stesso (mai a mano), ha la sua intestazione e compare nella documentazione del negozio. Così, tra due anni, chi aggiornerà saprà cosa c'è e perché.