Shopware 6.6 auf 6.7: Was sich wirklich ändert

• von Tobias Schäfer • 15 min read
#Shopware #PHP #Shopware 6 #Plugin Development

6.7 ist kein kosmetisches Release. Es schließt mehrere in 6.6 begonnene Migrationen ab: Vuex→Pinia ist jetzt vollständig erzwungen (keine Vuex-APIs mehr vorhanden), die Vue-2-Kompatibilität ist komplett entfernt, Webpack ist im Admin-Build-System durch Vite ersetzt worden, und Redis wechselt von optional-aber-empfohlen zu zwingend erforderlich. Wer Plugins hat, die den Admin berühren oder PHP-Kernklassen erweitern, hat Arbeit vor sich.

Der positive Aspekt: Die architektonische Disruption von 6.6 war der größere Sprung. 6.7 verfeinert und vervollständigt, was 6.6 begonnen hat. Wer gut gewartete Plugins hat und die 6.6.x-Deprecation-Warnungen im Blick behalten hat, kann den Schadensradius hier überschaubar halten.

Was sich geändert hat: Überblick

KategorieUmfangAuswirkung
SystemanforderungenNode.js 20+, Redis 7.0+ Pflicht, Symfony 7.4+Mittel — vor Upgrade bereitstellen
Admin: Webpack → ViteAlle Plugins mit Admin-UI müssen neu gebaut werdenHoch — keine versionsübergreifende Kompatibilität
Admin: Pinia vollständigInterne Stores migriert; Shopware.State deprecated (entfernt in 6.8)Hoch für Plugins mit State-Nutzung
Admin: sw-* → mt-* erzwungenSeit 6.6 deprecated; in 6.7 als Wrapper aktiv, aber mit WarnungenMittel — Codemods verfügbar
Admin: Vue-2-Compat entfernt$tc() deprecated (entfernt in 6.8), Async-Komponenten als StandardMittel — vor Deploy abfangen
Caching: Delayed InvalidationCache invalidiert alle ~5 Min., nicht sofortMittel — Plugins müssen Erwartungen anpassen
Caching: Store-API-Route-CacheAlle Cached*Route-Klassen entferntHoch für Plugins, die diese erweitern
Caching: ESI für Header/FooterErfordert ESI-fähige HTTP-SchichtMittel — Nginx/Varnish-Konfiguration aktualisieren
PHP: Native TypenAlle Core-Properties haben native TypenHoch bei Erweiterung von Core-Klassen
PHP: DBAL 4, PHPUnit 11API-Änderungen, geänderte Test-SignaturenMittel
PHP: Payment-Handler-UmbauAlte Interfaces deprecated und durch AbstractPaymentHandler ersetztHoch für Shops mit Custom-Payment
PHP: OAuth-ScopesLeerzeichen-getrennte Strings, /api/oauth/authorize entferntGering–Mittel
StorefrontBarrierefreiheits-Standards, ESI-Konsequenzen, Custom-Field-NamenGering–Mittel

Jetzt upgraden?

Dieser Abschnitt richtet sich an Shopbetreiber und Verantwortliche, die entscheiden, wann der Zeitpunkt für den Wechsel kommt. Entwickler, die das Upgrade durchführen, können direkt zu den technischen Abschnitten springen.

Bereitschaft des Plugin-Ökosystems

6.7 erschien im Mai 2025. Anfang 2026 hatten die wichtigsten Shopware-Store-Plugins Zeit, kompatible Versionen zu veröffentlichen. Das ist ein wesentlicher Unterschied zu den ersten Monaten nach einem Major-Release — das Ökosystem hat aufgeholt. Vor allem anderen: jedes installierte Plugin gegen das 6.7-Kompatibilitäts-Badge im Shopware Store prüfen.

Für selbst entwickelte oder Agentur-Plugins gibt es kein Badge. Hier ist ein Code-Review erforderlich. Jedes Plugin mit Dateien in src/Resources/app/administration/ braucht eine Vite- und Pinia-Migration für 6.7 — davon ausgehen, bis das Gegenteil explizit geprüft wurde.

Cloud-gehostete (SaaS) Shops

