Plugin-Fehler nach einem Shopware-Update: Ursache finden statt raten

Wenn nach einem Shopware-Update etwas nicht mehr läuft, lohnt zuerst der Blick auf die Plugins: solche, die vor dem Update funktioniert haben und danach nicht mehr — oder sich gar nicht erst installieren lassen. In unseren Tests hat Shopware dabei ziemlich genau gesagt, was los ist. Man muss nur wissen, wo.

Drei Fehlerbilder beschreiben wir hier. Die ersten beiden haben wir am 27.10.2026 in zwei Wegwerf-Shops nachgestellt, einem mit Shopware 6.6.10.6 und einem mit 6.7.2.2. Das dritte beschreiben wir aus eigener Erfahrung mit einer Testumgebung auf Shopware 6.7.13.1. Aktuell sind am 30.10.2026 die Versionen 6.7.15.1 und 6.6.10.30; die hier zitierten Meldungen und die Log-Konfiguration haben wir in deren Quelltext unverändert wiedergefunden.

Fehlerbild 1: Das Plugin lässt sich nicht installieren

Jedes Plugin nennt in seiner composer.json, für welche Shopware-Versionen es gedacht ist. Unser Testplugin verlangte "shopware/core": "~6.6.0" — also eine Version 6.6. In 6.6.10.6 ließ es sich problemlos installieren. In 6.7.2.2 brach die Installation ab:

Could not install plugin, got 1 failure(s).
Required plugin/package "shopware/core ~6.6.0" does not match installed version == 6.7.2.2.

Die Meldung nennt beides: was das Plugin verlangt und was installiert ist. Nach einem Wechsel der Hauptversion ist das ein typischer Grund, warum ein Plugin nicht mehr startet. Was eine solche Versionsangabe zusagt — und was nicht —, erklärt dieser Ratgeber.

Was hilft: eine Version des Plugins, die der Hersteller für die neue Shopware-Version freigibt. Die Grenze von Hand zu ändern, empfehlen wir nicht: Sie schützt davor, ungeprüften Code auf einer Version laufen zu lassen, in der sich Schnittstellen geändert haben.

Fehlerbild 2: Der Shop zeigt einen Fehler 500

Ein Plugin ist installiert, aber sein Code passt nicht mehr zum Kern — oder hat einen Fehler, der erst nach dem Update auftritt. Unser zweites Testplugin warf auf jeder Storefront-Seite absichtlich eine Ausnahme. Das Ergebnis war in beiden Versionen gleich:

• Besucher sehen nur „An Error Occurred: Internal Server Error“ — im Produktivmodus absichtlich ohne Details.
• Das Log unter var/log/prod-2026-10-27.log enthielt die eigentliche Meldung:

request.CRITICAL: Uncaught PHP Exception RuntimeException: "Pixup-Testfehler: absichtlich ausgeloest" at Fehler.php line 7

Die Zeile nennt die Art des Fehlers, die Meldung und den Dateinamen mit Zeilennummer. Den vollständigen Pfad enthält derselbe Logeintrag weiter hinten, in der Form at /…/Fehler.php:7. Liegt diese Datei unter custom/plugins/ oder unter vendor/ eines Herstellers, ist das ein starkes Indiz, aber noch kein Beweis: Die Fundstelle zeigt, wo der Fehler sichtbar wurde, nicht zwingend, wer ihn verursacht hat. Ein anderes Plugin kann zum Beispiel Daten verändert haben, an denen dieser Code dann scheitert. Erst die Gegenprobe unten macht aus dem Indiz einen Befund. Wie Sie das Log finden, die Zeile lesen und vor dem Weitergeben schwärzen, beschreibt der Ratgeber Shopware zeigt einen Fehler 500.

Gegenprobe: Nach dem Deaktivieren des Testplugins und dem Leeren des Caches antwortete der Shop wieder mit Status 200:

bin/console plugin:deactivate PixupNovFehler
bin/console cache:clear

PixupNovFehler ist der technische Name unseres Testplugins; bin/console plugin:list zeigt die Namen in Ihrem Shop.

Fehlerbild 3: Storefront ohne Styles, Administration leer

