Shopware Plugin-Entwicklung 2026: Warum 80 % der Plugins eure Updates blockieren

Euer Shopware-Shop läuft seit Jahren. 18, vielleicht 24 Plugins sind installiert - jedes davon hat damals ein konkretes Problem gelöst. Heute steht das nächste Major-Update an, und plötzlich kostet allein die Frage „können wir auf 6.7 hoch?" mehrere Tausend Euro Vorbereitungszeit. Und niemand kann zusagen, dass der Shop danach noch alles kann, was er heute kann.

Das ist keine Ausnahme - das ist der Normalfall. Und in den allermeisten Fällen liegt es nicht an Shopware, sondern an den Plugins.

Das Plugin-Paradox

Jedes Plugin verspricht euch ein Feature in fünf Minuten Installation. Im Hintergrund schließt es dafür einen unsichtbaren Vertrag mit eurem Shop: Es greift in den Bestellprozess ein, dekoriert Services, überschreibt Templates, patcht den Core - manche davon sogar direkt im vendor-Verzeichnis. Jeder dieser Eingriffe ist ein Punkt, an dem ein Shopware-Update brechen kann.

In einem typischen gewachsenen Shopware-6-Shop, den wir uns ansehen, sind drei Muster wiederkehrend - und vermutlich erkennt ihr euren Shop direkt darin:

1. Marketplace-Plugins, die seit zwei Jahren nicht mehr aktualisiert wurden. Der Hersteller existiert vielleicht noch, der Code aber friert auf Shopware 6.4 ein. Beim Sprung auf 6.7 fehlt nicht nur die Kompatibilität, sondern auch jemand, der sie liefern kann.

2. „Eigene" Plugins, die niemand mehr versteht. Vor drei Jahren hat eine Agentur eine Funktion gebaut, die euer Pricing-Modell abbildet. Heute ist die Agentur weg, der Code ist nicht dokumentiert, und das Plugin überschreibt drei Core-Services - inklusive einer Stelle, die in Shopware 6.7 gar nicht mehr existiert.

3. Plugins, die ihr nicht mehr braucht. Drei oder vier Stück, die mal für eine Kampagne gebaut wurden oder eine Funktion ersetzten, die Shopware inzwischen selbst kann. Sie laden trotzdem bei jedem Request mit.

Das Ergebnis ist immer dasselbe: ein Shop, der funktioniert, solange ihn niemand anfasst. Sobald der nächste Sicherheits-Patch oder das nächste Feature aus Shopware kommt, wird aus einem Routine-Update ein Projekt.

Was ein Plugin 2026 wirklich „upgrade-fest" macht

Ein gut gebautes Plugin ist nicht das, was am meisten Funktionen mitbringt. Es ist das, was sich beim nächsten Shopware-Update am leisesten verhält. Vier technische Eigenschaften entscheiden über diesen Unterschied:

• Keine Core-Patches, keine vendor-Eingriffe. Ein Plugin, das Shopware-Dateien direkt verändert, gibt es im Maintenance-Vertrag nicht für umsonst. Beim nächsten Update sind die Patches weg - oder schlimmer, sie kollidieren still.

• Saubere Dependency Injection und Decorator-Pattern. Wer Shopware-Services dekoriert, statt sie zu überschreiben, bricht beim Update nicht - solange die Schnittstelle stabil bleibt. Shopware kommuniziert Breaking Changes Major-Versionen im Voraus.

• Tests, die beim CI/CD-Lauf grün sein müssen. Ein Plugin ohne Tests ist eine Annahme. Erst Unit-Tests für die Business-Logik plus ein paar Integrationstests gegen die Shopware-API machen aus „läuft" ein „läuft nachweisbar". Beim Update wisst ihr in Minuten, was bricht - nicht erst, wenn ein Kunde anruft.

• Kompatibilitäts-Range statt fixer Version. Ein Plugin, das `"shopware/core": "~6.6.0"` verlangt, blockiert euch sofort beim 6.7-Update. `"^6.6"` ist meist die ehrlichere Variante - kombiniert mit einer Test-Pipeline, die das auch wirklich beweist.

Wenn ihr ein Marketplace-Plugin bewertet, könnt ihr die ersten drei Punkte oft schon aus dem öffentlichen GitHub-Repo oder dem composer.json ablesen - bevor ihr einen Cent investiert.

Marketplace, fertig kaufen oder selbst bauen?

Die Entscheidung ist selten ideologisch. Sie hängt an drei nüchternen Fragen:

Ist die Funktion Standard? Ein DHL-Versandlabel oder ein Klarna-Checkout ist Standard. Ein Marketplace-Plugin mit aktivem Hersteller ist hier fast immer die richtige Antwort - selbst wenn es 49 € pro Monat kostet. Selber zu bauen bedeutet hier, denselben Wartungsaufwand wie der Hersteller zu tragen, ohne dessen Skaleneffekte.