Bei Shopwares cloud-gehostetem SaaS-Angebot steuert Shopware den Update-Zeitplan. Die Migration erfolgt nach Shopwares Zeitplan, nicht nach eigenem. Hinweis: Rise, Evolve und Beyond sind kommerzielle Plan-Tiers – sie können jeweils als SaaS, PaaS oder Self-hosted betrieben werden. Wer auf einem beliebigen Plan selbst hostet, steuert seinen eigenen Update-Zeitplan. Die Benachrichtigungsfrist für SaaS ist nicht großzügig. Wer die Plugin-Kompatibilität noch nicht geprüft hat, sollte das jetzt tun — bevor die Benachrichtigung eintrifft. Plugins mit Admin-UI haben dabei Priorität — der Webpack→Vite-Wechsel sorgt dafür, dass inkompatible Plugins unmittelbar nach dem Update sichtbar versagen.

Self-hosted auf 6.6 LTS

Wer auf 6.6 ist, hat Optionen. Shopware 6.6 ist LTS, also ungefähr zwei Jahre Sicherheits-Patches. Es besteht keine Dringlichkeit, heute auf 6.7 zu wechseln. Die Entscheidung hängt ab von:

  • Redis: Bereits auf dem Server vorhanden? Das Upgrade wird deutlich einfacher. Noch nicht vorhanden? Das gehört zum Scope und Zeitplan — das ist Infrastrukturarbeit, kein reines Composer-Update.
  • Plugin-Anzahl und -Typ: Fünf oder weniger Marketplace-Plugins, keine eigenen Admin-Plugins: geringes Risiko. Eigene Admin-Plugins, besonders ältere: pro Plugin erheblichen Aufwand einplanen.
  • Payment-Anpassungen: Wer eigene Payment-Handler hat, muss diese umschreiben, um AbstractPaymentHandler zu erweitern. Das ist nicht optional und keine kleine Änderung — entsprechend budgetieren.

Das ehrliche Entscheidungs-Framework

Diese Liste durchgehen:

  1. Redis: vorhanden und 7.0+?
  2. Plugins mit Admin-UI zählen. Für jedes: gibt es eine 6.7-kompatible Version?
  3. Gibt es eigene Payment- oder Shipping-Handler?
  4. Gibt es Varnish/Nginx-Cache-Konfiguration für den Storefront?

Wenn alle Antworten positiv sind, liegt der Aufwand wahrscheinlich im Rahmen einer intensiven Arbeitswoche. Wenn mehrere „Nein” oder „Unbekannt” auftauchen, steigt die Schätzung. Erst prüfen, dann schätzen.

Der Admin-Umbau

Hier liegt die meiste Arbeit für Plugin-Entwickler. Drei Änderungen, die je eine explizite Migration erfordern.

Webpack → Vite

Das Admin-Build-System wechselte in 6.7 von Webpack zu Vite. Die Build-Zeit für ein typisches Plugin sank von ca. zwei Minuten auf unter zwanzig Sekunden — eine echte Verbesserung. Aber nicht ohne Kosten.

Was kaputt geht: Jedes Plugin mit einer webpack.config.js im Administration-Verzeichnis baut nicht mehr. Die Webpack-Konfiguration wird von der neuen Toolchain schlicht ignoriert.

Was sich ändert: webpack.config.js durch vite.config.mts in src/Resources/app/administration/src/ ersetzen:

// vite.config.mts
import { defineConfig } from 'vite';

export default defineConfig({
    build: {
        lib: {
            entry: './src/main.js',
            formats: ['iife'],
            name: 'MyPlugin',
        },
    },
});

Die genaue Konfiguration variiert je nach Plugin-Komplexität. Shopwares offizielle Migrationsanleitung deckt das vollständige Vite-Setup ab.

Das Versions-Split-Problem: Shopware 6.6 nutzt Webpack, 6.7 nutzt Vite. Diese sind nicht kompatibel. Wer ein Plugin für beide Versionen pflegt, braucht separate Releases — ein 6.6-Paket, ein 6.7-Paket. Es gibt keine Einzelkonfiguration, die korrekt für beide Toolchains kompiliert. Plugin-Versionen entsprechend benennen und separate Pakete veröffentlichen.

Vuex → Pinia: Abgeschlossen

