Shopware Admin-Erweiterungen: Warum Ihre Plugins das 6.8-Update überleben müssen

Die Administration ist der Teil von Shopware, den Ihre Mitarbeiter täglich sehen — und zugleich der Teil, der bei Updates am häufigsten Ärger macht. Wenn nach einem Minor-Update ein Reiter leer bleibt, eine eigene Spalte in der Bestellübersicht verschwindet oder das ERP-Panel im Kundendatensatz nicht mehr lädt, liegt das selten am Core. Es liegt daran, wie die Erweiterung gebaut wurde. Mit Shopware 6.7.14.0 vom 9. September 2026 und dem absehbaren Sprung auf 6.8 ändert sich hier gerade die technische Grundlage. Wer seine Administration-Erweiterungen jetzt prüft, spart sich eine teure Notoperation im Zuge des Major-Updates.

Was sich mit Shopware 6.7.14 für Administration-Erweiterungen ändert

Shopware hat im September-Release drei Punkte geliefert, die unmittelbar auf die Erweiterbarkeit der Administration zielen. Erstens eine experimentelle API, mit der Administration-Erweiterungen als Vue Single File Components — also als klassische .vue-Dateien — entwickelt werden können. Shopware kündigt an, diese Schnittstelle mit 6.8 stabil zu stellen. Zweitens neue BC-Change-Attribute, die im Code sauber trennen, was eine echte Deprecation ist und was lediglich eine für 6.8 geplante API-Änderung. Drittens strengere ACL-Prüfungen: Die Endpunkte für Bestellungen, Medien, SEO und Nummernkreise prüfen Berechtigungen nun explizit.

Dazu kommt ein Punkt, den viele Teams überlesen: Die Symfony-XML-Konfiguration ist als veraltet markiert und wird mit Shopware 6.8 entfernt. Jedes Plugin, das seine Services noch in services.xml definiert, braucht also eine Migration auf PHP- oder YAML-Konfiguration. Das ist kein Hexenwerk, aber es betrifft praktisch jedes gewachsene Projekt, und es betrifft es flächendeckend. Eine Nebenbemerkung im Changelog wird so zur Aufgabe im Sprint-Backlog.

Der rote Faden hinter all dem ist derselbe: Shopware zieht die Administration Schritt für Schritt aus der alten Twig-JS-Welt heraus und in eine moderne Vue-Architektur mit klaren Schnittstellen. Für Sie als Betreiber heißt das, dass die Art, wie Ihre Erweiterungen angebunden sind, über die Update-Kosten der nächsten Jahre entscheidet.

Warum Admin-Plugins beim Update als Erstes brechen

Der klassische Weg, die Administration anzupassen, ist das Override. Eine Komponente wird überschrieben, ein Twig-Block erweitert, eine interne Methode umgebogen. Das funktioniert — solange die überschriebene Stelle im Core existiert und sich nicht verändert. Genau das ist die Wette, die man mit jedem Override eingeht: Man koppelt die eigene Erweiterung an Interna, für die niemand Stabilität zugesagt hat.

Wie fragil diese Kopplung ist, hat sich zuletzt an der Twig-Version gezeigt. Shopware nutzt in der Administration interne Twig-APIs, die nicht vom Kompatibilitätsversprechen von Twig abgedeckt sind. Als Twig 3.28 eine dieser internen Schnittstellen änderte, konnte ein gewöhnliches Composer-Update die Administration lahmlegen; Shopware hat das ab Version 6.7.12.1 abgefangen. Der Vorfall ist ein gutes Lehrstück, weil hier nicht einmal ein Plugin schuld war, sondern eine transitive Abhängigkeit. Mit jedem eigenen Override multiplizieren Sie genau diese Art von Risiko.

Hinzu kommt die laufende Ablösung der Administration-Komponenten durch die Meteor Component Library, die mit 6.7 begonnen hat. Shopware liefert dazu Codemods, die einen Teil der Ersetzungen automatisiert vornehmen, sowie einen deprecated-Prop, mit dem sich eine Codebasis übergangsweise an beiden Versionen betreiben lässt. Das ist hilfreich — aber es ist ein Übergangswerkzeug, kein Dauerzustand. Wer die Migration aussitzt, sammelt technische Schulden, die beim Major-Update auf einen Schlag fällig werden. In unseren Referenzprojekten ist der Admin-Bereich regelmäßig der Posten, der ein Update von „zwei Tagen“ auf „zwei Wochen“ hebt.

Meteor Admin SDK und Vue-SFC: der Weg aus der Override-Falle

Die Alternative zum Override ist die Erweiterung über definierte Schnittstellen. Das Meteor Admin SDK ist genau dafür gedacht: Erweiterungen laufen in einem isolierten iframe und kommunizieren über ein Messaging-System mit der Administration, statt sich in deren Innenleben einzuklinken. Das klingt nach Umweg, ist aber der entscheidende Unterschied. Was über eine dokumentierte Schnittstelle läuft, hat ein Versprechen; was über ein Override läuft, hat keines.

App statt Plugin: wann sich der Schnitt lohnt

