Shopware Problemlösung

Shopware Update fehlgeschlagen

Das Shopware-Update bricht ab, die Administration bleibt im Wartungsmodus oder der Shop zeigt nach dem Update Fehler. Diese Anleitung zeigt, wie Systemanforderungen, Erweiterungen, Composer, Migrationen, Cache und Logs systematisch geprüft werden.

Fehlerbild

Update bricht ab, Shop bleibt im Wartungsmodus oder Frontend und Administration funktionieren danach nicht korrekt.

Häufige Ursache

Inkompatible Erweiterung, unpassende PHP-Version, Composer-Konflikt, fehlgeschlagene Migration oder unvollständiger Codebestand.

Wichtig

Keine Migrationen ausführen, solange der bereitgestellte Code nicht eindeutig zur vorgesehenen Shopware-Version passt.

Inhaltsverzeichnis

  1. Fehlerbild eingrenzen
  2. Backup und Testsystem prüfen
  3. Versionen und Systemanforderungen prüfen
  4. Erweiterungen kontrollieren
  5. Composer-Fehler analysieren
  6. Wartungsmodus kontrollieren
  7. Update vorbereiten
  8. Migrationen abschließen
  9. Cache und Container neu aufbauen
  10. Logs auswerten
  11. Rollback richtig entscheiden
  12. Shop vollständig testen
  13. Abschlusskontrolle

1. Fehlerbild genau eingrenzen

Vor weiteren Befehlen muss geklärt werden, an welcher Stelle das Update abgebrochen ist. Ein Composer-Konflikt benötigt eine andere Behandlung als eine fehlgeschlagene Datenbankmigration.

  • Ist das Update in der Administration oder über die CLI gestartet worden?
  • Wurde der neue Code vollständig bereitgestellt?
  • Ist Composer bereits erfolgreich durchgelaufen?
  • Ist system:update:prepare abgeschlossen?
  • Ist system:update:finish fehlgeschlagen?
  • Ist nur das Frontend betroffen oder auch die Administration?
  • Bleibt der Shop im Wartungsmodus?
  • Gibt es eine konkrete Exception im Browser oder Terminal?
  • Trat der Fehler nach Aktivierung einer Erweiterung auf?
Fehlermeldung vollständig sichern

Die erste Exception ist meist aussagekräftiger als spätere Folgefehler. Terminalausgabe, Zeitpunkt, Zielversion und letzte erfolgreiche Ausführung dokumentieren.

2. Backup und Wiederherstellungsweg prüfen

Vor jeder weiteren Änderung muss feststehen, ob ein vollständiges und wiederherstellbares Backup vorhanden ist. Shopware erstellt dieses Backup nicht automatisch.

  • Datenbank-Backup vor dem Update vorhanden
  • Datei-Backup vor dem Update vorhanden
  • composer.json und composer.lock gesichert
  • Version des Backups dokumentiert
  • Wiederherstellungsweg getestet oder eindeutig bekannt
  • Aktuelle Bestellungen seit dem Backup berücksichtigt
Kein unkontrollierter Rollback der Datenbank

Ein älteres Datenbank-Backup kann neue Bestellungen, Kunden oder Zahlungen überschreiben. Vor einer Wiederherstellung muss die zwischenzeitlich entstandene Geschäftsdatenlage geprüft werden.

3. Shopware-, PHP- und Datenbankversion prüfen

Installierte Shopware-Version anzeigen

Shopware CLI
bin/console --version
Mit festem PHP-Pfad
/usr/bin/php bin/console --version

CLI-PHP-Version kontrollieren

Shell
/usr/bin/php -v

Datenbankversion anzeigen

MySQL oder MariaDB
mysql --version
Web-PHP und CLI-PHP können abweichen

Die Website kann mit einer anderen PHP-Version laufen als Composer und die Shopware-Konsole. Für das Update müssen beide Umgebungen zur Zielversion passen.

Bei einem Wechsel auf eine neue Hauptversion müssen zusätzlich deren eigene Update-Hinweise geprüft werden. Shopware 6.7 benötigt beispielsweise PHP 8.2, 8.3 oder 8.4 sowie aktuelle Datenbankversionen.

4. Erweiterungen und Themes kontrollieren

Inkompatible Plugins, Apps oder Themes gehören zu den häufigsten Ursachen für abgebrochene Updates. Vor einem Eingriff muss festgestellt werden, welche Erweiterung die Zielversion blockiert.

Installierte Erweiterungen anzeigen

Shopware CLI
bin/console plugin:list

Plugin-Dateien neu einlesen

Shopware CLI
bin/console plugin:refresh
  • Ist die Erweiterung ausdrücklich für die Zielversion freigegeben?
  • Gibt es eine neuere kompatible Version?
  • Verändert die Erweiterung Administration, Storefront oder Datenbank?
  • Wurde sie über Composer oder manuell installiert?
  • Gibt es individuelle Plugins ohne offiziellen Kompatibilitätseintrag?
  • Ist das aktive Theme für die Zielversion geeignet?