In 6.6 begann Shopware, interne Stores von Vuex zu Pinia zu migrieren. In 6.7 sind Shopwares eigene interne Stores vollständig zu Pinia migriert. Shopware.State ist in 6.7 mit Konsolen-Warnungen als deprecated markiert und wird in 6.8 entfernt. Vuex-Stores von Drittanbietern funktionieren in 6.7 weiterhin, sollten aber jetzt migriert werden, um 6.8-Fehler zu vermeiden. Alles sollte über Shopware.Store laufen.

Die API-Änderung ist unkompliziert, erfordert aber Anpassungen an jeder Stelle, die den State liest oder schreibt:

// Vorher (Vuex / 6.6 und früher)
Shopware.State.registerModule('myStore', {
    state: {},
    getters: {},
    mutations: {},
    actions: {}
});
Shopware.State.get('myStore');

// Nachher (Pinia / 6.7)
Shopware.Store.register('myStore', {
    state: () => ({}),   // state MUSS eine Funktion sein in Pinia
    getters: {},
    actions: {}          // Mutations sind weg — Logik direkt in Actions
});
Shopware.Store.get('myStore');

Drei Dinge zu verinnerlichen:

  1. state muss eine Funktion sein, die ein Objekt zurückgibt. Ein direktes Objekt funktioniert nicht.
  2. Mutations sind komplett weg. In Pinia gibt es kein Mutations-Konzept. Logik, die in Mutations lag, kommt in Actions.
  3. Das registerModule/get-Muster entspricht sauber register/get — aber die gesamte Codebase nach Shopware.State durchsuchen, um alles zu finden, was aktualisiert werden muss.

Die Codemods können hier helfen (siehe Abschnitt Automatisierte Tools).

sw-* → mt-* jetzt erzwungen

Die Deprecation der sw-*-Komponenten begann bereits in 6.6. In 6.7 fungieren sie als dünne Wrapper um mt-*-Komponenten und funktionieren weiterhin, erzeugen aber Konsolen-Warnungen. Sie sind in 6.7 nicht entfernt — die Entfernung ist für 6.8 oder später geplant. Alle neuen Entwicklungen und alle migrierten Plugins sollten mt-*-Komponenten verwenden.

Die Schnellreferenz:

Alte KomponenteNeue KomponenteHinweis
sw-cardmt-card
sw-buttonmt-button
sw-text-fieldmt-text-field
sw-checkbox-fieldmt-checkboxName verkürzt
sw-select-fieldmt-selectName verkürzt
sw-switch-fieldmt-switchNicht mt-switch-field

Das sind keine reinen Umbenennungen — Prop-Namen, Slot-Strukturen und Event-Namen haben sich ebenfalls geändert. Die Codemods übernehmen den Großteil, aber das Ergebnis im Browser verifizieren.

Offiziellen Codemod ausführen:

composer run admin:code-mods -- --plugin-name MyPlugin --fix -v 6.7

Dieser übernimmt die sw-* → mt-*-Umbenennung und die Pinia-Migration in einem Durchlauf. Ausführen, dann das Diff sorgfältig prüfen, bevor committet wird.

Vue-2-Compat: Vollständig entfernt

Die Vue-2-Kompatibilitätsschicht, die mit Vue 3 in 6.6 ausgeliefert wurde, ist in 6.7 komplett weg.

$tc() deprecated. Die Plural-Übersetzungsfunktion $tc() war in 6.6 deprecated. In 6.7 ist sie weiterhin vorhanden, bildet intern auf $t() ab und gibt eine Warnung aus — sie wird in 6.8 entfernt. Einige erweiterte Overloads verhalten sich im zugrunde liegenden vue-i18n v10 anders. Alle Vorkommen jetzt durch $t() ersetzen, um 6.8-Fehler zu vermeiden:

// Vorher
this.$tc('my.translation.key', count)

// Nachher
this.$t('my.translation.key', { count })

Async-Komponenten sind jetzt Standard. Code, der synchrone Komponentenauflösung voraussetzte und unmittelbar nach einem Render-Aufruf auf Component-Refs zugegriffen hat, muss await nextTick() hinzufügen oder so umstrukturiert werden, dass auf das Mounten der Komponente gewartet wird.

