Shopware Update endet mit Error 500: Ursachen und Lösungen
Nach einem Update zeigt der Shop nur noch einen 500-Fehler, im Frontend und in der Administration. Für Shopware 6.7 sind zwei Ursachen gut dokumentiert. Hier steht, woran Sie sie erkennen und was dagegen hilft.
Ein 500-Fehler nach einem Shopware-Update ist nur ein Symptom, die Ursache steht im Log. Bei Shopware 6.7 tauchen in der Praxis vor allem zwei Fälle auf: eine Datenbank-Migration, die auf MySQL 8.4 mitten im Update abbricht, und ein Twig-Fehler, der die Administration nach dem Update lahmlegt.
Die Seite erklärt beide Fälle mit den Fehlermeldungen, an denen Sie sie erkennen. Sie sagt auch offen, was in den Quellen bestätigt ist und was nicht. Bevor Sie am Live-System etwas ändern, sichern Sie die Datenbank und testen Sie jeden Schritt auf einer Kopie.
Zuerst: Ursache im Log finden
Ein allgemeiner 500-Fehler sagt nichts über die Ursache. Öffnen Sie zuerst die Logdateien im Verzeichnis var/log Ihres Shops und suchen Sie die Fehlermeldung zum Zeitpunkt des Updates. Der Text der Meldung entscheidet, welcher der folgenden Fälle vorliegt.
- Meldung mit „Cannot drop index“ und „needed in a foreign key constraint“ während „Migrated x out of y“: Fall 1, Migrationsfehler auf MySQL 8.4.
- Meldung „Return value must be of type string, Twig\Markup returned“ im Template der Administration: Fall 2, Twig-Fehler.
- Andere Meldungen: Notieren Sie Fehlertext, Shopware-, PHP- und Datenbankversion, bevor Sie etwas ändern. Das spart bei jeder Hilfe Zeit.
Fall 1: Migration bricht auf MySQL 8.4 ab
Im Forum wird ein Update von Shopware 6.7.6.2 auf 6.7.8.2 beschrieben, das mit einem 500-Fehler endet. Im Log steht, dass die Migration „Migration1763125891AddProductTypeColumn“ fehlgeschlagen ist, mit der Meldung „SQLSTATE[HY000]: General error: 1553 Cannot drop index '': needed in a foreign key constraint“. Die Migration fügt der Tabelle product eine Spalte type hinzu und legt dafür einen Index an. Ein weiterer Forenbeitrag nennt denselben Fehler beim Update von 6.7.8.2 auf 6.7.12.1, und im GitHub-Issue kam der Meldende von Version 6.6.10.8.
Danach ist der Shop häufig nicht mehr erreichbar, und im Log erscheint zusätzlich ein Fehler wie „Unknown column 'sales_channel_analytics.track_offcanvas_cart'“. Das ist die Folge einer nur halb durchgelaufenen Migration: Der neue Code ist bereits eingespielt, die Datenbank aber nicht vollständig angepasst.
Zur Ursache: Im zugehörigen GitHub-Issue (shopware/shopware #16240) beschreibt ein Beitrag einen Fremdschlüssel der Tabelle product mit einem falschen Namen, der aus früheren Migrationen übrig geblieben sei. Ein weiterer Beitrag verweist auf den MySQL-Bug 118151, der MySQL 8.4.5 und neuer betrifft. Die Shopware-Maintainer haben diese Erklärung auf der Seite nicht bestätigt. Das Issue wurde am 20. Mai 2026 als erledigt geschlossen und mit der Änderung #16658 verknüpft. In welcher Shopware-Version die Korrektur enthalten ist, steht dort nicht, prüfen Sie dazu die Release Notes der aktuellen 6.7-Version.
- 1Datenbank sichern oder Backup zurückspielenIst der Shop nach dem Abbruch nicht mehr erreichbar, ist das Zurückspielen des Backups aus der Zeit vor dem Update der sicherste Weg. Die Migration ist nur halb durchgelaufen, ein Reparieren am Live-System ist riskant.
- 2Update auf einer Kopie erneut versuchenSpielen Sie Datenbank und Code auf ein Staging-System und führen Sie das Update dort mit einem der beiden folgenden Wege aus.
- 3Weg A: MySQL-Einstellung vorübergehend ändernDer Shopware-Support empfahl in dem Forenfall, die Einstellung restrict_fk_on_non_standard_key global auf 0 zu setzen, damit das Update durchläuft. Im Issue wird sie als vorübergehende Maßnahme beschrieben. Setzen Sie den Wert nach dem Update wieder zurück. Ob das in jedem Fall funktioniert, ist in den Quellen nicht bestätigt.
- 4Weg B: Fremdschlüssel korrigierenIm Issue wird als zweiter Weg beschrieben, den falsch benannten Fremdschlüssel der Tabelle product durch einen korrekt benannten zu ersetzen und danach „bin/console system:update:finish“ auszuführen. Das ist ein Eingriff in die Datenbank und gehört nur auf eine Kopie oder unter Aufsicht eines Entwicklers.
- 5Aktuelle Patchversion prüfenAktualisieren Sie auf die neueste 6.7-Version und lesen Sie die Release Notes zu den Produkt-Migrationen und MySQL 8.4, bevor Sie am Live-System wiederholen.
[mysqld]
restrict_fk_on_non_standard_key=0Die Einstellung gilt für den gesamten MySQL-Server. Ändern Sie sie nur mit Rücksprache Ihres Hosters oder Administrators und nur für die Dauer des Updates.
Fall 2: Administration meldet 500, Twig-Fehler
Ein zweiter Fall betrifft die Administration. Nach einem Update von 6.7.8.2 auf 6.7.9.0 oder höher meldet sie einen 500-Fehler mit der Meldung „Return value must be of type string, Twig\Markup returned“ im Template „@Administration/administration/index.html.twig“.
Laut dem verknüpften GitHub-Issue liegt das an neueren Twig-Versionen: Ab Twig 3.26.0 liefert die Funktion include() ein Objekt vom Typ Twig\Markup statt eines Textes. Shopware deklariert für seine eigene Erweiterung einen strikten Rückgabetyp „string“, deshalb löst PHP einen Typfehler aus. Das passiere auch bei deaktivierten Plugins, weil schon das Kern-Template der Administration betroffen ist. Gemeldet wurde der Fehler für Shopware 6.7.11.1 mit Twig ab 3.26.0, reproduziert mit 3.28.0. Eine Forendiskussion nennt einen weiteren Bereich von 6.7.6.0 bis 6.7.11.1.
Eine offizielle Korrektur von Shopware war in den gelesenen Quellen nicht bestätigt, das Issue war noch nicht bearbeitet. Prüfen Sie deshalb, ob die Release Notes Ihrer Shopware-Version den Fehler inzwischen beheben.
- Twig auf eine Version unter 3.26.0 festlegen: Das hat laut Forum geholfen. Legen Sie dazu die Twig-Version in der composer.json fest und aktualisieren Sie das Paket auf einer Kopie.
- Rückgabewert in der Shopware-Datei per Hand in einen Text umwandeln: Das beseitigt den Fehler, wird aber bei jedem späteren Composer-Install oder -Update überschrieben und gehört nicht in einen Live-Shop.
Vor jedem Update: so vermeiden Sie den Ausfall
- Vollständiges Backup von Datenbank und Dateien erstellen und die Wiederherstellung einmal testen.
- Das Update zuerst auf einer Kopie des Live-Shops ausführen, mit derselben PHP-, MySQL- und Composer-Version wie im Live-System.
- Datenbankversion prüfen. Der Migrationsfehler wird im Zusammenhang mit MySQL 8.4 berichtet.
- Plugins vor dem Update auf Kompatibilität prüfen und in den Release Notes nach Hinweisen zu Ihrer Zielversion suchen.
- Nach dem Update Checkout, Zahlung und E-Mail-Versand mit einer Testbestellung durchspielen.
- Einen Rollback-Plan bereithalten, damit ein Abbruch mitten in den Migrationen nicht zum Ausfall führt.
Passende Leistungen und Leitfäden
Häufige Fragen zum Update-Fehler
Nein. Ein 500-Fehler nach dem Update bedeutet, dass der Shop oder die Administration nicht korrekt läuft. Bei einer abgebrochenen Migration ist die Datenbank nur teilweise angepasst, ein Weiterarbeiten kann Daten beschädigen. Sichern Sie zuerst und spielen Sie im Zweifel das Backup zurück.
Quellen
Stand: 24. Oktober 2026. Die Angaben beruhen auf öffentlichen Berichten und Issues und sind keine Garantie für Ihr System. Eingriffe in Datenbank und Serverkonfiguration sollten nur auf einer Kopie des Shops und mit vollständigem Backup erfolgen.
Update fehlgeschlagen oder noch geplant?
Schreiben Sie uns Ihre Shopware-, PHP- und MySQL-Version und die Fehlermeldung aus dem Log. Wir melden uns innerhalb eines Werktags.