Shopware 6.5 Update: Fehler, Lösungen und der Weg zu 6.7

Shopware 6.5 erhält voraussichtlich nur noch bis zum 28.02.2027 Sicherheitsupdates. Wer heute noch auf 6.5 oder einer älteren Version arbeitet, sollte den Wechsel auf Shopware 6.7 jetzt planen. Gerade bei solchen Versionssprüngen tritt aber oft der gefürchtete «kritische Fehler» auf: Der Shop zeigt eine leere Seite oder «Leider ist etwas schiefgelaufen» und steht still.

Dieser Artikel hilft bei typischen Fehlern beim Update auf und innerhalb von Shopware 6.5 – und bei vielen Problemen, die beim Major-Upgrade von 6.5 auf 6.6 oder 6.7 genauso auftreten. Sie finden vorbeugende Massnahmen, die häufigsten Ursachen, konkrete Composer- und SQL-Befehle sowie eine Checkliste für die Zeit nach dem Update.

«Kritischer Fehler» ist meist ein Sammelbegriff. Dahinter stecken in der Regel Konflikte bei Composer-Abhängigkeiten, Inkonsistenzen in der Datenbank oder Probleme mit Dateiberechtigungen und der Serverumgebung. Die Fehlermeldung allein verrät die Ursache selten – entscheidend ist eine saubere Diagnose. Und vieles lässt sich mit guter Vorbereitung ganz vermeiden.

Shopware 6.5 läuft aus: Was jetzt zu tun ist

Gemäss Release Policy von Shopware sieht der Support der einzelnen Versionen so aus (Stand Oktober 2026):

Nach dem voraussichtlichen Supportende am 28.02.2027 schliesst Shopware Sicherheitslücken in 6.5 nicht mehr. Ein Zwischenhalt auf 6.6 verschafft nur rund ein Jahr Aufschub, deshalb lohnt sich der Wechsel auf 6.7 in einem Projekt – Shopware empfiehlt dabei, Major-Version für Major-Version zu aktualisieren, also über 6.6. So gehen Sie vor:

1. Upgrade-Check machen: Erfassen Sie Version, Plugins, Eigenentwicklungen, Schnittstellen und Hosting. Shopware 6.7 braucht PHP 8.2 oder neuer sowie MySQL 8.0.22+ oder MariaDB 10.11.6+.
2. Testumgebung aufsetzen: Spielen Sie das Upgrade zuerst auf einer Kopie des Shops durch – nie direkt im Live-System.
3. Plugins auf 6.7-Kompatibilität prüfen: Shopware 6.7 bringt einen neuen Admin-Build. Erweiterungen mit eigenen Admin-Modulen brauchen deshalb eigene 6.7-Versionen. Für Plugins ohne Nachfolgeversion müssen Sie rechtzeitig einen Ersatz finden.

Wer noch auf Shopware 6.4 ist, sollte ebenfalls auf 6.7 wechseln – über die Zwischenschritte 6.5 und 6.6. Für Shopware 5 ist der Umstieg auf Shopware 6 faktisch ein Neuaufbau – mehr dazu auf unserer Seite zur Shopware-Migration.

Ausführlich beschreiben wir Weg, Checkliste und Zeitplan im Leitfaden zum Shopware 6.7 Upgrade.

Sie möchten das nicht selbst machen? Wir bringen Ihren Shop zum Festpreis auf 6.7. Ein vorgelagerter Upgrade-Check legt Umfang und Preis verbindlich fest: Shopware-Upgrade auf 6.7.

Was hinter dem «kritischen Fehler» steckt

Ein kritischer Fehler bedeutet, dass Shopware nicht mehr korrekt laden kann. Er zeigt sich als leere Seite, als allgemeine Fehlermeldung oder als PHP Fatal Error in den Server-Logs – meist während oder direkt nach dem Update. Die Ursachen lassen sich in drei Gruppen einteilen: Umgebung, Abhängigkeiten und Datenintegrität.