@vue:mounted verwenden statt Komponenteninstanzen synchron nach DOM-Einfügung anzusprechen. Das alte Muster, eine Ref zu setzen und im gleichen Tick sofort zu lesen, gibt undefined zurück.

Caching-Architektur-Änderungen

Die Caching-Schicht in 6.7 ist grundlegend anders. Wer im Shop eigene Caching-Logik, Reverse-Proxy-Konfiguration oder Plugins hat, die vom Timing der Cache-Invalidierung abhängen, sollte diesen Abschnitt sorgfältig lesen.

Delayed Invalidation ist jetzt Standard

In 6.6 und früher invalidierte das Bearbeiten einer Entität im Admin (Produkt, Kategorie, CMS-Block) die entsprechenden HTTP-Cache-Einträge sofort. In 6.7 ist die Invalidierung verzögert.

Standardmäßig wird der Cache alle fünf Minuten durch einen Scheduled Task invalidiert. Das ist beabsichtigt: Es verbessert die Cache-Hit-Rate für stark frequentierte Shops dramatisch, indem ein einzelnes Admin-Speichern nicht mehr einen großen Teil der gecachten Seiten ungültig macht.

Auswirkung auf eigene Plugins: Jedes Plugin, das auf „Speichern im Admin → sofort im Storefront sichtbar”-Verhalten angewiesen war, wirkt in 6.7 fehlerhaft. Die Seite aktualisiert sich, aber mit bis zu fünf Minuten Verzögerung.

Bei Bedarf nach sofortiger Invalidierung für spezifische Anwendungsfälle gibt es zwei Optionen:

  1. InvalidateHttpCacheTask nach dem Entitäts-Update manuell auslösen
  2. sw-force-cache-invalidate: 1 im HTTP-Header senden, um die Verzögerung für eine spezifische Anfrage zu umgehen

Sofortige Invalidierung nicht global auslösen — das macht die Performance-Verbesserung zunichte.

Redis ist Pflicht

Für Multi-Server- oder Load-Balanced-Produktivumgebungen ist Redis effektiv erforderlich für korrektes Session- und Cache-Sharing. Einzelserver-Setups können technisch ohne Redis laufen, Redis wird jedoch unabhängig von der Serveranzahl dringend empfohlen.

Wichtig: Wenn Redis im Einsatz ist, muss die php-redis-PHP-Erweiterung Version 6.1 oder höher sein — das ist eine harte Anforderung durch Symfony 7.4’s Composer-Abhängigkeiten.

Redis vor dem Upgrade bereitstellen. Das ist nichts, was man mitten in der Migration erledigt — wer mitten im Update-Prozess feststellt, dass Redis nicht verfügbar ist, hat ein Problem. Server-Umgebung zuerst prüfen.

Store-API-Route-Cache entfernt

Das ist eine erhebliche Breaking Change für alle Plugins, die die gecachten Store-API-Routen erweitern. Alle Cached*Route-Klassen sind weg:

  • CachedProductRoute
  • CachedCategoryRoute
  • CachedNavigationRoute
  • CachedProductListingRoute
  • Und alle anderen nach diesem Muster

Plugins, die diese Klassen erweiterten — um Daten zu injizieren, Cache-Tags hinzuzufügen oder die gecachte Antwort zu modifizieren — werfen in 6.7 einen Class-not-found-Fehler. Der Ersatz ist HTTP-Level-Caching statt Application-Level-Route-Caching.

Cache-Tags direkt auf die HTTP-Responses setzen und den Reverse-Proxy so konfigurieren, dass er diese berücksichtigt.

Storefront-Header und Footer werden jetzt über Edge Side Includes (ESI) unter /_esi/global/header und /_esi/global/footer geladen. Sie sind separat gecacht und werden auf HTTP-Ebene zusammengesetzt.

Anforderungen: ESI-Unterstützung muss auf der HTTP-Schicht aktiviert sein — Symfony HttpCache, Nginx oder Varnish. Ohne ESI-Unterstützung im Deployment werden Header und Footer nicht gerendert.

