Events, Subscriber und Decorators in Shopware 6: Das Erweiterungs-Trio, das du kennen musst

1. Warum „einfach überschreiben" keine Option ist

In Shopware 5 war es verbreitet, Klassen direkt per extend zu übernehmen oder Methoden im Template mit {% block %}-Overrides zu modifizieren. Das Problem: Zwei Plugins, die dieselbe Methode überschreiben, sind inkompatibel. Shopware 6 löst das durch eine konsequente Architektur, die auf Symfony-Patterns aufbaut. Der Einstiegspunkt ist das Event-System.

2. Events und Subscriber: Reagieren ohne einzugreifen

Shopware feuert an hunderten Stellen im Kern eigene Events — beim Anlegen einer Bestellung, beim Laden von Produkten, vor und nach dem Checkout. Ein Event Subscriber lauscht auf diese Ereignisse, ohne den auslösenden Code zu berühren. Mehrere Subscriber auf demselben Event arbeiten parallel, nicht gegeneinander.

use Shopware\Core\Checkout\Cart\Event\CheckoutOrderPlacedEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class OrderPlacedSubscriber implements EventSubscriberInterface
{
    public static function getSubscribedEvents(): array
    {
        return [
            CheckoutOrderPlacedEvent::class => 'onOrderPlaced',
        ];
    }

    public function onOrderPlaced(CheckoutOrderPlacedEvent $event): void
    {
        $order = $event->getOrder();
        // eigene Logik — z.B. externe API benachrichtigen
    }
}

In der services.xml reicht ein Tag, damit Symfony den Subscriber automatisch registriert:

<service id="MyPlugin\Subscriber\OrderPlacedSubscriber">
    <tag name="kernel.event_subscriber"/>
</service>

Für die meisten Anwendungsfälle — E-Mails versenden, Logs schreiben, externe Systeme triggern — reicht ein Subscriber vollständig aus. Er verändert keine Daten, er reagiert nur.

3. Flow Events: Wenn Geschäftslogik in die Hand des Shop-Betreibers gehört

Seit Shopware 6.4 gibt es einen zweiten, oft unterschätzten Weg: eigene Events als Flow-Builder-Aktionen oder -Trigger registrieren. Statt die Logik hart im PHP zu verdrahten, kannst du ein Custom Event feuern und dem Shop-Betreiber überlassen, was damit passiert — E-Mail, Webhook, Tag setzen. Das macht Plugins deutlich flexibler und reduziert Support-Anfragen, weil der Betreiber selbst konfigurieren kann.

Der technische Aufwand ist überschaubar: Ein eigenes Event-Objekt, das FlowEventAware implementiert, ein BusinessEventCollector-Subscriber, der das Event registriert — und es taucht im Flow Builder auf.

4. Das Decorator Pattern: Kernlogik ändern, ohne sie zu brechen

Manchmal reicht Reagieren nicht. Du musst in einen Service eingreifen — zum Beispiel die Ergebnisse einer Produktsuche filtern oder die Preisberechnung um eine eigene Regel erweitern. Hier kommt der Decorator ins Spiel: Du wickelst den Original-Service in eine eigene Klasse und kannst Methoden vorher oder nachher beeinflussen, ohne die Originalklasse zu verändern.

class ProductListingDecorator implements ProductListingLoaderInterface
{
    public function __construct(
        private readonly ProductListingLoaderInterface $inner
    ) {}

    public function load(
        Criteria $criteria,
        SalesChannelContext $context
    ): EntitySearchResult {
        // vor dem Original-Aufruf: Criteria modifizieren
        $criteria->addFilter(new EqualsFilter('active', true));

        $result = $this->inner->load($criteria, $context);

        // nach dem Aufruf: Ergebnis nachbearbeiten
        return $result;
    }
}

In der services.xml wird der Decorator über das decorates-Attribut registriert. Symfony ersetzt automatisch den Original-Service im Container und injiziert ihn als $inner. Mehrere Decorators auf demselben Service stapeln sich in einer Kette — update-sicher, weil jeder nur das Interface berührt, nicht die Implementierung.

5. Wann welcher Ansatz?

• Event SubscriberReagieren auf Systemereignisse ohne Eingriff in die Daten-Pipeline. Ideal für Benachrichtigungen, Logging, externe Integrationen. Mehrere Subscriber auf demselben Event stören sich nicht.
• Flow Builder EventWenn die Reaktion auf ein Ereignis konfigurierbar sein soll — ohne dass der Betreiber PHP anfassen muss. Skaliert besonders gut in produktiven Plugin-Szenarien.
• DecoratorWenn du aktiv in die Logik eines Services eingreifen musst — Criteria erweitern, Rückgabewerte transformieren, Validierungen vorschalten. Einzige saubere Alternative zum direkten Fork.

6. Praxisfehler, die man nur einmal macht

Zwei Muster, die in fast jedem Review auftauchen: Erstens der Subscriber, der den EntityRepository direkt injiziert und bei jedem Event eine Datenbankabfrage auslöst — auch wenn sie gar nicht nötig ist. Das fällt erst unter Last auf. Die Lösung: früh prüfen, ob der Subscriber überhaupt handeln muss, und unnötige Queries mit einem Guard-Clause vermeiden.

Zweitens der Decorator, der nicht das Interface, sondern die konkrete Klasse als Typ-Hint nutzt. Das funktioniert, bis eine andere Shopware-Version die Implementierung umbaut — dann bricht der Type-Check. Immer gegen das Interface dekorieren, nie gegen die Klasse.

7. Fazit: Erweiterbarkeit ist Architektur

Shopware 6 macht es leicht, das System zu erweitern — wenn man die Mechanismen kennt. Events halten Seiteneffekte lose gekoppelt. Decorators ermöglichen echten Eingriff in die Logik, ohne Originalcode zu forkten. Wer beide Muster sauber einsetzt, schreibt Plugins, die Shopware-Updates überstehen und mit anderen Plugins koexistieren, ohne in einer Kompatibilitätsmatrix zu enden.