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.
Update bricht ab, Shop bleibt im Wartungsmodus oder Frontend und Administration funktionieren danach nicht korrekt.
Inkompatible Erweiterung, unpassende PHP-Version, Composer-Konflikt, fehlgeschlagene Migration oder unvollständiger Codebestand.
Keine Migrationen ausführen, solange der bereitgestellte Code nicht eindeutig zur vorgesehenen Shopware-Version passt.
Inhaltsverzeichnis
- Fehlerbild eingrenzen
- Backup und Testsystem prüfen
- Versionen und Systemanforderungen prüfen
- Erweiterungen kontrollieren
- Composer-Fehler analysieren
- Wartungsmodus kontrollieren
- Update vorbereiten
- Migrationen abschließen
- Cache und Container neu aufbauen
- Logs auswerten
- Rollback richtig entscheiden
- Shop vollständig testen
- 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?
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
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
bin/console --version
/usr/bin/php bin/console --version
CLI-PHP-Version kontrollieren
/usr/bin/php -v
Datenbankversion anzeigen
mysql --version
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
bin/console plugin:list
Plugin-Dateien neu einlesen
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?
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
composer --version
Projektdatei validieren
composer validate
Blockierende Abhängigkeit ermitteln
composer why-not shopware/core ZIELVERSION
ZIELVERSION muss durch die konkrete Shopware-Version ersetzt werden.
Abhängigkeiten ohne automatische Scripts aktualisieren
composer update --no-scripts
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
bin/console sales-channel:maintenance:enable --all
/usr/bin/php bin/console sales-channel:maintenance:enable --all
Wartungsmodus nach erfolgreicher Prüfung beenden
bin/console sales-channel:maintenance:disable --all
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.
bin/console system:update:prepare
/usr/bin/php bin/console system:update:prepare
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.
bin/console system:update:finish
/usr/bin/php bin/console system:update:finish
Migrationen separat anzeigen
bin/console database:migrate --all
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
bin/console cache:clear
/usr/bin/php bin/console cache:clear
Theme nur bei Storefront-Problemen neu kompilieren
bin/console theme:compile
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
ls -lah var/log/
Aktuelle Produktionseinträge lesen
tail -n 250 var/log/prod-*.log
Nach typischen Updatefehlern suchen
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. |
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
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
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