Shopware 6: Plugins statt Core-Hacks

Ein Onlineshop ist selten ein Projekt, das irgendwann fertig ist. Zahlungsarten ändern sich, Versanddienstleister stellen Schnittstellen um, das Warenwirtschaftssystem bekommt ein neues Feld, und Shopware selbst veröffentlicht regelmäßig Updates mit Sicherheitskorrekturen und neuen Funktionen. Gerade deshalb entscheidet sich die Qualität eines Shopware-6-Projekts nicht am Tag des Livegangs, sondern beim zweiten, dritten und zehnten Update danach.

Unser Grundsatz dafür ist einfach: Der Kern von Shopware wird nicht angefasst. Jede Anpassung lebt in einem Plugin, einem Theme oder einer App. Warum das so wichtig ist und wie das in der Praxis aussieht, beschreiben wir hier.

Warum Core-Änderungen teuer werden

Eine direkte Änderung an einer Datei im Verzeichnis des Shopware-Kerns wirkt zunächst schnell und bequem. Das Problem zeigt sich später: Beim nächsten Update wird die Datei ersetzt, und die Änderung ist entweder stillschweigend verschwunden oder muss von Hand neu eingepflegt werden. Oft weiß nach einem Jahr niemand mehr genau, welche Zeilen verändert wurden und warum.

Die Folge ist bekannt: Updates werden aufgeschoben, weil sie riskant wirken. Der Shop bleibt auf einem alten Stand, Sicherheitskorrekturen kommen verspätet an, und irgendwann ist der Abstand zur aktuellen Version so groß, dass ein Update einem Neubau gleicht. Ein Shop, der nicht mehr aktualisiert werden kann, ist ein Risiko – technisch und wirtschaftlich.

Die Werkzeuge, die Shopware mitbringt

Shopware 6 basiert auf Symfony und ist von Grund auf für Erweiterungen gebaut. Ein Plugin ist im Kern ein Symfony-Bundle mit eigenem Lebenszyklus: Es wird installiert, aktiviert, aktualisiert und bei Bedarf wieder entfernt. Innerhalb eines Plugins stehen mehrere Mechanismen zur Verfügung.

Services dekorieren statt ersetzen

Soll sich eine Kernfunktion anders verhalten, etwa die Preisberechnung oder das Laden von Produkten, dekorieren wir den zuständigen Service. Das Decorator-Pattern legt eine eigene Klasse um den Originalservice, übernimmt dessen Schnittstelle und ergänzt oder verändert nur das, was nötig ist. Der Rest wird an das Original weitergereicht. Ändert Shopware den Originalservice in einem Update, profitiert der Shop davon, ohne dass wir etwas nachziehen müssen – solange die Schnittstelle stabil bleibt.

Auf Ereignisse reagieren

Viele Anpassungen brauchen gar keinen Eingriff in eine Klasse. Shopware löst an zahlreichen Stellen Events aus: wenn eine Seite geladen, eine Bestellung abgeschlossen oder eine Entität geschrieben wird. Ein Event-Subscriber im Plugin hängt sich genau dort ein, ergänzt Daten für das Template oder stößt einen Folgeprozess an, zum Beispiel die Übergabe an ein externes System.

Templates erben statt kopieren

Im Storefront arbeiten wir mit der Twig-Template-Vererbung von Shopware. Mit sw_extends erweitert ein Plugin- oder Theme-Template das Original und überschreibt gezielt einzelne Blöcke. Mit parent() bleibt der ursprüngliche Inhalt eines Blocks erhalten. Statt eine komplette Vorlage zu kopieren, ändern wir nur den Block, der sich wirklich unterscheidet. Das Theme selbst ist ebenfalls ein Plugin und wird genauso versioniert und ausgeliefert.

Eigene Daten sauber modellieren

Braucht ein Shop eigene Datenstrukturen, definieren wir sie über den Data Abstraction Layer (DAL) von Shopware: eine Entity-Definition beschreibt Felder und Beziehungen, eine Migration legt die Tabelle an. So stehen die Daten automatisch in den APIs und in der Administration zur Verfügung, und bestehende Kern-Entitäten lassen sich über Erweiterungen ergänzen, ohne ihre Tabellen zu verändern.

Die Administration erweitern

Auch die Administration ist erweiterbar. Eigene Module, zusätzliche Felder in bestehenden Masken oder neue Einstellungsseiten entstehen als Plugin-Komponenten, die Shopware beim Build einbindet.

Plugin oder App?

Neben Plugins kennt Shopware 6 das App-System. Eine App läuft nicht im Shop selbst, sondern kommuniziert über Webhooks und die Admin API mit ihm. Das eignet sich für Erweiterungen, die auch in der Cloud-Variante von Shopware funktionieren sollen, oder für Logik, die ohnehin auf einem eigenen Server liegt. Plugins dagegen haben vollen Zugriff auf die Symfony-Welt und sind die richtige Wahl, wenn tief in Abläufe eingegriffen werden muss. Wir entscheiden das pro Anforderung, nicht pauschal.

Wie wir Shopware-Projekte aufsetzen

• Composer-basiertes Projekt: Shopware und alle Abhängigkeiten sind in composer.json festgehalten. Versionen sind nachvollziehbar, Updates werden bewusst eingespielt.
• Eigene Plugins im Repository: Projektspezifische Erweiterungen liegen versioniert neben dem Projekt, mit klaren Namen und einer Aufgabe pro Plugin.
• Keine Änderungen im Vendor-Verzeichnis: Was dort liegt, gehört Shopware oder den Herstellern der Erweiterungen.
• Staging vor Produktion: Updates werden zuerst in einer Testumgebung mit realistischen Daten eingespielt und geprüft – Checkout, Zahlungsarten, Schnittstellen.
• Automatisierte Prüfungen: Statische Analyse und Tests für eigene Plugins fangen Brüche in Schnittstellen früh ab.

Neue Projekte setzen wir auf Shopware 6.7 auf. Weil jede Anpassung in einem eigenen Plugin steckt, lässt sich vor einem Update einzeln prüfen, welche Erweiterung von einer geänderten Schnittstelle betroffen ist.

Fazit

Ein Shop, der sich sauber aktualisieren lässt, bleibt sicher, schnell und offen für neue Funktionen. Plugins, Decorators, Events und Template-Vererbung sind dafür keine Zusatzarbeit, sondern die Arbeitsweise, die Shopware 6 von Anfang an vorsieht. Wenn Sie einen bestehenden Shop übernehmen lassen möchten, der Updates bisher nicht mehr verträgt, prüfen wir zuerst, wo der Kern verändert wurde, und überführen diese Stellen Schritt für Schritt in Erweiterungen.