Nicht pauschal im Live-Shop deaktivieren

Eine Erweiterung kann Zahlungsarten, Versand, Checkout oder Datenstrukturen bereitstellen. Vor der Deaktivierung Auswirkungen, Datenbestand und Wiederaktivierung prüfen.

5. Composer-Konflikte analysieren

Bei Composer-basierten Installationen entscheidet Composer, ob die Abhängigkeiten der Zielversion gemeinsam installiert werden können.

Composer-Version prüfen

Shell
composer --version

Projektdatei validieren

Composer
composer validate

Blockierende Abhängigkeit ermitteln

Composer
composer why-not shopware/core ZIELVERSION

ZIELVERSION muss durch die konkrete Shopware-Version ersetzt werden.

Abhängigkeiten ohne automatische Scripts aktualisieren

Composer
composer update --no-scripts
composer.lock nicht ungeprüft löschen

Das Löschen der Lock-Datei kann zahlreiche Paketversionen gleichzeitig verändern und die Fehlersuche erschweren. Konflikt zuerst mit Composer-Ausgabe und why-not nachvollziehen.

6. Wartungsmodus kontrollieren

Alle Verkaufskanäle in Wartung setzen

Shopware CLI
bin/console sales-channel:maintenance:enable --all
Mit festem PHP-Pfad
/usr/bin/php bin/console sales-channel:maintenance:enable --all

Wartungsmodus nach erfolgreicher Prüfung beenden

Shopware CLI
bin/console sales-channel:maintenance:disable --all
Nicht zu früh deaktivieren

Der Wartungsmodus sollte erst beendet werden, wenn Migrationen, Cache-Aufbau, Administration, Storefront und Checkout geprüft sind.

7. Update mit system:update:prepare vorbereiten

Dieser Befehl löst vorbereitende Update-Ereignisse aus. Er sollte nur verwendet werden, wenn Zielversion, Codebestand und Erweiterungen eindeutig feststehen.

Shopware CLI
bin/console system:update:prepare
Mit festem PHP-Pfad
/usr/bin/php bin/console system:update:prepare
Code und Datenbank nicht vermischen

Dieser Schritt gehört in einen kontrollierten Updateablauf. Keine Befehle ausführen, wenn unklar ist, ob bereits alter und neuer Shopware-Code miteinander vermischt wurden.

8. Update und Migrationen abschließen

Nach dem erfolgreichen Bereitstellen des aktualisierten Codes führt Shopware mit system:update:finish die notwendigen Update-Skripte und Datenbankmigrationen aus.

Shopware CLI
bin/console system:update:finish
Mit festem PHP-Pfad
/usr/bin/php bin/console system:update:finish

Migrationen separat anzeigen

Shopware CLI
bin/console database:migrate --all
Migrationen nicht wiederholt erzwingen

Schlägt eine Migration fehl, zuerst die konkrete Exception und den Datenbankzustand prüfen. Wiederholte Aufrufe ohne Ursachenanalyse können Folgefehler erzeugen.

9. Cache und Container neu aufbauen

Shopware-Cache leeren

Shopware CLI
bin/console cache:clear
Mit festem PHP-Pfad
/usr/bin/php bin/console cache:clear

Theme nur bei Storefront-Problemen neu kompilieren

Shopware CLI
bin/console theme:compile
Cache-Fehler von Codefehlern unterscheiden

Ein Cache-Aufbau kann veraltete Containerdateien beseitigen. Eine fehlende PHP-Klasse, ein Composer-Konflikt oder eine fehlerhafte Migration wird dadurch nicht behoben.

10. Shopware-, PHP- und Webserver-Logs auswerten

Shopware-Logs anzeigen

Shell
ls -lah var/log/

Aktuelle Produktionseinträge lesen

Shell
tail -n 250 var/log/prod-*.log

Nach typischen Updatefehlern suchen

Shell
grep -RiE "update|migration|composer|plugin|exception|fatal|memory|timeout|class not found" var/log/ | tail -n 300
Fehlerhinweis Mögliche Ursache
Class not found Unvollständiger Codebestand, Autoloader oder inkompatible Erweiterung
SQLSTATE oder Migration failed Datenbankmigration, Schema-Konflikt oder individuelle Datenstruktur
Allowed memory size exhausted CLI-PHP-Speicherlimit zu niedrig
Maximum execution time exceeded Browser-Updater oder Hosting beendet den Prozess
Package conflict Composer-Abhängigkeiten blockieren die Zielversion
Service not found Plugin oder Konfiguration nicht mit der Zielversion kompatibel
Unknown column oder duplicate column Migration teilweise gelaufen oder Datenbankschema abweichend

11. Rollback oder Reparatur entscheiden

