Die ersten Schritte
Ein Update ist abgebrochen, oder der Shop zeigt danach Fehler, leere Seiten oder eine Administration, die nicht lädt. Jetzt hilft eine feste Reihenfolge.
- 01
Wartungsmodus einschalten
Für alle Verkaufskanäle. So entstehen keine Bestellungen in einem halb aktualisierten Shop.
- 02
Zustand sichern
Auch kaputt ist er die Grundlage der Fehlersuche.
- 03
Protokolle lesen
Bevor Sie etwas ändern. Die Meldung nennt meist die Stelle.
- 04
Entscheiden
Reparieren, wenn die Ursache klar und schnell behebbar ist. Zurückspielen, wenn nicht.
Den Wartungsmodus schalten Sie in den Einstellungen jedes Verkaufskanals ein oder auf der Konsole für alle auf einmal. In den Kanal-Einstellungen geben Sie auch Ihre IP-Adresse frei, um den Shop trotz Wartung zu sehen.
bin/console sales-channel:maintenance:enable --allWo es typischerweise hakt
Lädt die Administration nicht, bringt oft eine Erweiterung veraltete Admin-Dateien mit. Dann hilft, sie zu aktualisieren oder vorübergehend zu deaktivieren.
Inkompatible Erweiterungen
Ein Plugin unterstützt die neue Version noch nicht. Besonders Erweiterungen, die tief in Checkout, Zahlung oder Versand eingreifen.
Composer-Konflikte
Wer per Composer aktualisiert, bekommt „Your requirements could not be resolved“, wenn Erweiterungen andere Paketversionen verlangen.
Abgebrochene Migrationen
Ein Update baut die Datenbank um. Bricht eine Migration ab, steht sie zwischen altem und neuem Stand.
Theme nicht neu kompiliert
Die Storefront sieht ungestylt aus oder einzelne Elemente fehlen.
Caches und OPcache
Der Server liefert noch Teile des alten Codes aus. Die Fehler verschwinden nach dem Leeren aller Caches und einem Neustart von PHP.
Hintergrundprozesse
Warteschlange und geplante Aufgaben laufen mit altem Code weiter: E-Mails, Indexierung oder Exporte hängen.
Die Ursache eingrenzen
Shopware schreibt Fehler in Protokolldateien im Ordner var/log, bei einem Produktivshop in Dateien wie prod-<Datum>.log. Dazu kommt das Fehlerprotokoll des Webservers. Die Meldung nennt meist die Klasse oder Datei, und darüber das Plugin.
Ein Befehl nach dem anderen, mit Blick ins Protokoll dazwischen. Wer alles auf einmal ausführt, weiß hinterher nicht, was geholfen hat.
bin/console plugin:refreshErweiterungen neu einlesen.bin/console plugin:listAlle Erweiterungen mit Version und Status.bin/console plugin:deactivate <Name>Eine verdächtige Erweiterung abschalten.bin/console cache:clearDen Cache leeren.bin/console theme:compileDas Theme neu kompilieren.bin/console dal:refresh:indexIndizes neu aufbauen, wenn Suche oder Kategorien falsch anzeigen.bin/console messenger:stop-workersHintergrundprozesse beenden, damit sie mit neuem Code starten.
Vor dem Update bin/console system:update:prepare, danach bin/console system:update:finish. Letzteres spielt die Datenbankmigrationen ein. Wurde dieser Schritt vergessen oder brach er ab, ist das oft schon die Ursache.
Zurück geht es nur mit Dateien und Datenbank
Ein Update verändert nicht nur Dateien, sondern über seine Migrationen auch die Datenbank. Alte Dateien auf einer bereits umgebauten Datenbank führen zu neuen Fehlern.
Ohne Sicherung von direkt vor dem Update bleibt nur die Reparatur nach vorne: Ursache finden, Erweiterungen aktualisieren oder ersetzen, Migrationen erneut ausführen. Das dauert meist länger und braucht Erfahrung mit Shopware.
Dateien und Datenbank aus derselben Sicherung
Angelegt direkt vor dem Update. Bestellungen, die danach eingegangen sind, fehlen anschließend im Shop.
Er verhindert solche Bestellungen. Was zwischen Sicherung und Wartungsmodus bestellt wurde, gleichen Sie mit Zahlungsanbieter und Warenwirtschaft ab.
Sicherheitsupdates dürfen nicht warten
Ein fehlgeschlagenes Update ist kein Grund, künftig seltener zu aktualisieren.
Shopware veröffentlicht Sicherheitskorrekturen als Patch-Releases, erkennbar an der letzten Stelle der Versionsnummer. Ältere Versionen bekommen ausgewählte Korrekturen über das Security-Plugin, das eine aktuelle Version aber nicht ersetzt. Zwei Beispiele aus 2026:
Store API
Unter bestimmten Bedingungen Übernahme des Administratorzugangs und Ausführen von Code, besonders bei Headless-Shops.
Quelle: Sansec, August 2026App-Zugangsdaten
CVE-2026-31889: Übernahme von Zugangsdaten installierter Apps.
Quelle: GitHub Security Advisory, 2026Also: Sicherheitsupdates zeitnah und getestet einspielen, nicht blind. Wie das ohne Ausfall geht, beschreibt der Ratgeber Shopware 6 Updates einspielen, ohne den Shop zu gefährden.
Proben, aber nicht mit echten Kundendaten
Die beste Versicherung gegen ein fehlgeschlagenes Update ist eine Generalprobe auf einer Kopie des Shops. Dort darf es scheitern und wird behoben, bevor der Live-Shop etwas abbekommt.
Eine Kopie mit echten Namen, Adressen und Bestellungen ist aus Sicht des Datenschutzes eine zweite Datenbank voller personenbezogener Daten, oft schlechter geschützt als der Live-Shop.
| Feld | Live-Shop | Kopie |
|---|---|---|
| Name | Erika Beispiel | Kunde 4711 |
| erika@beispiel.de | kunde4711@test.invalid | |
| Adresse | Musterweg 1 | Teststraße 1 |
| Bestellung | 3 Artikel, 129,00 € | 3 Artikel, 129,00 € |
Erfundene Beispieldaten. Produkte, Preise und Bestellstrukturen bleiben, Personen nicht.
So verhindere ich das mit dem Doppelgänger
Für meine Kunden spiele ich jedes Shopware-Update zuerst auf dem Doppelgänger ein, einer exakten Kopie des Shops auf einem eigenen Server in Deutschland.
Anonymisierte Kopie
Kundendaten werden bei jeder Kopie anonymisiert.
Bis zur Kasse geprüft
Erweiterungen, Theme und Hintergrunddienste prüfe ich, und ich bestelle bis zur Kasse, mit den Testmodi der Zahlungsanbieter.
Live, jederzeit umkehrbar
Erst der geprüfte Stand geht live, in wenigen Minuten. Jeder Release ist eine eigene Version, der vorherige Stand ist in Sekunden wieder da.
Jeden Morgen getestet
Im Live-Shop läuft jeden Morgen eine Testbestellung bis zur Zahlung.
Wie das im Detail aussieht, steht auf der Seite Doppelgänger für Shopware.
Aus der Praxis: JuCad arbeitet mit dem Doppelgänger: Jedes Update und jede neue Funktion läuft zuerst auf der Kopie des Shops und geht erst nach dem Test live.
Seit unser Shop einen Doppelgänger hat, auf dem Julian jedes Update und jede Änderung zuerst prüft, läuft der Shop absolut rund. Updates sind für uns kein Großprojekt mehr, das man vor sich herschiebt. Neue Funktionen sehen und testen wir dort, bevor sie live gehen, und geben sie erst frei, wenn alles passt. Das hat unsere Arbeit spürbar produktiver gemacht.
Kurz beantwortet.
Was tue ich zuerst, wenn ein Shopware-Update fehlschlägt?
Schalten Sie den Wartungsmodus für alle Verkaufskanäle ein, damit keine Bestellungen in einem halb aktualisierten Shop entstehen. Danach sichern Sie den aktuellen Zustand für die Fehlersuche und sehen in die Protokolle unter var/log und ins Fehlerprotokoll des Webservers.
Kann ich einfach die alten Dateien zurückkopieren?
Nein. Ein Update verändert mit seinen Migrationen auch die Datenbank. Alte Dateien auf einer neuen Datenbankstruktur führen zu weiteren Fehlern. Zurück geht es nur mit Dateien und Datenbank aus derselben Sicherung, idealerweise direkt vor dem Update angelegt.
Welche Erweiterungen machen bei Updates am häufigsten Probleme?
Erweiterungen, die tief in Checkout, Zahlung oder Versand eingreifen, und individuell entwickelte Plugins, deren Hersteller die neue Shopware-Version noch nicht unterstützt. Vor jedem Update lohnt ein Blick auf die Kompatibilitätsangaben aller installierten Erweiterungen.
Nach dem Update sieht der Shop ungestylt aus. Was ist passiert?
Meist wurde das Theme nach dem Update nicht neu kompiliert, oder Caches liefern noch alte Dateien aus. Das Neukompilieren des Themes und das Leeren der Caches beheben das in vielen Fällen. Bleibt der Fehler, liegt es oft an einer Theme-Erweiterung, die nicht zur neuen Version passt.
Wie dringend sind Shopware-Sicherheitsupdates?
Sehr dringend. Shopware veröffentlicht Sicherheitskorrekturen als Patch-Releases und für ältere Versionen über das Security-Plugin. 2026 wurden unter anderem eine Lücke in der Store API mit möglicher Übernahme des Administratorzugangs und eine Lücke bei App-Zugangsdaten geschlossen. Solche Updates sollten zeitnah, aber getestet eingespielt werden.
Darf ich Updates auf einer Kopie mit echten Kundendaten testen?
Davon rate ich ab. Eine Kopie mit echten Namen, Adressen und Bestellungen ist aus Sicht des Datenschutzes eine zweite Datenbank voller personenbezogener Daten, oft schlechter geschützt als der Live-Shop. Für Tests reicht eine Kopie, in der Kundendaten anonymisiert sind.