App oder Plugin in Shopware
Eine App bekommt Schreib-Webhooks für 11 von 247 Entitäten. Die Zahl ist in 6.6 und 6.7 gleich — der Mechanismus dahinter nicht, und darauf kommt es an.
Die Frage wird meist mit Betriebsargumenten beantwortet: Apps laufen außerhalb, sind cloud-tauglich, brauchen keinen Code im Shop. Das stimmt und reicht nicht, weil es die eine Frage auslässt, an der Projekte scheitern: Kommt die App überhaupt an die Daten, um die es geht?
Dafür gibt es eine Zahl.
Die Zahl
| 6.6.10.6 | 6.7.13.1 | |
|---|---|---|
| DAL-Entitäten insgesamt | 228 | 247 |
| davon mit Schreib-Webhook für Apps | 11 | 11 |
| Business-Events (Flow-Auslöser) | 95 | 96 |
Die elf sind:
product · product_price · category · sales_channel ·
sales_channel_domain · customer · customer_address · order ·
order_address · document · media
Eine App erfährt also von Schreibvorgängen an den Kerndaten des Shops — und an nichts sonst. Keine Bestellposition, keine Zahlungstransaktion, kein Lieferstatus, keine Eigenschaft, kein Regelwerk, nichts aus einer anderen Erweiterung.
Der eigentliche Unterschied liegt nicht in der Zahl
In beiden Versionen sind es elf. Was sich geändert hat, ist der Weg dorthin:
| 6.6.10.6 | 6.7.13.1 | |
|---|---|---|
| Herkunft der Liste | feste Konstante im Kern | DI-Tag shopware.entity.hookable |
| von außen erweiterbar | nein | ja |
In 6.6 ist die Liste geschlossen. Wer eine zwölfte Entität braucht, kann nichts tun — außer den Kern zu ändern.
In 6.7 ist sie ein Tag. Eine Erweiterung kann ihre eigene Entität damit versehen, und die App bekommt Webhooks dafür.
Der Haken: Diesen Tag zu setzen braucht PHP-Code im Shop — also ein Plugin. Die Öffnung hilft damit nicht der App allein, sondern dem Gespann aus App und Plugin. Für eine reine Cloud-Installation ohne Plugins bleibt es bei elf.
Das ist die Nuance, die in dieser Entscheidung am häufigsten fehlt: Ab 6.7 lautet die Frage nicht mehr „App oder Plugin", sondern oft „App mit einem kleinen Plugin oder Plugin allein".
Was eine App sonst deklarieren kann
Die Webhooks sind nur ein Teil. Das App-Manifest kennt daneben unter anderem Verwaltungsmodule und Action Buttons, eigene Zahlungs- und Versandarten, Steuer-Anbieter, Regelbedingungen, Custom-Field-Sets, Cookie-Einträge, CMS-Bausteine, Storefront-Erweiterungen und Gateways für Checkout und Kontext.
Die App-Oberfläche ist also keineswegs schmal — sie ist nur deklarativ. Was im Manifest vorgesehen ist, geht; was nicht vorgesehen ist, geht nicht. Ein Plugin kennt diese Grenze nicht, weil es im selben Prozess läuft wie der Kern.
Die Entscheidung
| Frage | Antwort |
|---|---|
| Zielumgebung ist Shopware Cloud | App — Plugins sind dort nicht installierbar |
| Die Logik braucht Daten außerhalb der elf Entitäten | Plugin, oder App plus kleines Plugin ab 6.7 |
| Es geht um Zahlung, Versand, Steuern, Regelbedingungen | App genügt — dafür gibt es Manifest-Einträge |
| Die Logik muss synchron im Bestellprozess greifen | Plugin — ein Webhook ist asynchron |
| Der Dienst soll mehrere Shops bedienen | App — eine Instanz, viele Shops |
| Es gibt keinen Server für den Betrieb | Plugin — eine App braucht einen |
| Die Erweiterung soll in den Store | beides möglich; die Zielumgebung der Kunden entscheidet |
Die Zeile mit dem Bestellprozess wird am häufigsten unterschätzt. Webhooks sind asynchron. Was eine Bestellung verhindern oder vor dem Abschluss verändern soll, kann kein Webhook leisten. Was Shopware bei Webhooks selbst regelt — Wiederholungen, Abschaltung nach Fehlern —, steht in Webhooks in Shopware 6.
Was wir selbst tun
Pixup baut beides und verkauft Plugins im Shopware Store. Das ist der Grund, warum dieser Text keine Empfehlung für eine der beiden Seiten enthält: Wir würden uns damit selbst widersprechen.
Was wir in Projekten tatsächlich zuerst fragen, ist die eine Zeile oben — liegt die gebrauchte Entität auf der Elferliste. Fällt die Antwort nein aus und soll es ohne Code im Shop gehen, erübrigt sich der Rest der Tabelle.
Grenzen dieser Messung
Gezählt wurden die Entitäten mit Schreib-Webhook, die DAL-Entitäten und die Business-Events zweier Installationen, dazu die Deklarationsmöglichkeiten des Manifests. Nicht gemessen wurden Laufzeit, Zustellzuverlässigkeit oder Betriebsaufwand einer App im Vergleich zu einem Plugin — das sind eigene Fragen und brauchen einen laufenden Dienst, keinen Kernel-Dump.
Wenn Sie vor dieser Entscheidung stehen, gehört sie zu App- und Plugin-Entwicklung.
Häufige Fragen
- Für welche Entitäten bekommt eine App Schreib-Webhooks?
- Für elf: product, product_price, category, sales_channel, sales_channel_domain, customer, customer_address, order, order_address, document und media. Gemessen in 6.6.10.6 und 6.7.13.1, in beiden dieselbe Liste.
- Kann eine App eigene Entitäten hookbar machen?
- Nicht aus sich heraus. Ab 6.7 kann eine Erweiterung eine Entität über einen DI-Tag hookbar machen — das setzt aber ein Plugin voraus, weil es PHP-Code im Shop braucht.
- Läuft eine App im Shop?
- Nein, sie läuft auf einem eigenen Server und wird über Webhooks und die API angesprochen. Genau daraus folgen ihre Vorteile — kein Code im Shop, cloud-tauglich — und ihre Grenzen.
- Was ist mit Shopware Cloud?
- Dort sind Plugins nicht installierbar, Apps schon. Wenn Cloud die Zielumgebung ist, entfällt die Frage weitgehend — dann entscheidet nicht, was besser wäre, sondern was geht.