Nicht jeder Fehler erfordert sofort eine vollständige Wiederherstellung. Entscheidend ist, ob der Code bereits aktualisiert wurde, ob Migrationen gelaufen sind und ob neue Geschäftsdaten entstanden sind.

Situation Sinnvolle Richtung
Composer scheitert vor Bereitstellung des neuen Codes Abhängigkeiten korrigieren; Datenbank bleibt normalerweise unverändert.
Neuer Code bereitgestellt, Migration noch nicht gestartet Codebestand korrigieren oder kontrolliert auf vorherigen Stand zurücksetzen.
Migration teilweise ausgeführt Fehlerursache fachlich analysieren; kein einfacher Datei-Rollback.
Shop war nach Update bereits produktiv Neue Bestellungen und Änderungen vor jedem Datenbank-Rollback sichern.
Dateien und Datenbank müssen zusammenpassen

Ein Rollback nur der Dateien kann zu einer alten Codebasis mit bereits verändertem Datenbankschema führen. Wiederherstellung immer als zusammengehörigen Versionsstand planen.

12. Shop nach dem Update vollständig testen

  • Administration lädt ohne JavaScript- oder API-Fehler
  • Startseite und Kategorien funktionieren
  • Produktdetailseiten werden vollständig angezeigt
  • Warenkorb lässt sich verwenden
  • Registrierung und Kundenlogin funktionieren
  • Checkout mit den wichtigsten Zahlungsarten funktioniert
  • Bestellmails werden versendet
  • Plugins und Apps arbeiten wie vorgesehen
  • Theme und Erlebniswelten werden korrekt dargestellt
  • Scheduled Tasks und Message Queue laufen
  • Keine neue Exception in Shopware- und Server-Logs
  • Performance hat sich nicht auffällig verschlechtert
Wartungsmodus erst danach beenden

Erst wenn zentrale Prozesse und Logs geprüft sind, sollten alle Verkaufskanäle wieder freigeschaltet werden.

13. Abschlusskontrolle

  • Backup und Wiederherstellungsweg sind vorhanden
  • Zielversion und aktueller Codebestand sind eindeutig
  • PHP- und Datenbankversion erfüllen die Anforderungen
  • Erweiterungen sind für die Zielversion geprüft
  • Composer-Konflikte sind vollständig aufgelöst
  • system:update:prepare lief erfolgreich
  • system:update:finish lief erfolgreich
  • Cache wurde neu aufgebaut
  • Administration und Storefront wurden getestet
  • Checkout und Bestellmails funktionieren
  • Scheduled Tasks und Message Queue laufen
  • Logs enthalten keine neuen kritischen Fehler
  • Wartungsmodus wurde kontrolliert beendet
Update erfolgreich abgeschlossen

Das Update gilt erst als abgeschlossen, wenn Shopware-Version, Datenbankschema, Erweiterungen und produktive Abläufe gemeinsam geprüft wurden.

Häufige Fragen

Warum bleibt Shopware nach dem Update im Wartungsmodus?

Der Updateprozess wurde möglicherweise nicht vollständig beendet oder der Wartungsmodus wurde nach einem Fehler nicht zurückgesetzt. Vor dem Deaktivieren müssen Migrationen und Shopfunktion geprüft werden.

Kann ich system:update:finish einfach erneut ausführen?

Nur wenn der bereitgestellte Code eindeutig zur Zielversion passt und die vorherige Fehlermeldung verstanden wurde. Bei einer fehlgeschlagenen Migration zuerst Ursache und Datenbankzustand prüfen.

Warum scheitert das Update in der Administration, aber nicht per CLI?

Browserbasierte Updates können an Zeit- oder Speicherlimits scheitern. Die CLI ist für produktive und größere Installationen stabiler.

Müssen alle Plugins vor jedem Update deaktiviert werden?

Nicht pauschal bei jedem Patch-Update. Entscheidend sind Zielversion, offizieller Updatepfad und Kompatibilität. Bei bestimmten Hauptversionswechseln gelten strengere Vorgaben.

Darf composer.lock gelöscht werden?

Nicht als allgemeine Reparaturmaßnahme. Dadurch können viele Paketversionen gleichzeitig wechseln. Konflikte zuerst gezielt analysieren.

Reicht cache:clear nach einem fehlgeschlagenen Update?

Nur bei veralteten Cache- oder Containerdateien. Composer-Konflikte, fehlende Klassen und Migrationen werden dadurch nicht behoben.

Verwandte Shopware-Anleitungen

Das Shopware Update ist weiterhin fehlgeschlagen?

Ich prüfe Zielversion, Composer-Abhängigkeiten, Erweiterungen, Migrationen, Cache und Server-Logs direkt in der bestehenden Shopware-Installation.

Technische Prüfung anfragen
Stand: Juli 2026 · Hinweise gelten für selbst gehostete Shopware-6-Installationen. Updateablauf, Systemanforderungen und verfügbare Befehle können je nach Shopware-Version und Hosting abweichen.