Nach 164 individuellen Plugins, ausgeliefert über dutzende Shopware-6-Projekte, habe ich dieselbe Handvoll Fehler immer wieder Shops zerlegen sehen.
Ein Plugin läuft ein Jahr lang sauber. Der Betreiber bestätigt am Wochenende ein Shopware-Update. Montagmorgen lädt der Admin nicht mehr. Bestellungen hängen. Die Agentur sagt “wir schauen uns das an” und stellt 30 Stunden in Rechnung.
Diese Geschichte ist vermeidbar. Meistens ist es kein Pech. Es ist ein Plugin, das für die Plattform falsch gebaut wurde.
Dieser Beitrag richtet sich an Betreiber, die entscheiden, wem sie ihren Shop anvertrauen, und an Agenturleitungen, deren Plugins gut altern sollen.
Shopware 6 spielt nach eigenen Regeln
Die meisten Entwickler kommen zu Shopware 6 von Magento, WooCommerce oder einer generischen Symfony-App. Die Reflexe, die anderswo funktionieren, kosten in Shopware 6 leise.
Die Plattform hat ihre eigene Architektur, und manche Entscheidungen wirken seltsam, bis sie Ihren Shop vor einem kaputten Update retten. Die wichtigste betrifft die Frage, wie Sie Shopwares eigenen Code erweitern.
Decoration: das Pattern, das Plugins am Leben hält
Wenn ein Entwickler ändern will, wie Shopware eine Bestellung versendet, gibt es zwei Wege.
Weg eins: Shopwares Klasse kopieren, die unliebsamen Stellen ändern und Shopware mitteilen, die Kopie zu verwenden. Das nennt man Override.
Weg zwei: Shopwares Klasse mit einer dünnen Schicht umhüllen, die die Änderung obendrauf legt, und Shopwares Originalklasse unangetastet lassen. Das nennt man Decoration.
Shopware 6 ist um Weg zwei herum gebaut. Der Grund ist mechanisch. Wenn Shopware nächsten Monat die Klasse aktualisiert und eine neue Methode hinzufügt, erbt die umhüllte Version diese Methode. Die Kopie nicht. Die Kopie driftet langsam aus dem Takt mit dem Original, bis etwas schiefgeht.
Dekorierte Plugins überleben Shopware-Updates. Überschriebene Plugins verpassen still neue Features und liefern irgendwann falsche Ergebnisse.
Die Shopware-Doku beschreibt die Mechanik, aber nicht die Abwägung. Es gibt einige Stellen, an denen Decoration die falsche Wahl ist: Warenkorbberechnung, Suchindexierung, alles auf einem Hot Path, wo die zusätzliche Schicht Millisekunden kostet. Dort sind ein Event-Subscriber oder ein Service-Replacement der richtige Schritt. Überall sonst: dekorieren.
Wenn Ihre Agentur standardmässig zu Klassen-Overrides greift, baut sie auf Weg eins. Die Kosten sind jetzt unsichtbar und tauchen beim nächsten Shopware-Update auf.
Die vier Fehler, die Shops am meisten kosten
Ich auditiere regelmässig Plugins anderer Agenturen. Vier Probleme tauchen immer wieder auf.
Admin-Komponenten überschreiben statt erweitern. Wenn Shopware die Basis-Komponente aktualisiert, geht das Override stumm aus. Kein Fehler, nur das falsche Rendering oder ein fehlendes Feld. Component Extensions liegen darüber und erben Änderungen mit. Dieselbe Idee wie Decoration, angewendet auf den Vue-Admin statt auf PHP-Services.
Plugins, die Zustand in geteilten Services halten. Shopware verwendet Service-Instanzen über Requests hinweg wieder. Wenn ein Service Daten aus einem Request cached, sieht der nächste Request sie ebenfalls. Der Bug zeigt sich als Kunde A, der die Daten von Kunde B sieht. Bis es bemerkt wird, steht das Datenleck längst in den Logs.
Plugin-Lifecycle-Hooks ignorieren. Shopware bietet install, update, activate und deactivate aus gutem Grund. Plugins, die diese Hooks ignorieren, funktionieren auf einer frischen Installation und beschädigen die Datenbank beim Update. Ich habe erlebt, wie eine einzige fehlende Migration einen Produktions-Shop 8 Stunden offline genommen hat.
Schwere Arbeit in synchronen Event-Subscribern. Ein Plugin, das jedes Mal beim Speichern eines Produkts eine externe API aufruft, blockiert das Speichern, bis die API antwortet. Wenn die API langsam ist, wirkt der Admin defekt. Die Lösung ist die Message Queue. Alles, was länger als ein Request-Zyklus dauert, gehört dorthin.
Alle vier sind vermeidbar. Wenn ein Plugin von Tag eins an um Decoration und Message Queue herum gebaut ist, kommt keiner dieser Fälle vor.
Wenn die Daten gross werden
Der Shopware Data Abstraction Layer (DAL) ist der Standardweg, um Entities zu lesen und zu schreiben. Sauber, sicher, und in der Skalierung der erste, der einknickt.
In einem Projekt mit 500.000+ SKUs lag die Importzeit bei 33 Stunden mit DAL-Schreiboperationen. Das auf unter 3 Stunden zu drücken, brauchte drei Änderungen: Batch-Verarbeitung mit einstellbaren Chunk-Grössen, Redis-gestütztes Queuing für die asynchrone Arbeit und direkte DBAL-Schreiboperationen für die Bulk-Inserts, an denen der DAL der Engpass war.
Die Grenze, die man kennen sollte: unter 10.000 Entities pro Operation ist der DAL in Ordnung. Darüber: benchmarken, bevor Sie sich festlegen. Ein Plugin, das für einen 5.000-Produkt-Shop gebaut wurde, kollabiert auf einem 100.000-Produkt-Shop, wenn niemand vorausgedacht hat.
Integrationen sind, wo Shops tatsächlich fallen
Die meisten Shopware-Projekte in der DACH-Region sprechen mit ERPs (SAP, Microsoft Dynamics, Sage), PIMs (Akeneo, Pimcore) und Lagersystemen. Eigenständige Shops sind selten. Jede Integration hat ihr eigenes Datenformat, ihren eigenen Sync-Rhythmus und ihre eigenen Fehlerbilder.
Das Muster, das hält: ein dedizierter Sync-Service pro Integration, jeder mit eigener Retry-Logik, Logging und Circuit Breaker. Die Shop-Logik hängt nie davon ab, dass ein externes System erreichbar ist. Wenn das Lager offline geht, bleibt der Storefront online.
Genau dieses Muster habe ich für einen Pharma-Distributor umgesetzt, der 300.000+ SKUs ohne einen Fulfillment-Fehler synchronisiert, und für eine B2B-Plattform, die Echtzeit-ERP-Angebote über OAuth2-REST-APIs integriert.
Migration von Shopware 5
Viele DACH-Shops laufen noch auf Shopware 5, zwei Jahre nach dem offiziellen End-of-Life im Juli 2024. Wenn Sie eine Migration planen: die Headline ist, dass Shopware 6 ein Neubau ist. Shopware-5-Plugins werden gegen die neue Architektur neu gebaut.
Der Neubau klingt teuer. Er ist auch die Gelegenheit, Jahre technischer Schulden in einem Schritt loszuwerden. Die Ersatz-Plugins nutzen von Tag eins an Decoration, den neuen Admin und den Flow Builder. Ich habe komplette Plattform-Migrationen ohne Downtime durchgeführt, indem beide Systeme während des Übergangs parallel liefen.
Was Sie vor der Beauftragung fragen sollten
Wenn Sie eine Agentur für ein Shopware-6-Projekt beauftragen, decken vier Fragen in einem Gespräch viel auf.
- Dekorieren Sie Services oder überschreiben Sie sie? “Decoration als Standard, Override nur mit Begründung” ist die Antwort, die Sie hören wollen.
- Testen Sie Plugins mit Produktionsdaten? Ein Plugin, das bei 1.000 Produkten läuft und bei 100.000 zusammenbricht, ist häufig.
- Wie behandeln Sie länger laufende Arbeit? Message Queue ist richtig. Im Event-Subscriber ist falsch.
- Wie behandeln Sie Plugin-Updates auf bestehenden Installationen? Alles ausser einer echten Migrationsstrategie ist eine rote Flagge.
Wenn Ihre Plugins längst in Produktion laufen und Sie vermuten, dass einige davon falsch gebaut sind, lohnt sich ein Audit von einem Beratungstag. Ein Audit kostet einen Tag. Es bei einem Shopware-Update herauszufinden, kostet sehr viel mehr.
Wo das Sie hinführt
Shopware 6 ist eine andere Plattform als alles andere in PHP. Teams, die das so behandeln, liefern Plugins, die Updates überleben, mit dem Katalog mitwachsen und im nächsten Wartungsbudget keine Position mehr sind.
Wenn Sie einen Shopware-6-Shop betreiben und das die Art von Arbeit ist, die Sie ordentlich erledigt haben möchten, nehmen Sie Kontakt auf. Konkrete Projekte finden Sie in den Case Studies.
Häufig gestellte Fragen
Was ist das Decoration-Pattern in Shopware 6? Decoration umhüllt einen bestehenden Service, um Verhalten zu ergänzen, ohne das Original zu ersetzen. Shopware 6 baut darauf, weil dekorierte Services weiterlaufen, wenn Shopware das Original aktualisiert, mehrere Plugins denselben Service dekorieren können, ohne sich zu blockieren, und ein Decorator isoliert getestet werden kann.
Wann ist Decoration die falsche Wahl? Auf Hot Paths wie Warenkorbberechnung oder Suchindexierung. Die zusätzliche Hülle erzeugt Call-Overhead, der bei hohem Volumen zählt. Dort ist das vollständige Ersetzen des Services oder die Nutzung eines Subscribers die bessere Wahl. Überall sonst: dekorieren.
Wie skaliert man Shopware-6-Plugins für grosse Kataloge? Drei Schritte: Batch-Verarbeitung mit einstellbaren Chunk-Grössen, Redis-gestütztes Queuing für asynchrone Arbeit und direkte DBAL-Schreiboperationen für Bulk-Inserts, wenn der DAL zum Engpass wird. Ab etwa 10.000 Entities pro Operation: benchmarken, bevor Sie sich auf den DAL festlegen.
Lassen sich Shopware-5-Plugins nach Shopware 6 portieren? Nein. Shopware 6 ist ein kompletter Neubau. Shopware-5-Plugins werden gegen die neue Architektur von Grund auf neu gebaut, mit Decoration, dem neuen Admin und der Message Queue.
Was lässt Shopware-6-Plugins bei Updates brechen? Vier häufige Ursachen: Services überschreiben statt dekorieren, Admin-Komponenten überschreiben statt erweitern, fehlende Update-Migrationen und synchrone Subscriber, die schwere Arbeit machen. Alle vier sind vermeidbar, wenn das Plugin von Tag eins an um Decoration und Message Queue herum gebaut ist.
