Shopware-Plugin:kaufen oderbauen lassen?

Ob Sie ein Shopware Plugin kaufen oder entwickeln lassen, hängt vor allem an einer Frage, nämlich ob die Erweiterung aus dem Store Ihren Ablauf abbildet oder ob Sie umgekehrt Ihren Ablauf an die Erweiterung anpassen müssten. Passt sie, ist die Store-Lösung meist der schnellere Weg. Läuft Ihr Shop in der Shopware Cloud als SaaS, ist die Auswahl ohnehin kleiner, denn dort gibt es nur Apps (Plugins werden laut Shopware nicht unterstützt). Und wer nur einmal viele Datensätze ändern muss, braucht oft gar keine Erweiterung, sondern ein geprüftes Skript über die Admin-API.

Nikolai Schöbel und Jeremias Burger

Co-Founder der Scalableloops GmbH. Nikolai Schöbel verantwortet Online-Marketing und KI-Strategie, Jeremias Burger die KI-Architektur. Beide bauen und schulen KI-Systeme im eigenen Agenturalltag.

Shopware App vs Plugin: Was ist der Unterschied?

Shopware 6 kennt zwei Arten von Erweiterungen, und der Unterschied zwischen ihnen ist vor allem einer des Ortes. Plugins laufen im Prozess des Shopware-Kerns, reagieren dort auf Ereignisse, führen eigenen Code aus und haben die Datenbank direkt im Zugriff. Apps bleiben außerhalb des Kerns, lassen sich über Webhooks von Ereignissen benachrichtigen und arbeiten über die Admin-API mit den Daten des Shops.

Aus diesem Aufbau folgen auch die Grenzen, die man kennen sollte: Eine App kann weder die Datenbankstruktur verändern noch interne Routen oder Konsolenbefehle anlegen. Im Gegenzug hängt sie weniger an der Shopware-Version und läuft in der Cloud genauso wie im selbst gehosteten Shop. Ganz ohne Logik im Shop bleibt sie übrigens nicht, denn seit Shopware 6.4.8.0 können Apps über sogenannte App Scripts auch Logik innerhalb von Shopware ausführen, allerdings in einer abgeschotteten Umgebung.

In der Praxis heißt das: Tauscht die Erweiterung Daten mit einem externen System aus, etwa mit Warenwirtschaft, PIM oder Versand, ist eine App oft die zukunftssichere Wahl. Greift sie dagegen tief in Checkout, Preisberechnung oder Datenmodell ein, landet man meist beim Plugin, vorausgesetzt, Ihr Shop lässt es zu.

Was kostet ein Store-Plugin, und was ein eigenes?

Seit dem 28. Dezember 2023 vermietet der Shopware Store Erweiterungen nur noch, monatlich oder jährlich; die frühere Kaufoption mit Update-Abo ist abgeschafft. Für Ihre Kalkulation heißt das vor allem eines: Läuft die Miete aus, verliert der Shop das Recht, die Erweiterung zu nutzen, und damit ist eine Store-Erweiterung ein laufender Posten, so lange, wie Sie die Funktion brauchen.

Ein eigenes Plugin kostet einmal die Entwicklung und danach die Wartung. Wie hoch das ausfällt, hängt weniger an der Zahl der Funktionen als an einer Handvoll Treiber, die Agenturen übereinstimmend nennen: fachliche Komplexität, die Zahl der beteiligten Systeme wie ERP oder CRM, eigene Oberflächen in Administration oder Storefront, Anforderungen an Performance und Sicherheit, der Testumfang und schließlich die Frage, wie flexibel sich die Lösung später erweitern lassen soll.

Kippen kann die Rechnung an einer Stelle. Müssen Sie eine Store-Erweiterung erst anpassen lassen, damit sie passt, zahlen Sie Miete und Anpassung, und die Anpassung hängt dann am Code eines Dritten, der nach dem nächsten Update des Anbieters schon anders aussehen kann. Seriös ist deshalb nur eine Schätzung nach Bauteilen, denn eine Pauschale ohne Aufteilung verrät Ihnen nicht, wofür Sie eigentlich bezahlen.

Wann reicht ein Skript über die Admin-API statt eines Plugins?

Nicht jede Aufgabe braucht dauerhaften Code im Shop. Shopware selbst beschreibt die Admin-API als Schnittstelle für Integrationen, Automatisierung, Datenabgleich sowie Importe und Exporte, mit Lese- und Schreibzugriff auf jede Entität. Für Massenänderungen gibt es obendrein den Sync-Endpunkt, der viele Datensätze in einer einzigen Anfrage anlegt oder aktualisiert.

Ein Beispiel aus unserer Arbeit für einen Kinderwagen-Hersteller: 23 Produktvarianten sollten eine EAN für Google Shopping bekommen. In der Oberfläche brach die Pflege nach zwei Einträgen mit einer Zeitüberschreitung ab, und der CSV-Import meldete Fehler. Die übrigen 21 haben wir deshalb über die Admin-API gesetzt und dabei zuerst den Bestand gelesen, dann nur das eine Zielfeld geschrieben und danach jeden Datensatz gegengeprüft. Ein Plugin brauchte es dafür nicht, und im Shop ist auch kein zusätzlicher Code zurückgeblieben, den jemand bei Updates pflegen müsste.

Wo also die Grenze liegt? Für einmalige oder seltene Änderungen, die man hinterher sauber gegenprüft, taugt ein Skript gut. Soll eine Regel dagegen dauerhaft bei jeder Bestellung greifen, hat sie in einem Skript nichts verloren und gehört in eine App oder ein Plugin.

Was gehört ins Briefing an einen Shopware-Entwickler?

Wie viel Aufwand ein Plugin macht und was am Ende herauskommt, entscheidet das Briefing stärker als die Wahl des Entwicklers. Ein Satz wie „wir brauchen eine Sonderlogik im Checkout“ reicht dafür nicht. Bevor die erste Schätzung kommt, sollte deshalb Folgendes auf dem Tisch liegen:

1. 01

   Ablauf

   Schritt 1

   Wer klickt was, in welcher Reihenfolge, mit welchen Daten, und was soll danach anders sein.

2. 02

   Regeln und Ausnahmen

   Schritt 2

   Wann greift die Logik, für welche Kundengruppen oder Produkte, welche Sonderfälle gibt es, was passiert bei Fehlern.

3. 03

   Beteiligte Systeme

   Schritt 3

   Warenwirtschaft, PIM, CRM, Versand: welche Daten fließen in welche Richtung, wie oft.

4. 04

   Hosting und Version

   Schritt 4

   Selbst gehostet, PaaS oder SaaS, aktuelle Shopware-Version, Plan. Das entscheidet zwischen Plugin und App.

5. 05

   Geprüfte Alternativen

   Schritt 5

   Welche Store-Erweiterungen Sie angesehen haben und woran sie scheitern.

6. 06

   Abnahme und Wartung

   Schritt 6

   Woran Sie erkennen, dass es funktioniert, und wer die Erweiterung bei Updates anpasst.