Plugin-Auswirkung: Plugins, die Daten via GenericPageLoader in den Seiten-Header oder Footer injizierten, haben keinen funktionierenden Pfad mehr für Header/Footer-Inhalte. Injektionen zu HeaderPageletLoader oder FooterPageletLoader verschieben.

Reverse-Proxy-Konfiguration: Wer Varnish nutzt, muss von der alten Redis-Ban-Methode auf XKey-basiertes Cache-Tagging wechseln. Shopwares Dokumentation zum 6.7 Hosting Guide enthält die aktualisierte VCL-Konfiguration.

PHP- und Backend-Änderungen

Native Typen auf allen Properties

Shopware 6.7 hat allen Core-Klassen-Properties native PHP-Typdeklarationen hinzugefügt. Das verbessert die Typsicherheit der gesamten Codebase — ist aber eine Breaking Change für jedes Plugin, das Core-Klassen ohne passende native Typdeklarationen erweitert.

Wenn eine Plugin-Klasse eine Shopware-Klasse erweitert und die Property-Deklarationen nicht übereinstimmen, gibt es zur Laufzeit einen Fatal Error. PHP erlaubt keiner Child-Klasse, eine untypisierte Property zu haben, wo der Parent einen nativen Typ deklariert hat.

Fix: Jede Klasse im Plugin, die eine Shopware-Klasse erweitert, prüfen. Native Typdeklarationen exakt anpassen.

// Core in 6.7 (vereinfachtes Beispiel)
class ProductEntity extends Entity
{
    protected ?string $name = null;
    protected float $price = 0.0;
}

// Das Plugin, das es erweitert — Typen müssen übereinstimmen
class MyProductEntity extends ProductEntity
{
    protected ?string $myCustomField = null; // in Ordnung
    // protected $myCustomField = null;      // Fatal Error in PHP 8.2+
}

DBAL 4, PHPUnit 11, Dompdf 3

Drei Abhängigkeits-Upgrades mit eigenen Breaking Changes:

DBAL 4: Die SchemaManager-API hat sich geändert. Wer im Plugin eigenes Datenbank-Schema-Management hat (Migration-Klassen, Schema-Updates), sollte den DBAL-4-Changelog prüfen. Die Fremdschlüssel-Namenskonvention änderte sich von fk.<table>.<col> zu fk__<table>__<col> — Migrationen, die FK-Namen als Strings referenzieren, müssen aktualisiert werden.

PHPUnit 11: Test-Methodensignaturen haben sich geändert. Plugin-Unit-Tests brauchen wahrscheinlich Anpassungen bei setUp-Methoden-Signaturen, Assertion-Methodennamen und Data-Provider-Syntax. Das ist mechanische Arbeit, aber Pflicht, wenn Tests Teil der Deploy-Pipeline sind.

Dompdf 3: Wer im Shop oder in Plugins PDF-Dokumente generiert — Rechnungen, Lieferscheine, Gutschriften — muss diese alle nach dem Upgrade testen. Dompdf 3 hat Rendering-Änderungen, die das Layout beeinflussen können. Das sollte nicht im Produktivbetrieb entdeckt werden.

Payment-Handler-Umbau

Das ist die erheblichste PHP-Level-Änderung in 6.7 für Shops mit eigenen Payment-Integrationen.

Alle bisherigen Payment-Handler-Interfaces sind deprecated und wurden durch AbstractPaymentHandler ersetzt:

  • AsyncPaymentHandlerInterface
  • SyncPaymentHandlerInterface
  • PreparedPaymentHandlerInterface
  • RefundPaymentHandlerInterface
  • RecurringPaymentHandlerInterface

Das neue Muster: AbstractPaymentHandler erweitern und den einzelnen Service-Tag shopware.payment.method verwenden. Der spezifische Handler-Typ (sync, async, etc.) wird durch die implementierten Methoden bestimmt, nicht durch das implementierte Interface.

Zusätzlich benötigen alle Payment-Methoden und Shipping-Methoden jetzt einen technicalName. Für bestehende Methoden ohne einen solchen weist Shopwares Migration automatisch einen temporary_<id>-Wert zu — diese sollten durch aussagekräftige Bezeichner ersetzt werden, um spätere Verwirrung zu vermeiden.

