Eine Shopware Integration ließ sich auf „Administrator“ setzen, der Speichern-Dialog bestätigte es, doch nach dem Reload war die Berechtigung weg – es hatte nicht geklappt. Diese Geschichte ist ein klassisches Debugging-Epos mit langen Sackgassen, methodischer Detektivarbeit und einem echten Happy End. Wenn du selbst in einer ähnlichen Situation steckst – ein Shopware Integration Administrator Fehler, bei dem eine Einstellung speichern will, aber nicht speichert – dann lies weiter.
1. Das Symptom – Shopware Integration Administrator Fehler
Ausgangslage ist einfach: Im Shopware-Admin unter Einstellungen → Integrationen wollen wir einer Integration das Häkchen „Administrator“ geben. Der Prozess sieht tadellos aus:
- Shopware Integration auswählen, das Häkchen bei „Administrator“ setzen
- Auf „Änderungen speichern“ klicken
- Die Speicherung wird bestätigt
- Alles sieht gut aus
Dann kommt der Reload. Und das Häkchen ist weg. Die Integration hat keine Administrator-Rechte. Es gibt keinen Error, keine Warnung, nichts in der UI, das auf ein Problem hindeutet – nur das stille Verschwinden der Änderung.
Das ist die fieseste Sorte Shopware Integration Administrator Fehler: Die UI bestätigt die Änderung – aber tatsächlich wurde nichts geschrieben. Keine Fehlermeldung, keine rote Box, nichts. Der Bug versteckt sich hinter einer Operation, die bestätigt wird, obwohl sie nicht funktioniert.
Shopware Integration Administrator Fehler – zurück zur Übersicht
2. Shopware Debugging: Admin-Worker und die große Nebenbaustelle
Der erste Verdacht fiel auf den Admin-Worker. In den Logs tauchte im 10-Sekunden-Takt eine MessageQueueException auf – sinngemäß „ein anderer Worker läuft bereits für den Receiver: async“. Das roch nach einer kaputten Message-Queue, die Schreibvorgänge verschluckt.
Shopware Admin-Worker – Lösung mit drei Stolpersteinen
Also haben wir den Admin-Worker serverseitig abgeschaltet und stattdessen auf echte CLI-Worker per Cronjob umgestellt. Das war ein größerer Umbau – und dabei traten gleich drei klassische Fehlerquellen auf, an denen man leicht scheitern kann:
- Falscher Dateiname: Die YAML hieß zuerst
shopware-z.yamlstattz-shopware.yaml. In Shopware lädt die Config alphabetisch, und dasz-Präfix sorgt dafür, dass die Datei zuletzt greift und alles andere überschreibt. Mit falschem Namen passierte gar nichts. - Falsche Einrückung: Danach war die Einrückung 2 statt 4 Leerzeichen. YAML ist da gnadenlos – die Datei wurde geparst, aber die Werte landeten in der falschen Verschachtelungstiefe und damit ins Leere.
- Vergessener Cache: Und selbst als Name und Einrückung stimmten, griff es erst nach
cache:clear. Vorher servierte Shopware die gecachte alte Konfiguration.
Erst nachdem alle drei Dinge saßen, bestätigte das System enableAdminWorker: false. Saubere Lösung. Und – der entscheidende Punkt – es hat für den eigentlichen Bug exakt nichts gebracht. Der Save schrieb weiterhin nicht. Damit hatten wir aber unseren handfesten Negativbeweis: Es lag nicht am Worker.
Shopware Integration Administrator Fehler – zurück zur Übersicht
3. Shopware Commercial-Plugin – ausgeschlossen
Nächste Theorie: Der Quellshop, in dem die Integration „ganz easy“ Administrator werden konnte, lief mit dem SwagCommercial-Stack. Der Zielshop nicht. Vielleicht koppelt Commercial irgendeine Berechtigungslogik?
Klang plausibel. War falsch. Gegentest auf einer lokalen Installation ganz ohne Commercial-Plugin: Dort ließ sich der Administrator-Status einwandfrei setzen und speichern. Damit war Commercial raus – ein schneller Negativbeweis, aber ein wichtiger.
Shopware Integration Administrator Fehler – zurück zur Übersicht
4. Build-Drift und Rebuild – eine aufschlussreiche Sackgasse
Verdacht: Das Administration-Bundle auf dem Server war fehlerhaft gebaut oder veraltet. Also: Kompletter Rebuild der Administration (build-administration.sh, assets:install, cache:clear).
Ergebnis: Der Bundle-Hash war byte-identisch zu vorher. administration-CNzdiowZ.js – gleiche Datei. Kein Build-Drift. Der Bug blieb.
Wieder eine Sackgasse – aber eine, die im Nachhinein extrem aufschlussreich war. Dieser Rebuild-Test sollte sich später beim Happy End als der entscheidende Hinweis erweisen.
Shopware Integration Administrator Fehler – zurück zur Übersicht
5. ACL, Rollen und Plugin-Overrides – alles OK
Man hätte das Problem „lösen“ können, indem man der Integration einfach eine ACL-Rolle mit allen Rechten zuweist, statt das admin-Flag zu nutzen. Das wurde bewusst verworfen: Das ist ein Workaround, kein Fix. Wir wollten die echte Ursache finden.
Zur Sicherheit dennoch geprüft:
- Der eingeloggte User hatte
isAdmin() = true can('admin') = truecan('integration.editor') = true- Es fehlten also keine Rechte
Außerdem tauchte in den Logs ein [GreatAdvancedAdmin]-Plugin auf. Verdacht: Überschreibt das die Integrations-Komponente? Prüfung der overrideRegistry für sw-integration-list: 0 Overrides. Das GreatAdvancedAdmin-Bundle fasst den Save-Vorgang nirgends an. Auch das war’s nicht.
Shopware Integration Administrator Fehler – zurück zur Übersicht
6. Was wir bewiesen haben: Das Frontend blockt
Der entscheidende Test war ein Request-Interceptor auf dem HTTP-Client der Administration, kombiniert mit einem echten Klick auf „Speichern“:
Shopware Quellshop (funktionierte):
Beim UI-Save ging ein sauberer PATCH integration/{id} {admin:true} raus. So soll es sein.
Shopware Zielshop (der Patient):
Beim identischen UI-Save fing der Interceptor … nichts ab. Kein PATCH, kein POST, kein JavaScript-Fehler. Einfach gar kein Schreibrequest.
Datenbank-Bestätigung:
Bestätigt wurde das per Adminer (zwischendurch installiert): Die Test-Integration great4gether hatte admin = 0 und – der Knaller – updated_at = NULL. Das bedeutet: Die UI hatte noch nie auf dieses Objekt geschrieben, obwohl wir mehrfach „gespeichert“ hatten.
Zwischenstand der Diagnose: Backend, API, Datenbank, ACL – alles funktionierte. Das Problem saß im Administration-Frontend: Der Save-Button löste keinen Schreibrequest für das admin-Feld aus. Der grüne Toast kam trotzdem, weil die UI den (vermeintlichen) Erfolg meldete, ohne dass je etwas rausging.
Shopware Integration Administrator Fehler – zurück zur Übersicht
7. Das Happy End – Update + Hard-Reload
An diesem Punkt kam die pragmatische Entscheidung, die sich als goldrichtig herausstellte: Update auf Shopware 6.7.11.0.
Nach dem Update war das Problem sofort behoben. Der UI-Save schreib jetzt tadellos, mit einem korrekten PATCH integration/{id} {admin:true} Request. Nach dem Reload blieb der Administrator-Status erhalten. ✓
Aber es gab noch ein interessantes Nebenprodukt des Updates: Die Integrations-Liste wurde plötzlich viel länger. Vorher waren da nur zwei Einträge (die manuell angelegten Integrationen), danach erschienen auf einmal 6–7–8 weitere hellgraue Einträge, die durch andere Apps (Plugins, Extensions) automatisch gesteuert wurden. Diese Integrationen waren vorher schlicht unsichtbar – oder besser: versteckt in der 6.7.10.1-Version.
Das Update brachte also nicht nur den Save-Bug zu Fall, sondern machte auch versteckte Integrations-Informationen wieder sichtbar.
Alternative: Workaround über API oder Datenbank (falls Update nicht infrage kommt)
Nicht jeder kann oder will sofort ein Shopware-Update fahren. Falls du mit dem Debugging-Ergebnis zufrieden bist und einfach nur möchtest, dass der Administrator-Schalter bleibt, wo er ist, gibt es zwei schnelle Workarounds:
Workaround 1: Über die Shopware Admin API
Ein einfacher API-Request setzt die Integration direkt auf Administrator, ohne dass die UI-Bug zuschlägt:
PATCH /api/integration/{integration-id}
Mit dem Body:
{"admin": true}
Danach bleibt der Wert erhalten – weil die API nicht den UI-Bug hat. Der Admin-Schalter wird daraufhin in der UI korrekt angezeigt und bleibt nach dem Reload bestehen.
Wie man den API-Request abfeuert – drei Optionen:
- Option 1: Mit Postman oder Bruno (einfach, visuell): Installiere Postman oder das Open-Source-Tool Bruno. Dort erstellst du eine neue Request mit der Methode PATCH, der URL
https://dein-shop.de/api/integration/{integration-id}, setzt im HeaderAuthorization: Bearer {API-Token}, und im Body{"admin": true}. Sendest ab – fertig. - Option 2: Mit curl über SSH (schnell, Terminal): Falls du SSH-Zugang hast, nutzt du den curl-Befehl:
curl -X PATCH https://dein-shop.de/api/integration/{id} -H "Authorization: Bearer {token}" -H "Content-Type: application/json" -d '{"admin": true}' - Option 3: Swagger UI im Shopware Admin (falls aktiviert): Manche Shopware-Installationen haben unter
/api/_info/swagger.htmleine grafische API-Dokumentation. Dort kannst du die Integration direkt im Browser anpassen – saubere Lösung, wenn verfügbar.
Den API-Token findest du: Im Shopware Admin unter Einstellungen → Integrationen, bei der Integration selbst. Dort ist der „Zugangsschlüssel“ oder „Secret Key“ hinterlegt – den brauchst du für die Authentifizierung.
Workaround 2: Direkt über die Datenbank
Falls du direkten Datenbank-Zugriff hast (z.B. via phpMyAdmin oder Adminer), kannst du auch manuell in der Tabelle integration das Feld admin auf 1 setzen:
UPDATE integration SET admin = 1 WHERE id = '{integration-id}';
Danach Cache leeren (cache:clear) und die Integration in der UI neu laden. Der Administrator-Status bleibt jetzt persistent.
Wichtig: Beide Workarounds beheben das Symptom, nicht die Ursache. Sie sind eine pragmatische Lösung, wenn das Update nicht sofort möglich ist. Die echte Lösung bleibt: Shopware auf 6.7.11.0 oder höher updaten.
Shopware Integration Administrator Fehler – zurück zur Übersicht
8. Lernpunkte und Takeaways
Diese Debugging-Odyssee hat mehrere wichtige Lektionen hinterlassen:
1. Negativbeweise sind wertvoll
Zu zeigen, was nicht das Problem ist, ist genauso wichtig wie zu finden, was es ist. Der Worker-Umbau, die Shopware Commercial-Prüfung, die ACL-Checks – all das führte nirgendhin, half aber, das Rätsel einzukreisen und den Fehler letztlich ins Frontend zu isolieren.
2. Systematisch vorgehen zahlt sich aus
Jede getestete Hypothese (auch die falschen) brachte uns näher zur echten Ursache. Methodische Detektivarbeit bei Shopware Integration-Problemen ist manchmal langsamer, führt aber sicherer zum Ziel als wildes Herumdoktern.
3. Shopware Request-Interceptoren und Netzwerk-Tabs retten Leben
Zu sehen, welche (oder welche nicht) Requests tatsächlich rausgehen, ist oft schneller als hundert Log-Zeilen zu lesen.
4. Die Shopware API direkt testen
Ein direkter PATCH /api/integration/{id} zeigte, dass die Backend-Seite tadellos funktioniert. Das half, die Fehlerquelle schnell auf das Frontend zu isolieren.
5. Shopware Versions-Updates als Lösung nutzen
Wenn ein Bug in der Debugging-Session nicht dingfest zu machen ist, aber alle Teile einzeln funktionieren, lohnt sich ein Shopware-Update – das bringt oft frischen Code und kann versteckte Bugs einfach mitnehmen. Bonus: Updates können auch Darstellungs- und Filter-Bugs aufdecken, die vorher unsichtbar waren. Nach unserem Update erschienen plötzlich 6–7 weitere Integrationen in der Liste, die vorher versteckt waren.
Shopware Integration Administrator Fehler – zurück zur Übersicht