Ist die Funktion euer Geschäftsmodell? Wenn euer Pricing, eure Konfiguratoren, eure B2B-Workflows oder eure ERP-Anbindung das sind, was euch von Wettbewerbern unterscheidet - dann gehört dieser Code euch. Nicht einem Plugin-Hersteller, den ihr nicht kontrolliert. Custom-Entwicklung ist teurer, aber sie sichert genau den Bereich, der euer Geschäft trägt.

Was kostet das Plugin in 24 Monaten? Nicht heute. Ein Marketplace-Plugin für 29 € pro Monat ist über zwei Jahre 700 € - plus Update-Kompatibilität, plus Lock-in, falls der Hersteller die Richtung wechselt. Bei einer Custom-Lösung steht der Aufwand am Anfang, aber der Code gehört euch und altert kontrolliert.

Eine pragmatische Faustregel: Standard-Funktionen kauft ihr, geschäftskritische Logik baut ihr - und beides muss denselben technischen Qualitätsmaßstab erfüllen.

Wo KI in der Plugin-Entwicklung 2026 wirklich hilft

KI-Tools haben in der Plugin-Welt im letzten Jahr einen leisen Rollenwechsel gemacht. Sie ersetzen keine Entwickler, aber sie verändern, wo deren Zeit hingeht.

Plugin-Audits werden in Stunden machbar, nicht Tagen. Mit Coding-Agents wie Claude Code lässt sich der gesamte Plugin-Code eines Shops automatisiert daraufhin prüfen, ob er Core-Patches setzt, deprecated APIs benutzt oder gegen Shopware-Konventionen verstößt. Was früher ein Senior-Entwickler manuell durchgegangen ist, läuft heute als Pre-Check für ein Update durch - und liefert eine konkrete Liste statt eines Bauchgefühls.

Migrations-Patches werden generierbar. Wenn Shopware in 6.7 eine API umbenennt oder einen Service umstrukturiert, kann ein KI-Tool die nötigen Anpassungen in einem Plugin in vielen Fällen als Pull Request vorbereiten. Reviewen muss das Team, schreiben muss niemand mehr.

Tests werden zur Selbstverständlichkeit. Das größte Hemmnis für Tests war historisch der Aufwand. Mit KI-gestützter Test-Generierung kostet ein erstes Test-Set für ein bestehendes Plugin Stunden statt Tage. Damit fällt eine der Hauptausreden weg, warum „unsere Plugins keine Tests haben".

Wichtig: KI ersetzt nicht den menschlichen Review eures Plugins. Aber sie verschiebt die Wirtschaftlichkeit. 2026 ist es schlicht günstiger, ein Plugin sauber zu bauen, als nochmal mit dem Argument „Tests sind zu teuer" zu starten.

Womit ihr diese Woche anfangen könnt

Ihr braucht keinen großen Plugin-Strategie-Workshop, um in eine bessere Ausgangslage zu kommen. Drei Schritte reichen für den Anfang:

1. Macht eine ehrliche Plugin-Inventur. Welche Plugins habt ihr aktiviert? Wer hat sie gebaut? Wann wurden sie zuletzt aktualisiert? Welche braucht ihr heute noch wirklich? Allein das Deaktivieren von zwei oder drei toten Plugins macht jedes Update spürbar leichter.

2. Klärt die Eigentumsfrage pro Plugin. Bei eigenen Plugins: Habt ihr den Code? Habt ihr ihn dokumentiert? Bei Marketplace-Plugins: Wisst ihr, was passiert, wenn der Hersteller morgen die Lichter ausmacht? Ein einseitiges Notfall-Dokument pro Plugin spart euch im Ernstfall Wochen.

3. Definiert Qualitätsmaßstäbe für neue Plugins. Bevor das nächste Plugin in euren Shop kommt - egal ob gekauft oder gebaut: keine Core-Patches, Tests vorhanden, Kompatibilität dokumentiert, klare Eigentumsverhältnisse. Das ist kein bürokratischer Akt, sondern eine Versicherung gegen die nächsten Update-Kosten.

Fazit

Plugins sind nicht das Problem. Plugins, die niemand mehr versteht oder pflegt, sind das Problem. Wer in 2026 Shopware-Plugins entwickelt oder einkauft, kauft nicht primär Features - er kauft die Wartbarkeit der nächsten zwei, drei Major-Updates mit.

Die gute Nachricht: Mit modernem Plugin-Design, einer ehrlichen Inventur und KI-gestützten Audit-Tools wird genau das messbar - und in vielen Fällen erstaunlich günstig zu verbessern, ohne dass ihr euren Shop neu bauen müsst.