Technisch führt dieser Weg oft weg vom klassischen Core-Plugin hin zur App. Der Gewinn ist handfest: Die Erweiterung ist vom Core-Update entkoppelt, sie lässt sich unabhängig deployen, und sie überlebt Versionssprünge, die ein Override nicht überlebt. Sinnvoll ist der Schnitt vor allem bei eigenständiger Oberfläche — einem ERP- oder PIM-Panel, einem Dashboard für den Vertrieb, einer Freigabe-Ansicht für B2B-Prozesse. Alles, was eine eigene Fläche in der Administration bekommt, ist ein guter Kandidat.

Mit der neuen Vue-SFC-Unterstützung wird dieser Weg zusätzlich attraktiv, weil Sie nicht mehr in einer Shopware-eigenen Template-Welt arbeiten, sondern in einem Standard, für den Sie am Markt Entwickler finden. Das ist für die Personalplanung oft das stärkere Argument als jedes technische. Wir berücksichtigen das in der Shopware Entwicklung von Anfang an: Je näher eine Erweiterung am Standard gebaut ist, desto geringer ist die Abhängigkeit von einzelnen Köpfen.

Was trotzdem im Core-Plugin bleibt

Nicht alles gehört in eine App. Alles, was tief in Geschäftslogik, Datenmodell oder Performance eingreift — eigene Entitäten, Preisberechnungen, komplexe Importe, kritische Schreibpfade — bleibt besser im Plugin, nah am Core und ohne den Umweg über HTTP. Die saubere Aufteilung lautet also nicht „App statt Plugin“, sondern: Logik ins Plugin, Oberfläche über das SDK. Wer diese Grenze einmal zieht, hat bei jedem Update nur noch eine Front zu verteidigen statt zwei.

Die Aufräumliste vor Shopware 6.8

Bevor Sie über Zeitpläne reden, brauchen Sie ein Bild vom Ist-Zustand. Fünf Fragen reichen für eine erste Einschätzung:

• Wie viele Overrides gibt es in der Administration? Zählen Sie die überschriebenen Komponenten und Templates — diese Zahl ist Ihr Update-Risiko in einer Kennzahl.

• Welche Plugins konfigurieren noch per XML? Jede verbliebene services.xml ist ein Blocker für 6.8 und sollte vor dem Major-Update auf PHP oder YAML stehen.

• Welche Erweiterungen greifen auf Endpunkte mit neuen ACL-Prüfungen zu? Integrationen, die bisher mit zu weit gefassten Rechten liefen, fallen jetzt auf, nicht erst im Produktivbetrieb.

• Welche Drittanbieter-Plugins sind betroffen? Fragen Sie die Hersteller nach deren 6.8-Fahrplan, bevor Sie Ihren eigenen festlegen. Ein einziges nicht gepflegtes Plugin kann den Termin kippen.

• Was davon brauchen Sie überhaupt noch? Erfahrungsgemäß ist ein spürbarer Teil der Anpassungen historisch gewachsen und heute ohne Funktion. Löschen ist die günstigste Migration.

Aus den Antworten ergibt sich fast von selbst eine Reihenfolge: zuerst weg, was niemand mehr nutzt, dann die XML-Konfiguration, dann die Overrides mit der höchsten Bruchwahrscheinlichkeit, zuletzt die Neubauten über das SDK. Das Vorgehen entspricht dem, was wir aus Projekten der Shopware Migration kennen: Bestand messen, Ballast abwerfen, dann erst neu bauen. Umgekehrt wird es teuer, weil Sie sonst Code migrieren, den Sie gar nicht behalten wollten.

Was das für Ihre Roadmap bedeutet

Der wichtigste Punkt ist das Timing. Solange Sie auf 6.7 unterwegs sind, haben Sie beides: eine laufende Installation und die neuen Werkzeuge, um Erweiterungen umzubauen. Dieses Zeitfenster ist der günstigste Moment für die Arbeit, weil Sie ohne Termindruck migrieren können. Wenn das Major-Update bereits ansteht, wird aus derselben Aufgabe ein Projekt unter Zeitdruck — mit allem, was dazugehört: Testaufwand, Wochenendarbeit, Risiko im Livebetrieb.

Planen Sie den Umbau deshalb nicht als Reaktion auf 6.8, sondern als Vorarbeit. Zwei bis drei Sprints für Bestandsaufnahme, Entrümpelung und die Migration der kritischen Erweiterungen sind in den meisten Projekten realistisch — und sie zahlen sich bei jedem folgenden Update erneut aus, nicht nur bei diesem einen. Wer seine Administration-Erweiterungen entkoppelt hat, aktualisiert Shopware künftig in Tagen statt in Wochen.

Als spezialisierte Shopware Agentur Köln sehen wir täglich, welchen Unterschied diese Entscheidung macht: Shops mit sauber angebundenen Erweiterungen gehen Updates gelassen an, während gewachsene Override-Landschaften jedes Release zur Risikoabwägung machen. Sie wollen Ihr Shopware-Setup auf das nächste Level heben? Wir analysieren Ihre Administration-Erweiterungen, zeigen Ihnen, welche davon den Sprung auf 6.8 nicht überstehen, und bauen mit Ihnen einen Shop, der mitwächst — sprechen Sie mit enno.dev, Ihrer Shopware Agentur.