• Inkompatible Plugins oder Themes: Die häufigste Ursache. Veraltete Erweiterungen bringen widersprüchlichen Code mit, verursachen unlösbare Abhängigkeiten oder brechen Kernfunktionen.
• PHP-Version und Speicherlimit: Neue Shopware-Versionen stellen oft höhere Anforderungen an PHP-Version und Arbeitsspeicher. Erfüllt der Server sie nicht, bricht das Update-Skript oder Shopware selbst ab.
• Composer-Abhängigkeitskonflikte: Shopware 6 baut auf Composer und Symfony-Komponenten wie Doctrine\DBAL\DriverManager und Symfony\Bundle\FrameworkBundle auf. Ein Core-Update aktualisiert diese Bibliotheken mit. Brauchen Plugins andere Versionen derselben Bibliothek, kommt es zum Konflikt.
• Datenbankinkonsistenzen: Unterbrochene Updates oder manuelle Löschungen hinterlassen die Datenbank in einem inkonsistenten Zustand. Typische Folgen sind SQLSTATE: Base table or view not found oder SQLSTATE: Column already exists bei späteren Migrationen.
• Dateiberechtigungen und Serverkonfiguration: Falsche Berechtigungen hindern Shopware daran, Dateien zu schreiben. Serverseitiges Caching (z.B. NGINX Proxy Cache) kann nach dem Update zu Anzeigefehlern führen.
• Beschädigte Dateien oder unvollständige Updates: etwa durch abgebrochene Uploads.

Oft ist der sichtbare Fehler nur das letzte Glied einer Kette: Eine kleine Inkompatibilität löst Folgefehler aus. Beheben Sie deshalb immer den frühesten Fehler im Log, nicht nur das letzte Symptom.

Deprecation-Warnungen ernst nehmen

Log-Meldungen wie User Deprecated: The "url" connection parameter is deprecated... Not configuring a schema manager factory is deprecated sind selbst kein kritischer Fehler. Sie zeigen aber Änderungen in Kernabhängigkeiten wie Doctrine DBAL an. Bei einem Major-Update – etwa von 6.5 auf 6.6 oder 6.7 – wird veralteter Code entfernt oder geändert. Plugins, die noch darauf aufbauen, verursachen dann einen kritischen Fehler. Wer diese Warnungen regelmässig prüft, erkennt Probleme vor dem Update.

Vorbeugen: Vorbereitung vor jedem Update

Die beste Strategie gegen kritische Fehler ist eine gründliche Vorbereitung.

Backup von Dateien und Datenbank

Erstellen Sie vor jedem Update ein vollständiges Backup der Shopware-Installation – Dateien und Datenbank. Shopware selbst erstellt keine Backups; das liegt bei Ihnen oder Ihrem Hosting-Partner. Mit einem Backup können Sie den Shop bei Problemen in den vorherigen Zustand zurücksetzen.

Testumgebung nutzen

Testen Sie das Update zuerst in einer separaten, identischen Testumgebung. So finden Sie Probleme in Ihrer konkreten Konfiguration, ohne den Live-Shop zu gefährden. Auch sorgfältig geplante Updates können an unvorhergesehenen Konflikten scheitern – deshalb sind Testumgebung und Wiederherstellungsplan so wichtig wie das Update selbst.

Systemanforderungen prüfen

Stellen Sie sicher, dass Ihr Server die Anforderungen der Zielversion erfüllt. Beim Update über die Administration prüft Shopware das als ersten Schritt. Ist nicht alles im grünen Bereich, beheben Sie das zuerst. Veraltete PHP-Versionen und zu knappe Speicherlimits sind häufige Fehlerursachen.

Plugin-Kompatibilität prüfen

Inkompatible oder veraltete Plugins sind eine Hauptursache für kritische Fehler. Prüfen Sie die Kompatibilität aller Erweiterungen im Shopware Store, im Updater der Administration oder in Ihrem Shopware Account unter «Lizenzen».

Beim Update über die Administration zeigt Shopware für jedes Plugin einen von drei Status an:

• «Bereits kompatibel»
• «Mit der neuen Shopware-Version» – ein Update ist nach dem Core-Update möglich
• «Nicht kompatibel» – es gibt keine Nachfolgeversion

Deaktivieren Sie inkompatible Plugins, bevor Sie das Core-Update starten. Bei Major-Updates (z.B. 6.4 auf 6.5 oder 6.5 auf 6.6/6.7) ist es oft nötig, alle Plugins zu deaktivieren.

Die richtige Update-Methode wählen

Shopware bietet drei Wege:

• Browser (Shopware Installer): Das Update läuft über eine einzelne PHP-Datei (shopware-installer.phar.php). Übertragen Sie sie im Binärmodus (z.B. in FileZilla), sonst wird sie beschädigt.
• Administration: Unter «Einstellungen > System > Shopware Update», inklusive System- und Plugin-Prüfung.
• Composer: Empfohlen für Entwickler und komplexe Setups, weil Sie mehr Kontrolle über die Abhängigkeiten haben. Die Befehlsfolge finden Sie weiter unten.

Erste Hilfe: Cache, Logs, Plugins

Wenn der Shop nach dem Update nicht mehr läuft, beginnen Sie mit diesen drei Schritten.

Cache leeren

