Warum ein eigenes Plugin oft die bessere Antwort ist
Shopware 6 ist eine starke E-Commerce-Plattform, aber kein All-in-One. Sobald das Geschäftsmodell Sonderlogik braucht, die nicht im Standard abgedeckt ist, gibt es zwei Wege: ein Store-Plugin kaufen, das vielleicht 80 Prozent trifft, oder ein eigenes Plugin entwickeln, das genau passt. Beide Ansätze haben ihre Berechtigung. Faustregel: Je näher die Funktion an Ihrem Alleinstellungsmerkmal liegt, desto eher lohnt sich Custom-Code. Generische Funktionen wie Cookie-Banner oder einfache Tracking-Pixel sind im Store oft günstiger und schneller verfügbar. Spezifische Geschäftslogik (Staffelpreise mit Sonderregeln, individuelle Gratisartikel-Logik, B2B-Workflows mit ERP-Bezug) ist im eigenen Plugin meist besser aufgehoben.
Plugin-Architektur in Shopware 6: was sich gegenüber SW5 geändert hat
Die Plugin-Architektur in Shopware 6 ist grundlegend anders als in SW5. Statt Smarty-Templates kommen Twig-Blöcke zum Einsatz, das Backend ist eine eigene Vue-3-App, die über die Admin-API mit dem Shop spricht. Erweiterungspunkte sind Event-Subscriber (Reaktion auf Domain-Events), Decorator (Ergänzung oder Überschreibung bestehender Services), Storefront-Controller-Erweiterungen, Twig-Block-Overrides und Custom Entities mit Migrations und Repositories. Plugins werden gegen den Symfony-Dependency-Injection-Container registriert und folgen dem klassischen Plugin-Lifecycle (install, update, uninstall, activate, deactivate). Sauberer Code in diesem Modell ist update-sicher, schlecht gebauter Code kippt beim nächsten Minor-Release.
Store-Plugin oder Custom-Plugin: wann was sinnvoller ist
Vor jeder Plugin-Anfrage stelle ich die Frage: gibt es ein Store-Plugin, das die Anforderung sauber abdeckt? Wenn ja und der Hersteller pflegt das Plugin aktiv, ist Kaufen meist günstiger als Entwickeln. Wenn nein, oder wenn das Geschäftsmodell so spezifisch ist, dass Anpassungen nötig wären, lohnt sich Custom-Code. Drittes Szenario: ein Store-Plugin trifft 80 Prozent, der Rest ist individuelle Logik. Hier ist ein eigenes Decorator-Plugin oft die wartungsärmste Lösung: das Original-Plugin bleibt update-sicher und Ihre Sonderlogik liegt in einem klar abgegrenzten Modul, das Sie ohne Lizenz-Rücksicht weiterentwickeln können.
ERP- und Schnittstellen-Plugins als eigenes Spezialgebiet
Viele B2B-Shopware-Shops brauchen ERP-Anbindungen: Sage 100, JTL Wawi, Plentymarkets, DATEV, oder eigene SQL-Server-Lösungen. Standardisierte Plugins gibt es teilweise im Store, aber sobald Stammdaten-Mapping, Sonderpreis-Regeln oder mehrstufige Bestellprozesse ins Spiel kommen, sind individuelle Lösungen meist effizienter. Mein Vorgehen: Webhook-basierte Sync-Plugins mit Logging, Retry-Mechanik und sauberen Fehlerausgaben. Kein „Skript läuft täglich um drei Uhr und niemand weiß was, wenn es kippt", sondern beobachtbare Schnittstellen mit klaren Monitoring-Hooks.
Tracking- und Affiliate-Plugins mit DSGVO-Bewertung
Tracking-Plugins sind ein eigenes Themenfeld in Shopware 6, weil sie Cookie-Consent, DSGVO-Konformität und korrekte Storefront-Integration vereinen müssen. Aus eigener Code-Hand: InvTrackingAdcell und InvTrackingSovendus, beide mit Shopware-Store-Review-Durchlauf. Was in solchen Plugins zählt: Pixel werden erst nach gesetztem Consent geladen, Server-Side-Tracking als Option für AdBlocker-resistente Conversion-Messung, sauberes Mapping zwischen Shopware-Bestelldaten und Affiliate-Parametern, klare Fallbacks bei fehlenden Trackingparametern. DSGVO-Bewertung gehört zur Lieferung, nicht als Disclaimer im FAQ.
Plugin-Wartung über Shopware-Versionen
Ein Plugin ist selten fertig. Shopware veröffentlicht regelmäßig Minor- und Major-Versionen, manchmal mit API-Änderungen, geänderten Twig-Blocks oder neuen Erweiterungspunkten. Plugins, die nur gegen eine bestimmte Shopware-Version gebaut wurden, kippen früher oder später. Mein Ansatz: Plugin-Code wird gegen mehrere Shopware-Versionen getestet, kritische Code-Stellen sind versionssensitiv dokumentiert, ein einfaches Update-Skript begleitet das Plugin über Major-Releases. Bei Bestand-Plugins, die ich nicht selbst gebaut habe, läuft erst ein Audit, danach ein Migrations-Plan.
Plugin als Store-App: was bei der Marketplace-Einreichung zählt
Wer ein Plugin in den Shopware Marketplace einreichen will, sollte wissen, was das Review-Team prüft: saubere Code-Struktur ohne Direktzugriff auf die Datenbank, korrekte Lifecycle-Methoden, Multi-Language-Support per Snippets, dokumentierte Konfigurationsoptionen, DSGVO-Bewertung bei Datenverarbeitung, korrekte Storefront-Integration ohne ESI-Cache-Brüche. Aus eigener Erfahrung mit mehreren Plugin-Einreichungen kann ich diese Punkte im Voraus prüfen, sodass Patch-Runden mit dem Shopware-Team minimal bleiben. Erfahrungswerte: ein gut vorbereiteter Plugin-Code geht in zwei bis vier Review-Runden durch, ein hastig zusammengestelltes Plugin braucht oft sechs bis acht Runden mit Wartezeiten dazwischen.
Performance-Aspekte bei Plugin-Code
Ein Plugin kann einen schnellen Shop ausbremsen, wenn es ungünstig in die Storefront eingreift. Klassiker: Datenbankabfragen im Twig-Template (jede Seite triggert N+1-Queries), Server-Side-Includes, die das ESI-Caching brechen, Event-Subscriber, die auf jeder Request-Phase laufen und Last erzeugen. Mein Ansatz bei Performance-kritischen Plugins: Datenzugriff über das offizielle Data-Abstraction-Layer mit Repositories, Caching über die Shopware-Cache-Mechanismen, Storefront-Erweiterungen so platziert, dass HTTP-Cache und ESI weiterhin sauber laufen. Vor der Live-Schaltung gehört ein Performance-Check zur Lieferung.
Verwandte Themen
Plugin-Entwicklung berührt häufig umliegende Disziplinen. Wenn das Plugin im Zuge eines Plattform-Wechsels entsteht, lohnt sich der Blick auf Shopware-Migration. Wenn der Plugin-Bedarf Teil eines laufenden Shop-Betriebs ist, passt eher Shopware-Freelancer. Bei Full-Service-Mandaten mit Konzept, Design, Entwicklung und Marketing aus einer Hand: Shopware-Agentur. Wer überhaupt erst entscheidet, ob Shopware der richtige Stack ist, findet einen Einstieg auf Online Shop erstellen lassen.
Wie die Zusammenarbeit konkret läuft
Plugin-Mandate laufen praktisch vollständig remote: Git-Repository mit klaren Branches pro Plugin-Feature, Pull-Request-Reviews als Abnahme-Stelle, Video-Calls für Konzept und Knackpunkte. Persönliche Termine in Münster oder beim Kunden vor Ort gehen, sind aber selten der Engpass. Die meisten Plugin-Auslieferungen über die letzten Jahre sind ohne ein einziges Vor-Ort-Treffen entstanden.
