Overrides in PrestaShop: wann sie vertretbar sind und wie Sie sie vermeiden

Ein Override ist eine Klasse im Ordner override/, die eine Core-Klasse erweitert (zum Beispiel class Cart extends CartCore) und einige ihrer Methoden neu schreibt. PrestaShop lädt sie dank seines Autoloaders und des Klassenindex (var/cache/prod/class_index.php) anstelle der Originalklasse.

Warum sie so viele Probleme machen

• Signaturen, die sich ändern. Wenn der Core in einer neuen Version die Parameter oder Typen einer Methode ändert, ist Ihr Override nicht mehr kompatibel und PHP wirft beim Laden der Klasse einen fatalen Fehler. Beim Wechsel auf PrestaShop 9.1 akzeptierten mehrere Methoden plötzlich explizit nullable Typen, und alte Overrides ließen sich nicht mehr kompilieren.
• Zwei Module, eine Methode. Nur ein Modul kann dieselbe Methode überschreiben. Das zweite, das es versucht, scheitert bei der Installation mit der Meldung „the method X in the class Y is already overridden“.
• Sie bleiben aktiv, auch wenn Sie das Modul deaktivieren. Der Override liegt in override/, nicht im Modulordner. Das Deaktivieren des Moduls schaltet ihn nicht ab; man muss es deinstallieren.
• Sie gehen still verloren. Wenn ein Update oder ein Deployment den Ordner leert, läuft der Shop weiter, aber ohne die Logik, die vom Override abhing.

So finden Sie heraus, welche Overrides Sie haben

Jeder von einem Modul installierte Override trägt einen Kopfkommentar mit dem Namen des Moduls:

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

Eine schnelle Auflistung aus dem Stammverzeichnis des Shops:

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

Dateien ohne diese Markierung hat jemand von Hand dort abgelegt: Sie sind die gefährlichsten, weil niemand weiß, warum sie da sind.

Alternativen, von besser zu schlechter

1. Ein Hook. Fast alles, was in alten Shops mit Overrides gemacht wird, hat heute einen Hook: etwas im Warenkorb anzeigen, Zahlungsoptionen ändern, auf das Speichern eines Objekts reagieren.
2. Einen Symfony-Service dekorieren. Im Backoffice von PrestaShop 8 und 9 sind viele Bausteine Services. Sie können einen davon über die services.yml Ihres Moduls mit Ihrem eigenen umhüllen, ohne das Original anzufassen.
3. Ein Template im Theme überschreiben, wenn die Änderung optisch ist.
4. Ein Override, nur wenn es keinen anderen Weg gibt, so klein wie möglich und dokumentiert.

Unsere Regel

Wenn ein Kunde eine Funktion von uns möchte, ist der Override das letzte Mittel. Wenn es nicht anders geht, installiert ihn das Modul selbst (nie von Hand), er trägt seinen Kopfkommentar und steht in der Dokumentation des Shops. So weiß in zwei Jahren, wer aktualisiert, was es gibt und warum.