Die erste und häufigste Lösung. Shopware cacht Konfigurationen, kompilierte Templates und Routen. Neuer Code kann mit alten Cache-Dateien kollidieren; das Leeren erzwingt den Neuaufbau.

• Mit CLI-Zugriff: bin/console cache:clear
• Ohne Zugriff auf die Administration: den Inhalt von var/cache per FTP/SSH löschen

Logs prüfen

Die Fehlerseite verrät kaum etwas. Den konkreten PHP Fatal Error, SQL-Fehler oder Stack-Trace finden Sie in den Server-Logs (Apache/Nginx) und in den Shopware-Logs unter var/log/. Das Plugin FroshTools bietet eine Log-Anzeige in der Administration.

Plugins gezielt deaktivieren

Vermuten Sie einen Plugin-Konflikt, deaktivieren Sie alle Plugins, um das Problem einzugrenzen. So sehen Sie, ob der Fehler im Core oder in einer Erweiterung liegt.

• Mit Administration: unter «Erweiterungen > Meine Erweiterungen»
• Ohne Administration: in der Datenbanktabelle plugin das Feld active für verdächtige Plugins auf 0 setzen

Häufige Fehlermeldungen im Überblick

Composer-Fehler beheben

«Could not execute ‘composer require’ for plugin…»

Der Fehler tritt häufig auf, wenn Plugins Pakete über Composer installieren wollen – besonders nach grösseren Shopware-Updates oder manuellen Plugin-Uploads. Er weist auf einen Versionskonflikt hin.

1. Notieren Sie die Pakete, die in der Fehlermeldung genannt werden (z.B. moorl/foundation 1.5.28).
2. Öffnen Sie die composer.json im Hauptverzeichnis Ihres Shops.
3. Passen Sie die Version an. Es gibt drei Varianten:
   • Sicher (empfohlen): die Version eintragen, die in der Fehlermeldung verlangt wird (z.B. moorl/foundation 1.5.29). Das müssen Sie unter Umständen bei jedem Update wiederholen.
   • Flexibler: ein Sternchen für die letzte Stelle verwenden (z.B. moorl/foundation 1.5.*).
   • Für Erfahrene: die ganze Zeile mit dem Paket löschen und damit die require-Anweisung entfernen.
4. Speichern Sie die Datei und aktualisieren Sie die Plugins bzw. starten Sie das Update erneut.

«Environment variable COMPOSER_HOME is misconfigured»

Der Pfad zum Composer-Home-Verzeichnis ist falsch, oder Composer hat auf dem Webserver keine Lese- und Schreibrechte. Passen Sie die Variable COMPOSER_HOME in der Datei .env oder .env.local im Hauptverzeichnis an.

Update mit Composer: die Befehlsfolge

Wenn Sie per Composer aktualisieren und auf Probleme stossen, halten Sie sich an diese Reihenfolge:

1. Wechseln Sie ins Shopware-Hauptverzeichnis und führen Sie bin/console system:update:prepare aus.
2. Ersetzen Sie in der composer.json die Version von shopware/core durch die Zielversion. Passen Sie auch shopware/administration, shopware/storefront, shopware/elasticsearch usw. an.
3. Führen Sie composer update --no-scripts aus. Das Flag --no-scripts verhindert, dass Post-Update-Skripte zu früh laufen und Konflikte verursachen.
4. Löschen Sie das Verzeichnis bin und die Datei public/index.php, damit recipes:install sie korrekt neu anlegt: rm -rf bin und rm public/index.php.
5. Führen Sie yes | composer recipes:install --force --reset aus. Damit werden die Konfigurationsdateien und Composer-Rezepte neu installiert.
6. Schliessen Sie das Update mit bin/console system:update:finish ab.
7. Aktualisieren Sie alle Plugins: bin/console plugin:update:all.
8. Leeren Sie den Cache: bin/console cache:clear.

Datenbankfehler beheben

Diese Fehler lassen sich nur direkt in der Datenbank beheben, z.B. mit phpMyAdmin oder Adminer. Erstellen Sie vorher ein Backup.

«Table: custom_field_set Entry already exists…»

Ein Eintrag für ein Zusatzfeld-Set (z.B. moorl_video) existiert bereits in der Tabelle custom_field_set – meist nach einer unvollständigen Installation oder manuellen Löschung. Ersetzen Sie moorl_video durch den Namen aus Ihrer Fehlermeldung:

DELETE FROM `custom_field_set` WHERE `name` = 'moorl_video';

Unterbrochene Migrationen

