Shopware Plugin Entwicklung

Ein Plugin ist bei uns kein Template-Override mit etwas PHP, sondern eine eigene Erweiterung mit klaren Grenzen. Typische Bausteine sind eigene Entities mit Migrationen, wenn euer Modell Daten braucht, die Shopware nicht kennt: Freigabe-Workflows, Kundenhierarchien, Projektpreise oder Konfigurationsdaten aus dem ERP. Dazu kommen Administration-Module in Vue.js, damit euer Team diese Daten selbst pflegen kann, ohne uns zu fragen.

Auf der Storefront-Seite ergänzen wir Twig-Komponenten, eigene Seiten und Checkout-Schritte, die sich in das bestehende Theme einfügen. Für Anbindungen nach außen entwickeln wir API-Endpunkte auf Basis der Store-API und der Admin-API, etwa für Punch-Out-Systeme, Preis-Engines oder Versanddienstleister. Wie wir größere Anbindungen aufbauen, zeigt die Seite Shopware-Schnittstellen.

Shopware Plugin Entwicklung ist dabei ein Teil unserer Shopware Entwicklung, kein isoliertes Angebot. Ein Plugin, das Preise berechnet, muss zum ERP-Abgleich passen, ein Freigabe-Workflow zum Checkout. Deshalb prüfen wir vor dem Bau, wo die Logik hingehört: in ein Plugin, in eine Schnittstelle oder in eine Konfiguration von Rule Builder und Flow Builder, die ganz ohne Code auskommt.

Shopware kennt zwei Wege, den Shop zu erweitern. Ein klassisches Plugin läuft innerhalb der Shopware-Instanz im Symfony-Kernel, hat direkten Zugriff auf Services und Datenbank und kann jeden Teil des Systems anpassen. Genau deshalb ist es nur in self-hosted Installationen möglich: In Shopware Cloud wird kein fremder Code im Prozess des Shops ausgeführt, klassische Plugins werden dort nicht unterstützt.

Eine App nach dem Shopware App-System läuft außerhalb der Shop-Instanz. Sie registriert sich über ein Manifest, wird per Webhooks über Ereignisse informiert und arbeitet über die Admin-API mit dem Shop. Der Code der App liegt auf einem eigenen Server, den ihr oder wir betreiben. Trotzdem kann eine App Admin-Module, eigene Entities, Custom Fields und Zahlungsarten mitbringen, und mit App-Scripts läuft synchrone Logik wie Warenkorb-Regeln in einer Sandbox direkt im Shop. Apps funktionieren in der Cloud und self-hosted, Plugins nur self-hosted.

Die Wahl hängt also zuerst vom Betriebsmodell ab. Wer Shopware Cloud nutzt oder sich den Wechsel offenhalten will, braucht eine App. Wer self-hosted bleibt und tief in Services, Checkout oder Datenmodell eingreifen muss, ist mit einem Plugin oft schneller und mit weniger Infrastruktur unterwegs. Wir bauen beides und sagen euch vorher, welcher Weg zu eurem Setup passt.

Am Anfang steht die Frage, ob ihr das Plugin überhaupt braucht. Wir prüfen, ob Rule Builder, Flow Builder oder ein vorhandenes Marketplace-Plugin die Anforderung schon abdecken. Erst wenn das nicht reicht, beschreiben wir den Umfang: welche Daten, welche Admin-Ansichten, welche Storefront-Elemente, welche Schnittstellen. Daraus entsteht eine Aufwandsschätzung, die Risiken benennt statt sie zu verstecken.

In der Umsetzung arbeiten wir in kurzen Iterationen, damit ihr früh seht, ob die Logik euer Modell wirklich trifft. Das Plugin entsteht in eurem Repository, jede Änderung geht durch ein Code-Review, und Unit- und Integration-Tests laufen in der Pipeline. Zwischenstände könnt ihr auf einer Staging-Umgebung mit euren echten Daten prüfen, bevor etwas in Richtung Live geht.

Der Release ist ein dokumentierter Schritt: Migrationen laufen kontrolliert, die Konfiguration ist beschrieben, README und Changelog liegen bei. Danach übernehmen wir auf Wunsch Wartung und Update-Tests, damit das Plugin auch mit dem nächsten Shopware-Release weiterläuft. Und weil der Code euch gehört, könnt ihr die Weiterentwicklung jederzeit selbst übernehmen.