Shopware 6: Plugin oder App – wann nehme ich was?
Die richtige Erweiterungsstrategie
· René van Dinter
Plugin oder App? Beide führen zum Ziel, unterscheiden sich aber grundlegend. Eine Entscheidungshilfe aus der Praxis – mit klaren Faustregeln.
„Sollen wir das als Plugin oder als App bauen?" – diese Frage steht am Anfang fast jedes Shopware-6-Projekts. Anders als oft behauptet, ist die Antwort nicht „self-hosted vs. Cloud". Beide Wege überschneiden sich stark – entscheidend ist, was die Erweiterung tun muss.
Der eigentliche Unterschied: PHP im Core – oder nicht
Ein Plugin ist PHP-Code, der innerhalb von Shopware läuft: voller Zugriff auf den Service-Container, die Datenbank (DAL), eigene Entities, Decorators, Resolver und Event-Subscriber. Dafür braucht es Dateizugriff auf den Server.
Eine App erweitert Shopware von außen über das App-System: ein manifest.xml, Webhooks und die Admin-/Store-API. Es läuft kein PHP im Shop-Prozess – die Logik liegt auf einem externen App-Server (beliebige Sprache), den Shopware per HTTP anspricht.
| Kriterium | Plugin | App |
|---|---|---|
| Ausführung | PHP im Shopware-Prozess | externer App-Server (HTTP), beliebige Sprache |
| Core erweitern (Services, Decorators, Resolver) | ja | nein |
| Eigene DB-Tabellen / Entities (DAL) | ja | nein |
| Interne Routen & CLI-Commands | ja | nein |
| Themes, Custom Fields, Admin-Module, Webhooks, Payment | ja | ja |
| Self-hosted | ja | ja |
| Shopware Cloud (SaaS) | nein | ja |
Self-hosted ist kein Kriterium – Cloud schon
Ein weit verbreiteter Irrtum: „Apps sind nur für die Cloud". Falsch. Auf einer selbst gehosteten Shopware laufen beide gleichermaßen. Der Unterschied greift nur in eine Richtung:
- Shopware Cloud (SaaS): hier sind nur Apps erlaubt – Plugins (auch Theme-Plugins) laufen dort nicht.
- Self-hosted: freie Wahl zwischen Plugin und App.
Wer also nicht in der Cloud ist, entscheidet rein nach der Aufgabe – nicht nach dem Hosting.
Was beide können
Die Überschneidung ist größer, als viele denken. Über beide Wege lassen sich abbilden:
- Storefront-Design und Themes (Twig/SCSS)
- Admin-Module und Oberflächen
- Custom Fields
- Webhooks bzw. Flow-Builder-Aktionen
- Zahlungsarten
- Veröffentlichung im Shopware Store
Für viele klassische Storefront- und Admin-Anpassungen sind also beide gangbar.
Was nur ein Plugin kann
Sobald echte Core-Erweiterungen in PHP ins Spiel kommen, führt kein Weg am Plugin vorbei:
- eigene Services, Decorators und Resolver
- Änderungen am Datenbank-Schema und eigene Entities über die DAL
- interne Symfony-Routen und CLI-Commands
- alles, was PHP-Ausführung direkt im Shop-Prozess braucht
// Solche PHP-Logik im Core ist ausschließlich per Plugin möglich –
// hier ein Event-Subscriber, der in die Produktseite eingreift.
public static function getSubscribedEvents(): array
{
return [
ProductPageLoadedEvent::class => 'onProductPageLoaded',
];
}
Was für die App spricht
- Cloud-Kompatibilität (Pflicht, wenn der Shop in der SaaS läuft)
- saubere Entkopplung: Shop-Updates brechen die App seltener
- Anbindung externer Dienste in beliebiger Sprache, sandboxed
Faustregel
- Brauchst du PHP im Core – Resolver, eigene Services, DB-Schema, CLI? → Plugin.
- Muss es in der Cloud laufen oder bewusst extern/entkoppelt sein? → App.
- Reine Storefront-/Admin-Anpassung (Theme, Custom Fields, Templates)? → beides möglich; entscheide nach Betrieb und Verteilung.
Fazit
Plugin oder App ist keine Glaubensfrage und schon gar keine reine Hosting-Frage. Wer sich ehrlich fragt, ob PHP im Core nötig ist und wo der Shop läuft, hat die Antwort meist schon in der Hand – und erspart sich später teure Umbauten.