Die allgemeine Meldung «Error during installation or update» weist oft auf unterbrochene Datenbankmigrationen hin. Auslöser sind etwa ein zurückgespieltes Backup, per FTP ersetzte Dateien oder manuell entfernte Plugins. Die folgenden Beispiele beziehen sich auf das Plugin Foundation von moori (technischer Name MoorlFoundation); ersetzen Sie den Namen durch den Ihres Plugins.

SQLSTATE: Base table or view not found: Das Plugin wurde samt Datenbanktabellen manuell gelöscht, die Einträge in der Tabelle migration sind aber noch da. Löschen Sie diese, damit eine Neuinstallation oder ein Update wieder möglich ist:

DELETE FROM `migration` WHERE `class` LIKE 'MoorlFoundation%';

SQLSTATE: Column already exists: Die Tabelle migration wurde geleert, die Tabellen des Plugins existieren aber noch, und die Migration wurde unterbrochen. Da die Daten schon vorhanden sind, markieren Sie den Migrationsschritt als erledigt. Wiederholen Sie den Befehl bei Bedarf nach jedem Update-Versuch:

UPDATE `migration` SET `update` = now(), `message` = NULL WHERE `class` LIKE 'MoorlFoundation%' AND `message` IS NOT NULL;

Fehler beim Laden von Klassen und beim JWT-Schlüssel

«Attempted to load class ‘HttpKernel’ from namespace ‘Shopware\Core’»

Meist sind die Composer-Autoload-Dateien oder der Cache nach dem Update beschädigt, sodass Shopware Kernklassen nicht laden kann. Installieren Sie die Abhängigkeiten neu und leeren Sie den Cache. Führen Sie die Befehle zuerst in der Testumgebung aus, da composer update Abhängigkeiten im Rahmen der composer.json aktualisiert:

chmod -R 775 var/cache
rm -rf vendor
composer install
composer update
composer dump-autoload
bin/console about
bin/console cache:clear

«Key provided is shorter than 2048 bits»

Das Problem betrifft den JWT Secret Key, der nach Migrationen oder Änderungen an der Umgebung ungültig werden kann. Generieren Sie ihn neu:

bin/console system:generate-jwt-secret --force

Was Sie auf keinen Fall tun sollten

Plugins sind nicht nur Dateien, sondern tief in die Datenbank integriert. Wer die Plugin-Verwaltung von Shopware umgeht, macht aus einem lösbaren Problem schnell ein schwer lösbares.

• Plugins per FTP löschen: Das hinterlässt verwaiste Datenbankeinträge und führt bei späteren Installationen oder Updates zu Fehlern wie Base table or view not found.
• Plugin-Tabellen manuell löschen: Ohne passende Bereinigung der Tabelle migration entstehen schwere Inkonsistenzen.
• Ohne Plan weiterprobieren: Sind Sie bei einem Schritt unsicher oder hilft keine der Lösungen, wenden Sie sich an den Support des Plugin-Herstellers oder an eine Agentur – bevor weitere manuelle Eingriffe die Analyse erschweren. Wir helfen Ihnen gerne über unseren Shopware-Support.

Checkliste nach dem Update

Ein Update ist erst abgeschlossen, wenn Core und Plugins wieder in einem konsistenten Zustand sind.

• Plugins aktualisieren: Bringen Sie alle Plugins auf die neueste kompatible Version, z.B. mit bin/console plugin:update:all.
• Cache nochmals leeren: bin/console cache:clear. Zeigt der Health Check danach noch Fehler, hilft es oft, den Browser zu schliessen und den Cache erneut zu leeren.
• Shop durchtesten: Storefront, Administration, Checkout und alle wichtigen Schnittstellen prüfen.

Fazit: Updates beherrschen – und 6.7 rechtzeitig angehen

Kritische Fehler nach einem Shopware-Update sind ärgerlich, lassen sich mit systematischem Vorgehen aber fast immer beheben. Die wichtigsten Grundlagen sind ein vollständiges Backup, eine Testumgebung und die sorgfältige Prüfung der Plugins. Tritt trotzdem ein Fehler auf, zeigen die Logs den Weg zu den passenden Composer- oder SQL-Befehlen.

Für Shops auf Shopware 6.5 ist jetzt der richtige Zeitpunkt, das Upgrade auf 6.7 zu planen – das voraussichtliche Supportende am 28.02.2027 kommt schneller, als man denkt. Wir übernehmen das Upgrade auf Shopware 6.7 zum Festpreis, inklusive Upgrade-Check. Damit Ihr Shop danach aktuell bleibt, bieten wir zudem Wartungsabos an.

Quellen: Shopware: Updating Shopware · moori: Error Messages – Causes and Solutions · Werkstattl: Update Shopware 6 with composer update –no-scripts · Shopware-Forum: Critical Error bei Update auf Shopware 6.5