Shopware 6.7 erschien Ende 2024 mit dem, was die offizielle Dokumentation als „major release with multiple breaking changes“ qualifiziert. Für Shops auf 6.6 ist die Migration mittelfristig obligatorisch — Shopware pflegt parallel nur die letzte stabile Version und die vorherige Version, sodass zu lange auf 6.5 oder 6.6 zu bleiben den Zugang zu Sicherheits-Patches abschneidet. Für Plugins, die in 6.6 entwickelt wurden, haben sich mehrere kritische APIs zwischen 6.6 und 6.7 in ihrer Signatur geändert oder wurden entfernt.
Dieser Artikel ist ein direkter Erfahrungsbericht über die Migration 6.6 → 6.7, die wir 2025-2026 auf mehreren Shops durchgeführt haben, mit den echten technischen Fallstricken, die wir angetroffen haben, und den Patches, die wir produzieren mussten, um unsere eigenen und Drittanbieter-Plugins anzupassen. Ziel: anderen Teams den Monat Debugging zu ersparen, den wir bei bestimmten stillen Regressionen verbracht haben.
Was sich in Shopware 6.7 wirklich ändert
Jenseits des Release-Marketings, hier die 6.7-Änderungen mit konkretem Einfluss auf existierende Plugins.
Payment Handler API Überarbeitung. Das Interface AsynchronousPaymentHandlerInterface wird in 6.7 entfernt. Jedes Payment-Plugin, das dieses Interface in 6.6 implementierte, muss zu AbstractPaymentHandler migrieren. Die pay()– und finalize()-Methoden haben eine andere Signatur: die Struct AsyncPaymentTransactionStruct wird durch PaymentTransactionStruct ersetzt, minimalistischer und DDD-orientiert.
Modifizierte Service-Tags. Das Tag shopware.payment.method.async, das synchrone und asynchrone Payments unterschied, wird zugunsten eines einheitlichen Tags shopware.payment.method entfernt. Wenn Ihre services.xml das alte Tag verwendete, registriert sich der Payment-Handler nicht mehr korrekt und die Zahlungsmethode verschwindet ohne sichtbaren Fehler aus dem Checkout.
Admin Vue 2 → Vue 3 Migration. Das Admin Shopware 6.7 ist auf Vue 3 portiert (während 6.6 auf Vue 2 mit Compat Layer war). Die sw-*-Komponenten (Legacy) werden durch die mt-*-Komponenten (Meteor Design System) ersetzt. Viele sw-*-Komponenten sind als deprecated markiert und werden in einem späteren 6.x-Release entfernt. Admin-Plugins, die sw-* Komponenten verwendeten, müssen migrieren.
Admin-Übersetzungssystem modifiziert. Die $tc()-Methoden (translation choice, Plural-Verwaltung) wurden durch $t() mit nativer Plural-Verwaltung ersetzt. Ihre Admin-Templates, die {{ $tc('mein.plugin.label') }} machten, müssen zu {{ $t('mein.plugin.label') }} wechseln.
Admin-Build über Vite. Das Admin kompiliert nun über Vite mit einer manifest.json, die anders strukturiert ist als die der 6.6. Plugins, die ihr Admin-JS über den historischen Mechanismus injizierten, müssen ihre Build-Pipeline anpassen, um das richtige Manifest zu generieren, sonst lädt das Admin leeres JS statt Ihren Code.
Storefront: Bootstrap 5.3 generalisiert. Der Wechsel zu Bootstrap 5.3 im Storefront aktiviert nativen Support für data-bs-theme, was die Dark-Mode-Implementierungen vereinfacht — Thema unseres DataFirefly Dark Mode Plugins, das diese Konvention ausnutzt. Custom-Themes basierend auf Bootstrap 5.2 oder früher können SCSS-Variablen haben, die nicht mehr mappen.
PHP- und MySQL-Kompatibilität. 6.7 erfordert PHP 8.2+ (PHP 8.1 EOL, PHP 8.3 empfohlen) und MySQL 8.0+ oder MariaDB 11.4 LTS. Hostings, die noch in MySQL 5.7 oder MariaDB 10.x sind, müssen ihre DB vor dem Applikations-Upgrade migrieren.
Die Plugin-für-Plugin Breaking Changes, die wir angetroffen haben
Auf den Shops, die wir migriert haben, hier die konkreten Bugs, die beim Upgrade 6.6 → 6.7 entdeckt wurden.
MoptWorldline (Zahlung Worldline / SaferPay). Das Worldline-Zahlungsplugin in der 6.6-Version implementierte AsynchronousPaymentHandlerInterface. Beim Übergang zu 6.7 lädt das Plugin nicht mehr korrekt, und die Worldline-Zahlungsmethoden verschwinden aus dem Checkout. Der Patch erfordert die Migration zu AbstractPaymentHandler und das Umschreiben der pay()– und finalize()-Methoden mit der neuen PaymentTransactionStruct-Signatur. Geschätzte Arbeit: 2-4 Tage für einen erfahrenen Shopware-Dev.
Custom Admin-Plugins mit sw-* Komponenten. In unseren MySmartBook- und anderen Plugins verwendeten mehrere benutzerdefinierte Admin-Komponenten sw-card, sw-button, sw-text-field usw. In 6.7 existieren diese Komponenten noch, sind aber als deprecated markiert. Die mt-card-, mt-button-, mt-text-field-Komponenten ersetzen sie. Die Migration ist mechanisch, erfordert aber eine erschöpfende Überprüfung aller Admin-Dateien.
Snippets und Übersetzungen. Snippet-Dateien in 6.6 verwendeten manchmal die pluralisierte Struktur, die $tc() konsumierte. In 6.7 mit $t() funktionieren einige Snippet-Strukturen nicht mehr identisch. Systematisch zu testen, besonders bei Snippets mit Zählern („1 Produkt“ / „N Produkte“).
Custom Field Customer und Synchronisation. Unser Dark Mode Plugin für Shopware speichert die Nutzerpräferenz in einem df_dark_mode_preference-Custom-Field auf der Customer-Entität. Die 6.7-Migration hat die Custom-Fields-Kompatibilität erhalten, aber die Synchronisations-API hat eine leicht andere Signatur. Systematisch nach dem Upgrade zu testen.
OpenSearch 2.19+ obligatorisch. Wenn Ihr Shop die Volltextsuche mit OpenSearch (ehemals Elasticsearch in früheren Shopware-Versionen) verwendet, erfordert 6.7 mindestens OpenSearch 2.19. OpenSearch 1.x-Versionen werden nicht mehr unterstützt. OpenSearch-Cluster-Migration vor dem Applikations-Upgrade einzuplanen.
Die Migrations-Checkliste in 8 Schritten
Für eine kontrollierte 6.6 → 6.7 Migration, hier die Reihenfolge, die wir intern befolgen.
Schritt 1 — Audit der installierten Plugins. Listen Sie alle auf Ihrem Shop aktivierten Plugins auf. Für jedes prüfen Sie im Store oder auf GitHub, ob eine 6.7-kompatible Version existiert. Nicht aktualisierte Plugins sind große Risiken: vorübergehend zu deaktivieren, intern zu patchen oder zu ersetzen.
Schritt 2 — Audit des Custom-Themes. Wenn Sie ein Custom-Theme verwenden (und nicht das native Storefront-Theme), prüfen Sie die Kompatibilität mit Bootstrap 5.3, die Strukturänderungen am Base-Layout und das Vite-Admin-System, wenn Ihr Theme Custom-Admin-JS injiziert.
Schritt 3 — Update der Infrastruktur-Umgebung. PHP 8.2+, MySQL 8 oder MariaDB 11.4 LTS, OpenSearch 2.19+ wenn verwendet, aktuelles Node.js (18+ oder 20 LTS). Vor dem Shopware-Applikations-Upgrade zu erledigen.
Schritt 4 — Vollständiges Backup. Datenbank + Files-Ordner + config/-Dateien. Es ist der Schritt, den wir vernachlässigen, bis das Upgrade unwiderruflich etwas kaputt macht. Systematisch vor jeder Änderung zu machen.
Schritt 5 — Migration in der Staging-Umgebung. Die Prod auf ein identisches Staging klonen, das 6.7-Upgrade auf dem Staging durchführen, erschöpfend validieren, bevor man die Prod anfasst. Es ist nicht optional — auf den Shops, die wir migriert haben, hatten 30 % kritische Bugs, die nur im Staging entdeckt wurden.
Schritt 6 — Shopware-Applikations-Upgrade. Über den SUM (Shopware Update Manager) in CLI: bin/console system:update:prepare, dann bin/console system:update:finish. Lesen Sie die offizielle Dokumentation sorgfältig für die Optionen (skip-asset-build, etc.). Rechnen Sie mit 30 min bis 2 h je nach Datenbankgröße.
Schritt 7 — Theme- und Admin-Neukompilierung. Nach dem Core-Upgrade das Theme neu kompilieren (bin/console theme:compile) und das Admin neu bauen (bin/build-administration.sh). Auf Shopware 6.7 kompiliert das Admin über Vite; der historische theme:compile-Befehl reicht nicht mehr für das Admin.
Schritt 8 — Erschöpfendes Post-Upgrade-Testing. Vollständiger Durchgang: Katalog-Navigation, Produktseite, In-den-Warenkorb-Legen, Checkout, Zahlung (jede Zahlungsmethode einzeln getestet), Kundenbereich, Admin (jedes installierte Modul). Bei B2B-Shops auch Angebote, hierarchische Konten, kundenspezifische Preise testen.
Die stillen Fallstricke, die wir in der Realität angetroffen haben
Jenseits der dokumentierten Breaking Changes, hier die subtilen Bugs, die sich nicht sofort nach dem Upgrade zeigen.
Der Payment-Handler, der sich nicht mehr registriert. Wie oben erwähnt, registriert sich ein Payment-Plugin mit altem Tag shopware.payment.method.async in 6.7 nicht mehr. Die Zahlungsmethode verschwindet aus dem Checkout, aber es wird kein Fehler ausgelöst — die entsprechende payment_method_id existiert noch in der Datenbank, der Handler wird einfach nicht mehr instanziiert. Symptom kundenseitig: die Methode wird im Admin (Konfiguration / Sales Channels / Payment Methods) angezeigt, erscheint aber nicht im Checkout.
Die Custom-Admin-Komponente, die leer rendert. Eine Komponente, die $tc() ohne zugehörige Übersetzung verwendete (Fall der hartcodierten Labels), rendert in 6.7 nichts mehr. Kein Fehler in der Konsole, einfach ein leerer Platzhalter. Durch manuelle Überprüfung der Custom-Admin-Screens nach dem Upgrade zu erkennen.
Das Vite-Manifest, das nicht generiert wird. Wenn Ihr Custom-Admin-Plugin mit einem personalisierten Skript in 6.6 gebaut wurde (Webpack oder direkter Rollup), generiert dieser Build möglicherweise nicht das von Shopware 6.7 erwartete manifest.json. Symptom: das Admin lädt, aber Ihr Plugin-JS wird nicht ausgeführt. Lösung: den Build anpassen, um ein Vite-kompatibles Manifest zu exportieren.
Pluralisierte Snippets, die nicht mehr übersetzt werden. Wenn Sie Snippets mit Struktur {count} | eine Sache | {count} Sachen hatten, die von $tc() konsumiert wurden, erfordert der Übergang zu $t() eine andere Syntax. Nicht migrierte Snippets zeigen die rohe Template-Zeichenkette statt der Übersetzung an.
Das Custom-Field, das in der API nicht mehr existiert. Einige Modifikationen der DAL-API (Data Abstraction Layer) in 6.7 haben die Serialisierung bestimmter komplexer Custom-Fields (Multi-Select, JSON) geändert. Die Werte in der Datenbank existieren noch, werden aber anders gelesen. Auf kritischen Custom-Fields zu testen.
Fazit: eine notwendige, aber zu antizipierende Migration
Die Shopware 6.6 → 6.7 Migration ist kein einfaches Minor-Update. Sie führt signifikante Breaking Changes ein, die echte Arbeit an den Plugins (insbesondere Payment), am Custom-Admin und an der Infrastruktur erfordern. Shops, die diese Migration in 1 Tag durchführen, „weil wir nur auf Update geklickt haben“, entdecken die Bugs Wochen später in der Produktion, manchmal mit direktem Umsatzeinfluss (defekte Zahlung, unbrauchbares Admin).
Die realistische Zeit-Investition für einen Shop mit 5-10 Drittanbieter-Plugins und einem Custom-Theme beträgt 5 bis 15 Manntage für einen erfahrenen Shopware-Entwickler, plus einige Tage Abnahme. Das Thema antizipieren, das Upgrade im Staging durchführen, erschöpfend vor der Prod testen — das ist es, was eine kontrollierte Migration von einer Krisen-Migration unterscheidet.
Für verwandte technische Themen durchstöbern Sie unsere Kategorien E-Commerce-News und Performance & Core Web Vitals. Und wenn Sie nach französischen, performance-first und gut gewarteten Shopware-6.7-Plugins suchen, ist unser Dark Mode Plugin ab Release Shopware-6.7-kompatibel und illustriert die technischen Patterns, die mit der neuen Architektur abgestimmt sind (Anti-FOUC, Customer Custom-Field, JS-Events für Drittanbieter-Synchronisation).
Ebenfalls lesenswert: die Checkliste zur Migration von PrestaShop 1.7 auf 8 und PrestaShop 9 vs PrestaShop 8.