Nach einem Plugin-Update fehlen manchmal Styles und Skripte, oder die Administration bleibt beim Laden hängen. Dieses Fehlerbild haben wir nicht in den beiden Wegwerf-Shops nachgestellt. Mögliche Ursachen:

• Das Theme wurde nicht neu kompiliert. Beim Aktivieren und beim Aktualisieren eines Plugins kompiliert Shopware die Themes bei Bedarf selbst neu — außer der Befehl läuft mit --skip-asset-build, wie in manchen Deployment-Skripten. bin/console theme:compile baut Styles und Skripte der Storefront neu.
• Der Cache enthält noch alte Ausgaben. bin/console cache:clear leert ihn.
• Der Build der Administration ist abgebrochen. In einer eigenen Testumgebung mit Shopware 6.7.13.1 haben wir erlebt, dass dieser Build bei knappem Arbeitsspeicher abgebrochen wurde und eine leere Administration hinterließ, die im Ladekreis hängen blieb.

So grenzen Sie die Ursache ein

1. In einer Kopie arbeiten, nicht im laufenden Shop. Eine Testumgebung mit abgeschalteten Mails und Zahlungen genügt.
2. Plugins auflisten. bin/console plugin:list zeigt jedes Plugin mit technischem Namen, Version und ob es installiert und aktiv ist. Steht in der Spalte „Upgradeable“ ein „Yes“, liegt eine neuere Version bereit, die erst mit bin/console plugin:update <TechnischerName> eingespielt wird. Die Spalte zeigt den Stand der letzten Prüfung; neu hochgeladene Plugin-Dateien erkennt Shopware erst nach bin/console plugin:refresh.
3. Log lesen: die jüngste Datei unter var/log/, nach CRITICAL oder ERROR suchen. Die Zeitstempel stehen in UTC. Eine Fundstelle in einem Plugin ist ein Indiz, kein Beweis (siehe oben).
4. Plugins einzeln deaktivieren, nach jedem Schritt den Cache leeren und den Fehler erneut auslösen. Verschwindet der Fehler nach dem Deaktivieren eines Plugins, ist dieses Plugin verdächtig.
5. Gegenprobe machen: das verdächtige Plugin wieder aktivieren (bin/console plugin:activate <TechnischerName>, danach bin/console cache:clear). Kehrt der Fehler zurück, ist der Verursacher eingegrenzt. Kehrt er nicht zurück, war es etwas anderes, etwa ein Cache-Stand oder ein Zusammenspiel mehrerer Plugins.
6. Hersteller prüfen: Gibt es eine freigegebene Version? Wenn nicht, ist eine Anpassung oder ein Ersatz nötig.

Alle Befehle laufen im Hauptverzeichnis des Shops, also dort, wo der Ordner bin liegt, und mit dem Benutzer, unter dem auch der Webserver läuft. Ein Beispiel für Schritt 4, wieder mit unserem Testplugin:

bin/console plugin:list
bin/console plugin:deactivate PixupNovFehler
bin/console cache:clear

Zwei Dinge können das Ergebnis verfälschen. Hängt ein anderes Plugin vom deaktivierten ab, fällt dessen Funktion womöglich mit weg — dann verschwindet der Fehler, obwohl der eigentliche Verursacher das abhängige Plugin ist. Und das Deaktivieren hat selbst Nebeneffekte: Zahlungsarten, Versandberechnungen oder Schnittstellen eines Plugins stehen danach nicht mehr zur Verfügung. Deshalb gehört die Eingrenzung in eine Kopie, und jedes Ergebnis braucht die Gegenprobe.

Vorbeugen: vor dem Update prüfen

Viele dieser Fehler lassen sich vor dem Update finden: Plugin-Liste gegen die Freigaben der Hersteller prüfen, das Update zuerst in einer Kopie durchspielen, Testkäufe machen. Ob ein Wechsel auf 6.7 jetzt sinnvoll ist, beantwortet dieser Ratgeber.

Steht der Shop nach einem Update und kommt intern niemand an Konsole und Log heran, beschreibt unsere Seite zum Shopware Support, wie wir dabei unterstützen.

In unseren Tests nannte Shopware den Grund selbst — in der Konsole beim Installieren, im Log beim Fehler 500. Die Fundstelle ist ein Indiz; die Gegenprobe in einer Kopie macht daraus einen Befund.