Wer auf ein von Dritten gewartetes Payment-Plugin angewiesen ist, explizit prüfen, dass es für 6.7 aktualisiert wurde. Veraltete Payment-Plugins verursachen Checkout-Fehler.

OAuth und API-Änderungen

OAuth-Scopes müssen jetzt als durch Leerzeichen getrennte Strings übergeben werden. Wer Scopes als Array in OAuth-Requests übergibt, erhält in 6.7 Fehler. Auf das String-Format aktualisieren: 'write read openid'.

/api/oauth/authorize entfernt. Code oder Integrationen, die diesen Endpunkt direkt ansprechen, müssen aktualisiert werden. Die Shopware-6.7-API-Dokumentation enthält den Ersatz-Flow.

Customer-Entity: Assoziationen werden in Store-API-Responses standardmäßig nicht mehr eager-geladen (Performance-Verbesserung). Code, der davon ausging, dass verknüpfte Daten ohne explizite Criteria vorhanden sind, muss die relevanten Assoziationen explizit zu den Criteria hinzufügen.

Many-to-many DAL: Fehlende Fremdschlüssel-Felder in Entity-Definitionen werfen jetzt Hard Exceptions statt stille Warnungen zu loggen. Eigene Many-to-many-Entity-Definitionen mit unvollständigen Feld-Deklarationen schlagen in 6.7 zur Laufzeit fehl.

Storefront- und Template-Änderungen

ESI-Konsequenzen für Plugins

Da Header und Footer zu ESI gewechselt sind, stellt GenericPageLoader keine Header- oder Footer-Daten mehr als Teil des Haupt-Seitenladens bereit. Plugins, die GenericPageLoader zur Dateninjektion in Header oder Footer nutzten, müssen zu HeaderPageletLoader oder FooterPageletLoader wechseln.

ErrorTemplateStruct hat auch keine header- und footer-Properties mehr — Fehlerseiten (404, 500 etc.) rufen diese separat ab. Plugins, die Fehler-Templates anpassen und diese Properties referenzieren, müssen entsprechend aktualisiert werden.

Barrierefreiheits-Standards

Mehrere Barrierefreiheits-Verbesserungen, die in 6.6 hinter dem ACCESSIBILITY_TWEAKS-Feature-Flag lagen, sind in 6.7 Standard. Das betrifft die HTML-Struktur auf eine Weise, die CSS-Selektoren brechen kann:

.product-image-link-Anker entfernt. Produktlisting-Bilder haben keinen separaten Anker mehr, der das Bild umhüllt. Der Produktname-Link verwendet stattdessen ein stretched-link-Muster. CSS-Regeln, die .product-image-link ansprechen, haben keine Wirkung.

Basis-Schriftgröße ist jetzt 1rem (16px). Das ist eine Browser-Standard-Angleichung — aber Themes, die mit pixelbasierter Größenangabe aufgebaut wurden und eine andere Root-Schriftgröße voraussetzten, können Layout-Regressionen haben. Theme gegen die geänderte Basis prüfen.

Sprach- und Währungsumschalter nutzen jetzt <button>-Elemente statt <a>. CSS oder JavaScript, das diese als Anker anspricht, muss aktualisiert werden.

<ul>/<li> für Warenkorb- und Bestellpositionen. Warenkorb- und Bestellpositionslisten nutzen jetzt semantisches Listen-Markup. CSS, das die alte <div>-Struktur anspricht, trifft diese Elemente nicht mehr.

Custom-Field-Namen

Custom-Field-Namen dürfen keine Bindestriche oder Punkte mehr enthalten. Diese Zeichen verursachen Twig-Template-Fehler, weil die Feldnamen direkt als Twig-Variablennamen verwendet werden, und Twig erlaubt keine Bindestriche oder Punkte in Variablenbezeichnern.

Wer unter 6.6 (oder früher) Custom Fields mit Namen wie mein-custom-feld oder mein.custom.feld erstellt hat, verursacht damit in 6.7 Twig-Rendering-Fehler. Diese in Underscores umbenennen: mein_custom_feld.

Der Upgrade-Prozess: Schritt für Schritt

