Bei der Migration eines Shopware-5-Systems in eine containerisierte Umgebung zeigte sich ein Fehlerbild, das zunächst ungewöhnlich wirkte: Das Backend lud zwar, aber statt der üblichen Oberfläche erschien ein Shopware-Fehlerdialog, der den Benutzer vollständig blockierte. Dieser Fehlerdialog enthielt:
-
- die eigentliche Exception
- eine Response-Vorschau
- Browser- und Systeminformationen
Ein normales Arbeiten war nicht möglich.
Der folgende Beitrag dokumentiert detailliert die Analyse – vom Symptom über die Identifikation eines problematischen Drittanbieter-Plugins bis zur konkreten Codekorrektur in zwei Subscriber-Klassen des Plugins NetiFoundation (Vendor: Net Inventors GmbH).
Das Fehlerbild im Backend
Nach dem Backend-Login erschien nicht die übliche Shopware-Oberfläche, sondern unmittelbar ein modales Fenster:
-
- Titel: „Ein Fehler ist aufgetreten“
- Inhalt: ein vollständiger Stacktrace
- rechts: JSON-Response, Systeminfo, Benutzeragent
Ein Wegklicken war nicht möglich – das Backend blieb blockiert.
Der Fehler lautete:
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException:The "auth" service is synthetic, it needs to be set at boot time before it can be used.
Diese Meldung tritt auf, wenn ein Subscriber oder Service zu früh im Backend-Bootprozess einen Dienst abruft oder Templates erweitert, bevor Shopware selbst vollständig initialisiert wurde.
Erste Spurensuche und Ausschlussverfahren
Das Frontend funktionierte problemlos, sodass klar war:
-
-
- Routing funktioniert
- PHP-FPM funktioniert
- Nginx läuft sauber
- Shopware-Core-Dateien sind nicht beschädigt
-
Da jedoch ein ganzer Block an Fehlermeldungen im Backend geladen wurde, lag der Verdacht nahe, dass ein Plugin in den Backend-Renderprozess eingreift.
Radikaltest: alle Nicht-Shopware-Plugins deaktivieren
Ein klassischer Ansatz zur Eingrenzung:
UPDATE s_core_pluginsSET active = 0, capability_enable = 0WHERE namespace <> 'Shopware';
Nach Cache-Leerung:
→ Backend funktionierte sofort wieder – ohne Fehlerdialog.
Das machte klar: Ein Drittanbieter-Plugin verursacht die Blockade.
Anschließend wurden die Plugins stufenweise wieder aktiviert.
Das Ergebnis war eindeutig:
Übeltäter: NetiFoundation (Vendor: Net Inventors GmbH)
Sobald dieses Plugin aktiviert wurde:
- erscheint der Fehlerdialog wieder
- Icons im Backend fehlen teilweise (z. B. Menüicons)
- ExtJS-Elemente laden nicht vollständig
- Beim Initialisieren des Backends wird eine Exception ausgelöst
Feinanalyse: Welche Komponenten des Plugins verursachen die Exception?
Das Plugin enthält zahlreiche Symfony-Service-Definitionen sowie mehrere Event-Subscriber.
Durch sukzessives Entfernen/Deaktivieren der Subscriber zeigte sich: Problematisch waren zwei spezifische Subscriber:
1. Subscriber/Backend.php
2. Subscriber/Controller.php
Alle anderen Subscriber konnten aktiv bleiben, ohne Fehler auszulösen.
Fehlerursache 1: Falsche / veraltete Methode im Subscriber Controller
Codeauszug aus Subscriber/Controller.php:
$view->getTemplateDir();
Problem:
- In Shopware 5 Backend Views existiert diese Methode nicht (nie existiert oder nicht mehr verfügbar).
- Unter klassischem Linux/Apache wird dieser Fehler teilweise geschluckt.
- Unter Docker + PHP-FPM führt der Fehler zu einem sofortigen Fatal Error, der im Backend den Fehlerdialog triggert.
Lösung:
Die Zeile muss entfernt bzw. ersetzt werden.
Korrekt ist:
addTemplateDir(__DIR__ . '/../Views/', 'NetiFoundation_Controller'); ?>Die gesamte unzulässige Methode wurde entfernt.
Fehlerursache 2: Backend-Subscriber erweitert ein Template, dessen Pfad nicht registriert ist
In Subscriber/Backend.php stand:
getSubject()->View()->extendsTemplate('backend/foundation_menu_item.tpl'); ?>
Problem:
- Das Template existiert – aber Shopware kennt den Pfad nicht, da es vorher kein addTemplateDir() für das View-Verzeichnis gab.
- Dadurch versucht Smarty, das Template anhand bestehender Theme-Verzeichnisse zu finden → scheitert → Exception.
- In Folge blockiert der Shopware-Fehlerdialog das Backend.
Lösung:
Der Templatepfad muss vor dem Extend registriert werden:
templateManager->addTemplateDir( __DIR__ . '/../Views/', 'NetiFoundation_Backend' ); ?>
und erst dann das Extend:
getSubject()->View()->extendsTemplate('backend/foundation_menu_item.tpl'); ?>
Ergebnis nach beiden Korrekturen
Nach Durchführung der Fixes:
- Backend lädt ohne Fehlerdialog
- Menüicons erscheinen wieder korrekt
- ExtJS lädt vollständig
- PluginManager funktioniert
- Keine ServiceNotFound-Exceptions mehr
- Kein „synthetic service“ Fehler mehr
Das Plugin NetiFoundation ist nun voll kompatibel mit der Docker-/PHP-FPM-Umgebung.
Warum trat der Fehler nur in Docker auf?
Auf dem ursprünglichen Server lief alles problemlos – warum also der Fehler im Container?
Technische Ursachen:
-
PHP-FPM behandelt Fatal Errors strenger als Apache mod_php.
-
Einige PHP-Warnungen oder nicht existierende Methoden werden im Live-System durch Konfiguration oder Error-Handling unterdrückt.
-
Docker nutzt häufig modernere, restriktivere Defaults (z. B. display_errors=0, aber Logging hart).
-
Shopware zeigt Backend-Fehler immer als modales Error-Window an – weshalb kein Weiterklicken möglich war.
Fazit
Die Migration eines Systems offenbart oft „schlafende“ Fehler, die auf dem bisherigen Server nie sichtbar wurden. In diesem Fall:
- ein veralteter Methodenaufruf (getTemplateDir())
- ein fehlendes addTemplateDir() in einem Backend-Subscriber
führten dazu, dass das Plugin NetiFoundation den Backend-Renderprozess bereits in der Initialphase störte.
Durch gezielte Analyse und präzise Korrektur wurde das Problem vollständig gelöst.
Wenn Sie Unterstützung bei der Fehlersuche, Plugin-Optimierung oder der technischen Modernisierung Ihrer Shopware-Instanz benötigen, stehen wir Ihnen gerne zur Seite. Wir entwickeln, analysieren und stabilisieren komplexe E-Commerce-Systeme und sorgen dafür, dass Ihr Shop performant, sicher und zuverlässig läuft.