Diese Reihenfolge existiert aus gutem Grund. Nicht umordnen.

  1. Kompatibilitätsprüfung zuerst:

    shopware-cli project upgrade-check

    Das scannt die Installation gegen die 6.7-Kompatibilitätsmatrix und listet auf, was kaputt gehen wird, bevor irgendetwas angefasst wird. Die gesamte Ausgabe lesen.

  2. Server-Umgebung aktualisieren:

    • PHP 8.2+ (8.3 empfohlen)
    • Node.js 20+
    • Redis 7.0+

    Das vor dem Shopware-Update erledigen. Umgebungs- und Anwendungsänderungen im gleichen Schritt verschleiern, welche der beiden ein Problem verursacht hat.

  3. Redis bereitstellen, falls noch nicht vorhanden. In framework.yaml oder .env als Cache-Adapter eintragen.

  4. Standard-Shopware-Theme allen Sales Channels zuweisen, die ein vollständig individuelles Theme ohne Vererbung vom Shopware-Standard nutzen. Das verhindert Theme-Kompilierungsfehler während des Upgrades.

  5. UPGRADE-6.7.md im Shopware-GitHub-Repository lesen. Das ist die Quelle der Wahrheit, nicht dieser Beitrag. Jede Breaking Change, die Shopware bekannt ist, ist dort dokumentiert.

  6. Wartungsmodus aktivieren:

    bin/console sales-channel:maintenance:enable --all

  7. composer.json auf 6.7 anpassen und ausführen:

    composer update --no-scripts

  8. Symfony-Flex-Recipe-Updates anwenden:

    composer recipes:update

    Das Diff sorgfältig prüfen. Nicht alle Updates blind akzeptieren — einige könnten angepasste Konfigurationen überschreiben.

  9. Datenbank-Vorbereitungsschritt ausführen:

    bin/console system:update:prepare

  10. Update-Abschlussschritt ausführen:

    bin/console system:update:finish

  11. Admin-Plugins migrieren: Die Vite-Konfiguration anwenden, die Pinia-State-Migration durchführen und mt-*-Codemods für jedes Plugin mit Admin-UI ausführen.

  12. Alle Assets neu bauen:

    bin/console theme:compile && bin/console assets:install && bin/console cache:clear

  13. Gründlich testen:

    • Admin: jedes Modul öffnen, das Plugins hinzufügen oder modifizieren
    • Storefront: vollständiger Ablauf Durchsuchen → Warenkorb → Checkout
    • Payments: jede aktive Zahlungsmethode Ende-zu-Ende testen
    • PDFs: Rechnung, Lieferschein, Gutschrift generieren
    • ESI: prüfen, ob Header und Footer korrekt gerendert werden
    • Caching: prüfen, ob Seiten nach Cache-Leerung korrekt angezeigt werden

  14. Wartungsmodus deaktivieren:

    bin/console sales-channel:maintenance:disable --all

Automatisierte Tools

Vieles davon muss nicht manuell erledigt werden.

shopware-cli project upgrade-check — Vor allem anderen ausführen. Scannt die Installation gegen die 6.7-Kompatibilitätsmatrix und listet auf, was kaputt gehen wird. Die Ausgabe prägt den gesamten Migrationsaufwand.

shopware-cli extension validate ./path/to/plugin --full — Detaillierte Validierung eines spezifischen Plugins. Nützlich nach Änderungen, um zu prüfen, ob das Plugin Shopwares Prüfungen besteht, bevor das vollständige Upgrade ausgeführt wird.

Offizielle Codemods — Automatisiert die sw-* → mt-*-Umbenennung und die Vuex→Pinia-Migration in einem Befehl:

composer run admin:code-mods -- --plugin-name MyPlugin --fix -v 6.7

Ausführen, dann das Diff lesen. Er übernimmt den Großteil der Komponenten-Umbenennungen und State-API-Änderungen, deckt aber nicht alle Edge Cases ab. Manuelle Überprüfung nach dem Codemod ist Pflicht.

Rector für PHP — Bei mehreren Plugins oder einer großen PHP-Codebase kann Rector native Typ-Hinzufügungen, Klassen-Umbenennungen und Methodensignatur-Updates für die PHP-Level-Breaking-Changes automatisieren. Mit Shopwares Rector-Regeln aus dem shopware/shopware-rector-Paket konfigurieren.

Twig-Block-Versioning (PHPStorm-Plugin) — Wer Core-Twig-Blöcke im Storefront überschreibt: Dieses Plugin verfolgt Upstream-Block-Änderungen und gibt Hinweise, wenn ein überschriebener Block im Core geändert wurde. Nützlich, um defekte Template-Überschreibungen zu erkennen, ohne jeden Block manuell zu vergleichen.

Häufige Fragen

Kann ich 6.6 überspringen und direkt auf 6.7 aktualisieren?

Technisch ja — Shopware erlaubt Versions-Sprünge. Aber die Breaking Changes aus 6.6 entfallen dadurch nicht: die Vue-3-Migration, die all.js-Entfernung, das Symfony-7-Upgrade und die entfernten deprecated PHP-APIs gelten alle auch in 6.7. Gleichzeitig die Probleme zweier Releases debuggen, mit weniger Referenzpunkten. Ohne spezifischen Grund: erst 6.6, stabilisieren, dann 6.7 als separates Projekt.

Ist Redis in 6.7 Pflicht?

Für Multi-Server- oder Load-Balanced-Produktivumgebungen ja — Redis ist effektiv für korrektes Session- und Cache-Sharing erforderlich. Einzelserver-Setups können technisch ohne Redis laufen, Redis wird aber unabhängig davon dringend empfohlen. Wenn Redis im Einsatz ist, muss die php-redis-Erweiterung 6.1+ sein – bedingt durch eine Symfony-7.4-Anforderung. Vor dem Upgrade bereitstellen.

Werden Shopware-Cloud-Shops (SaaS) automatisch auf 6.7 aktualisiert?

Bei Shopwares SaaS-(cloud-gehostetem) Deployment ja — Shopware steuert den Update-Zeitplan. Rise, Evolve und Beyond sind kommerzielle Plan-Tiers, die jeweils als SaaS, PaaS oder Self-hosted betrieben werden können. Nur das SaaS-Deployment-Modell wird von Shopware automatisch aktualisiert. Praktisch bedeutet das: weniger Reaktionszeit als erwartet. Plugin-Kompatibilität jetzt prüfen — bevor die Update-Benachrichtigung eintrifft. Plugins mit Admin-UI sind der Fokuspunkt, weil der Webpack→Vite-Wechsel inkompatible Admin-Plugins sofort sichtbar für das Team scheitern lässt.

Brauchen Plugins separate Versionen für 6.6 und 6.7?

Ja, für alle Plugins mit Admin-UI. Der Webpack→Vite-Wechsel im Admin-Build-System ist nicht rückwärtskompatibel. Ein Plugin, das für Shopware 6.6’s Webpack-Pipeline kompiliert wurde, lädt in 6.7’s Vite-Pipeline nicht korrekt — und umgekehrt. Es werden separate Plugin-Releases für jede Major-Version benötigt. Plugin-Entwickler sollten Releases klar versionieren und beide Pakete veröffentlichen.

Wie es weitergeht

Mit der Prüfung beginnen. shopware-cli project upgrade-check auf der Installation ausführen, danach manuell jedes Plugin mit Admin-UI prüfen. Diese Ausgabe bestimmt alles weitere zu Scope und Zeitplan.

Wer die 6.5 → 6.6 Migration noch nicht gemacht hat und diesen Änderungen zum ersten Mal begegnet: der 6.5-auf-6.6-Migrationsleitfaden deckt die Vue-3-Admin-Migration, die all.js-Entfernung und die Symfony-7-Änderungen ausführlich ab — die gelten weiterhin, wenn von 6.5 gesprungen wird.

Für Kontext zu Shopwares Aufbau und was tatsächlich läuft, bevor Änderungen vorgenommen werden, ist die Shopware-6-Plattformübersicht ein nützlicher Einstieg.

Wer eine konkrete Migration plant und eine zweite Meinung zum tatsächlichen Scope möchte — gerne melden. Die Einschätzung orientiert sich am Code, nicht an dem, was angenehm zu hören wäre.

An einem Shopware-Projekt beteiligt?

Ich stehe für Beratung, Entwicklung und Code-Reviews zur Verfügung. Schreib mir.

Ähnliche Artikel