Migration von Shopware 6.5 auf 6.6: Was wirklich kaputt geht

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

Das häufigste Fehlerbild in 6.6 hat nichts mit PHP zu tun. Es ist ein weißer Leerbildschirm im Admin, verursacht durch Vue-2-Muster, die Vue 3 entweder entfernt hat oder lautlos ignoriert. Dieser Leitfaden deckt alle Breaking Changes ab – Frontend und Backend – und zeigt einen schrittweisen Prozess, um sie ohne böse Überraschungen zu bewältigen.

Warum 6.6 anders war

Shopware-6-Minor-Releases sind normalerweise inkrementell. APIs werden als veraltet markiert, nicht entfernt. Twig-Templates verschieben sich leicht. Man aktualisiert, leert den Cache, behebt ein oder zwei Dinge und macht weiter. Das war jahrelang der Rhythmus.

6.6 hat diesen Rhythmus gebrochen.

Mehrere große Änderungen kamen gleichzeitig: eine vollständige Migration der Admin-Oberfläche von Vue 2 auf Vue 3, ein Symfony-7-Upgrade, die Entfernung von all.js aus dem Storefront-Build-System und ein Haufen zuvor als veraltet markierter PHP-APIs, die ihr Entfernungsdatum erreicht hatten. Jede einzelne davon hätte 6.6 zu einem bedeutenden Release gemacht. Alle zusammen machen es zum störendsten Shopware-Upgrade seit Jahren.

Das Ergebnis: Ein Plugin, das in 6.5 einwandfrei funktionierte, konnte in 6.6 einen weißen Bildschirm anzeigen, ohne dass sich eine einzige PHP-Zeile geändert hatte. Die Frontend-Logik war das Problem, und wenn man nicht explizit auf Vue-3-Kompatibilität geprüft hatte, gab es keine Möglichkeit, das zu wissen, bis man das Update durchführte.

Die richtige Erwartungshaltung: Das ist kein triviales Upgrade. Wenn Sie Plugins haben, die die Admin-Oberfläche berühren – ob aus dem Shopware Store gekauft oder von Ihrer Agentur entwickelt – setzen Sie voraus, dass diese überprüft werden müssen. Nehmen Sie keine Kompatibilität an.

Was sich geändert hat: Überblick

KategorieUmfangAuswirkung
SystemanforderungenPHP 8.2+, MariaDB 10.11+, Redis 7.0+Gering–Mittel
Admin: Vue 2 → Vue 3Alle Admin-Vue-KomponentenHoch für Plugins mit Admin-UI
Admin: SDK-Paket umbenanntadmin-extension-sdk → meteor-admin-sdkMittel für Admin-Erweiterungen
Admin: vue-meta entferntHead-Management in Admin-ViewsGering (hoch, wenn Ihr Plugin es verwendet)
Admin: Vuex → PiniaShopware-Store-Migrationen beginnenGering–Mittel
Admin: Meteor-Komponentenbibliothekmt-*-Komponenten eingeführtGering — sw-* funktioniert in 6.6 noch
PHP/Backend: Symfony 7Alle Symfony-Pakete aktualisiertMittel — abhängig von Ihrer Nutzung
PHP/Backend: Veraltete APIs entferntDiverse Services, Typen, MethodensignaturenMittel — abhängig von Ihrer Nutzung
Storefront: all.js entferntPlugin-JS-Build-Modell geändertHoch für Plugins mit Storefront-JS
Storefront: Template-ÄnderungenHTML-Struktur, Twig-Variablen umbenanntGering–Mittel

Die Vue-3-Migration

Das ist die größte Quelle für Probleme in 6.6 und die, die am ehesten überrascht, wenn man die Plugins nicht selbst geschrieben hat.

Was Vue 3 wirklich ändert

Die Options API funktioniert in Vue 3 noch. Wenn Sie eine einfache Plugin-Komponente mit data(), computed, methods und Standard-Lifecycle-Hooks haben, übersteht sie das größtenteils. Die Probleme kommen von Mustern, die Shopware und das Vue-2-Ökosystem intensiv verwendeten – Muster, die Vue 3 entweder entfernt oder grundlegend geändert hat.

this.$set() ist weg. In Vue 2 benötigte man this.$set(obj, 'key', value), um neue Eigenschaften reaktiv zu machen. Das Reaktivitätssystem von Vue 3 basiert auf Proxies – es braucht das nicht. Jedes Plugin, das this.$set() aufruft, wirft einen Laufzeitfehler.

$listeners wurde in $attrs integriert. In Vue 2 waren Event-Listener von Attributen getrennt. In Vue 3 sind sie unter $attrs vereint. Jede Komponente, die explizit auf this.$listeners verweist, wird brechen.

v-model-Semantik hat sich geändert. Dieses ist subtil, aber weit verbreitet. In Vue 2 sendet v-model bei einer benutzerdefinierten Komponente input aus und bindet an eine Prop namens value. In Vue 3 sendet es update:modelValue aus und bindet an modelValue. Wenn Ihr Plugin benutzerdefinierte Eingabekomponenten hat, ist das fast sicher kaputt.

Vue-Filter wurden entfernt. Kein {{ price | currency }} mehr in Templates. Stattdessen sind berechnete Eigenschaften oder Methoden erforderlich.

Lifecycle-Hooks wurden umbenannt:

  • beforeDestroy → beforeUnmount
  • destroyed → unmounted

Diese schlagen lautlos fehl – der Hook wird einfach nicht ausgeführt. Das ist die schlimmste Art von Bruch: kein Fehler, nur fehlendes Verhalten.

this.$children wurde vollständig entfernt. Es existiert in Vue 3 nicht mehr. this.$parent existiert noch, aber die Komponenteninstanzstruktur hat sich geändert. Jedes Plugin, das den Komponentenbaum auf diese Weise traversiert, wirft einen Fehler oder verhält sich unerwartet. Der korrekte Ansatz ist provide/inject.

Shopware-spezifisch: Komponentenregistrierung

Shopware hat eine eigene Schicht über Vue für die Registrierung und den Aufbau von Komponenten. In 6.5 sähe man typischerweise:

Shopware.Component.register('my-plugin-component', {
    template,
    // ...component options
});

In 6.6 haben sich die internen Abläufe, wie diese Komponenten aufgebaut und erweitert werden, geändert. Wenn Sie bestehende Shopware-Komponenten überschreiben (üblich bei Admin-Plugins), prüfen Sie, ob Shopware.Component.build() und die Override-Muster noch korrekt aufgelöst werden.

Admin-SDK-Paket umbenannt

Das Extension-SDK-Paket wurde in 6.6 umbenannt:

Vorher: @shopware-ag/admin-extension-sdk
Nachher: @shopware-ag/meteor-admin-sdk

Aktualisieren Sie Ihre package.json und alle Import-Pfade. Die API ist weitgehend gleich geblieben – das ist meist ein Suchen-und-Ersetzen in Ihren JS-Dateien – aber es ist eine harte Anforderung: Das alte Paket wird für 6.6+ nicht mehr gepflegt.

npm uninstall @shopware-ag/admin-extension-sdk
npm install @shopware-ag/meteor-admin-sdk@^4.0.0

Aktualisieren Sie dann Ihre Imports:

// Vorher
import { ... } from '@shopware-ag/admin-extension-sdk';

// Nachher
import { ... } from '@shopware-ag/meteor-admin-sdk';

vue-meta entfernt

Das vue-meta-Paket wurde in 6.6 vollständig aus dem Admin entfernt. Wenn Ihr Plugin vue-meta verwendet, um Seitentitel oder Head-Tags in Admin-Views zu verwalten, wird es in 6.6 einen Fehler werfen. Der Ersatz sind die nativen Composition-API-Alternativen von Vue 3. In der Praxis ist das bei Drittanbieter-Plugins selten, aber es ist eine Überprüfung wert.

Vuex → Pinia

Shopware migriert seine eigenen Admin-Stores von Vuex zu Pinia, beginnend in 6.6. Dies ist ein laufender Prozess – der adminMenu-Store war einer der ersten, der wechselte (6.6.8.0). Für die meisten Plugins ist das gering wirkend, aber wenn Ihr Plugin direkt aus Shopwares eingebauten Vuex-Stores liest oder in sie schreibt (anstatt über die dokumentierte Store-API), achten Sie auf Brüche, da die Migration durch 6.6.x-Patch-Releases und in 6.7 hinein fortgesetzt wird.

Vorher und Nachher: Ein Komponenten-Override

Hier ein vereinfachtes Beispiel eines häufigen Admin-Komponentenmusters, das in 6.6 bricht:

Vorher (Vue 2 / Shopware 6.5):

// src/Resources/app/administration/src/component/my-order-filter/index.js
import template from './my-order-filter.html.twig';

Shopware.Component.register('my-order-filter', {
    template,

    props: {
        value: {
            type: String,
            default: '',
        },
    },

    data() {
        return {
            internalValue: this.value,
        };
    },

    beforeDestroy() {
        this.cleanup();
    },

    methods: {
        onInput(val) {
            this.$emit('input', val);
        },

        cleanup() {
            // teardown logic
        },
    },
});

Nachher (Vue 3 / Shopware 6.6):

// src/Resources/app/administration/src/component/my-order-filter/index.js
import template from './my-order-filter.html.twig';

Shopware.Component.register('my-order-filter', {
    template,

    props: {
        modelValue: {
            type: String,
            default: '',
        },
    },

    data() {
        return {
            internalValue: this.modelValue,
        };
    },

    beforeUnmount() {
        this.cleanup();
    },

    methods: {
        onInput(val) {
            this.$emit('update:modelValue', val);
        },

        cleanup() {
            // teardown logic
        },
    },
});

Drei Änderungen: Prop-Name, Emit-Event-Name, Lifecycle-Hook-Name. Fehlt in einem echten Plugin auch nur eine davon, führt das zu einem stillen Fehler oder einer kaputten Zwei-Wege-Bindung.

Die Meteor-Komponentenbibliothek

Shopware 6.6 führte die Meteor-Komponentenbibliothek ein – ein eigenständiges Design-System mit mt-*-präfixierten Komponenten, das perspektivisch die bestehenden sw-*-Admin-Komponenten ersetzen soll.

Das Wichtigste für eine 6.6-Migration: Ihre bestehenden sw-*-Komponenten funktionieren noch. Sie erzeugen in 6.6 keine Deprecation-Warnungen. Die formale Deprecation von sw-*-Komponenten (mit @deprecated-Tags und Konsolenwarnungen) ist ein 6.7-Thema, nicht ein 6.6-Thema.

Was das in der Praxis bedeutet: Sie müssen Ihre sw-*-Admin-Templates nicht als Teil eines 6.5 → 6.6-Upgrades migrieren. Ihre Plugins werden weiterhin funktionieren. Wenn Sie jedoch neue Admin-Komponenten schreiben oder eine bedeutende Überarbeitung durchführen, verwenden Sie von Anfang an mt-* – Sie müssen ohnehin migrieren, wenn Sie zu 6.7 kommen, und die neuen Komponenten sind besser.

Die Komponenten und ihre mt-*-Entsprechungen (zur Referenz, wenn Sie zu 6.7 kommen):

Alte KomponenteNeue Komponente
sw-cardmt-card
sw-buttonmt-button
sw-text-fieldmt-text-field
sw-number-fieldmt-number-field
sw-textarea-fieldmt-textarea-field
sw-select-fieldmt-select-field
sw-checkbox-fieldmt-checkbox-field
sw-switch-fieldmt-switch

Wenn es so weit ist, sind das keine einfachen Umbenennungen – Prop-Namen, Slot-Strukturen und Event-Namen haben sich ebenfalls geändert. sw-switch-field → mt-switch, nicht mt-switch-field. Ein globales Suchen-und-Ersetzen bringt Sie nicht sauber ans Ziel.

$tc() → $t(): In Shopware 6.6 wurde die $tc()-Übersetzungsfunktion zugunsten von $t() als veraltet markiert. Jedes Plugin-Template, das $tc('some.key') verwendet, funktioniert zwar, erzeugt aber Deprecation-Warnungen. Der Ersatz ist eine einfache Umbenennung in all Ihren Templates und JavaScript-Dateien.

PHP-Änderungen

Die PHP-Seite der 6.6-Migration ist real, aber vorhersehbarer als die Admin-Änderungen, vorausgesetzt, man hat in 6.5 die Hausaufgaben gemacht.

Die Systemanforderungen haben sich durchgehend geändert. Bevor Sie sonst irgendetwas anfassen, vergewissern Sie sich, dass Ihre Umgebung die neuen Mindestanforderungen erfüllt:

Abhängigkeit6.5 Minimum6.6 Minimum
PHP8.18.2
MariaDB10.410.11
Redis6.27.0

Wenn Sie verwaltete Infrastruktur betreiben, aktualisieren Sie diese vor dem Shopware-Upgrade – nicht gleichzeitig. PHP 8.2 hat eigene Deprecations eingeführt (dynamische Eigenschaften zum Beispiel), also führen Sie Ihren Plugin-Code gegen 8.2 in einer Testumgebung aus, bevor Sie Shopware selbst migrieren.

Symfony 7. Shopware 6.6 hat alle Symfony-Pakete auf Version 7 aktualisiert. Wenn Ihr Plugin Symfony-Komponenten direkt verwendet (Routing, Form, Security, Console usw.), prüfen Sie Symfonys eigenen 6→7-Migrationsleitfaden auf alles, was Ihren Code betrifft. Symfony 7 hat Typdeklarationen verschärft und mehrere lang veraltete Features entfernt. Das häufigste Plugin-Problem: Jeder Service, der eine Symfony-Klasse erweitert oder implementiert, bei der sich die Methodensignaturen geändert haben.

Veraltete APIs entfernt. Die Regel bei Shopware ist, dass in einem Minor-Release als veraltet markierte Methoden im nächsten entfernt werden. Wenn Sie 6.5 betrieben und Deprecation-Hinweise in Ihren Logs hatten – das sind jetzt harte Fehler in 6.6. Das ist eigentlich gute Praxis: Wenn Sie alle Ihre @deprecated-Warnungen in 6.5 behoben haben, ist das PHP-Upgrade weitgehend sauber. Wenn Sie sie ignoriert haben, gibt es Arbeit zu erledigen.

Häufige Bereiche, in denen ich Brüche gesehen habe:

  • EntityRepository-Methodensignaturen: Einige Parametertypen wurden verschärft oder geändert
  • Interne Service-IDs: Eine Handvoll Services wurde im Dependency-Injection-Container umbenannt oder umstrukturiert
  • Typisierte Methoden, bei denen mixed oder lose Typen verschärft wurden

Meine stärkste Empfehlung vor jeder 6.6-Migration: Führen Sie PHPStan gegen Ihre Custom-Plugins aus, während Sie noch auf 6.5 sind. Shopware liefert PHPStan-Konfiguration in vendor/shopware/core/dev-ops/, die veraltete API-Nutzung erkennt. Die Ausgabe zeigt Ihnen genau, was brechen wird, bevor Sie irgendetwas aktualisieren.

# PHPStan gegen Ihr Plugin ausführen (Pfad an Ihr Setup anpassen)
vendor/bin/phpstan analyse custom/plugins/YourPlugin/src/ --level=6

# Shopwares eigenes Regelset befindet sich im Core-Paket:
# vendor/shopware/core/dev-ops/phpstan/phpstan.neon
# Referenzieren Sie es in Ihrer phpstan.neon für Shopware-spezifische Deprecation-Regeln

Storefront-Änderungen

Die all.js-Entfernung (Hohe Auswirkung für Storefront-Plugins)

Diese Änderung überrascht Entwickler, weil sie nicht in der offensichtlichen Kategorie „Admin-Änderungen” liegt. In Shopware 6.5 kompilierte der Storefront das gesamte Plugin-JavaScript in ein einzelnes all.js-Bundle. In 6.6 ist dieses Bundle weg.

Was das bedeutet: Wenn Ihr Plugin JavaScript zum Storefront hinzufügt – ein benutzerdefinierter Slider, ein Tracking-Script, ein Produktkonfigurator – verlässt es sich darauf, automatisch in all.js aufgenommen zu werden. In 6.6 muss jedes Plugin sein eigenes JavaScript als separates Bundle in einem dist/-Verzeichnis kompilieren und bereitstellen.

Das neue Modell:

Vorher (6.5): alle Plugins → einzelnes all.js
Nachher (6.6): jedes Plugin → eigenes dist/storefront/js/plugin-name.js

Shopware verwendet jetzt ein Webpack-MultiCompiler-Setup, das das JS jedes Plugins separat baut. PluginManager.initializePlugins() ist jetzt asynchron, um das zu ermöglichen.

Die praktische Auswirkung: Ein Plugin mit Storefront-JavaScript, das nicht für 6.6 aktualisiert wurde, funktioniert lautlos nicht mehr – kein Fehler in den PHP-Logs, nur fehlendes JS-Verhalten in der Browser-Konsole. Prüfen Sie console.error in Ihrem Browser nach dem Upgrade auf PluginManager-Registrierungsfehler.

Was in Ihrem Plugin geändert werden muss:

  1. Stellen Sie sicher, dass Ihr JS-Einstiegspunkt sich unter src/Resources/app/storefront/src/main.js befindet (oder dem von Shopware erwarteten Einstiegspfad für Ihr Plugin entspricht)
  2. Führen Sie bin/console theme:compile aus – der Multi-Compiler baut das JS Ihres Plugins als separates Bundle
  3. Die kompilierte Ausgabe landet in src/Resources/app/storefront/dist/storefront/js/ – committen Sie dieses Verzeichnis oder stellen Sie sicher, dass Ihr Deployment-Prozess es generiert
  4. Führen Sie bin/console assets:install aus, um die kompilierten Assets für den Webserver zugänglich zu machen

Sie benötigen keine benutzerdefinierte webpack.config.js – Shopwares Theme-Compiler übernimmt den Build. Was Sie benötigen, ist die korrekte Dateistruktur, damit der Compiler Ihren Einstiegspunkt finden und bauen kann.

Außerdem: Direkte Imports aus PluginManager oder der Plugin-Basisklasse sind veraltet. Wechseln Sie zu asynchronen Plugin-Registrierungsmustern, bei denen der Plugin-Manager über das asynchrone Modulsystem verfügbar ist.

Template- und Markup-Änderungen

Einige Twig-Template-Variablen wurden umbenannt – prüfen Sie Shopwares UPGRADE.md für die vollständige Liste und aktualisieren Sie alle überschriebenen Templates. Zwei strukturelle Änderungen sind erwähnenswert:

  • Order-Items und Cart-Line-Items wurden von <div> auf <ul>/<li>-Elemente geändert – CSS, das diese direkt anspricht, wird brechen
  • Header und Footer werden jetzt via ESI (Edge Side Includes) geladen, was das Caching und jede Sub-Request-Kontextverarbeitung betrifft

Führen Sie nach der Aktualisierung aus:

bin/console theme:compile
bin/console cache:clear

Achten Sie sorgfältig auf die Kompilierungsausgabe. Kompilierungsfehler machen Template-Probleme sichtbar, bevor Ihre Kunden sie sehen. Wenn die Kompilierung erfolgreich ist, aber visuell etwas falsch aussieht, prüfen Sie auf undefinierte Twig-Variablen – diese schlagen lautlos fehl und werden als leere Strings gerendert.

Der Migrationsprozess: Schritt für Schritt

Ich habe genug davon gemacht, um zu wissen: Die Reihenfolge ist entscheidend. Nicht improvisieren.

  1. Zuerst Plugin-Kompatibilität prüfen – bevor Sie irgendetwas anfassen. Prüfen Sie für jedes installierte Plugin das Kompatibilitäts-Badge im Shopware Store für 6.6-Unterstützung. Für Custom-/Agentur-Plugins bedeutet das eine Code-Überprüfung gegen die Breaking-Changes-Liste.

  2. Aktualisieren Sie Ihre Serverumgebung auf Staging: PHP auf 8.2, MariaDB auf 10.11, Redis auf 7.0. Tun Sie das vor dem Shopware-Update – die Vermischung von Umgebungs- und Anwendungsänderungen verschleiert, welche der beiden etwas kaputt gemacht hat.

  3. Lesen Sie Shopwares offizielle UPGRADE.md für 6.6. Sie befindet sich im Shopware-Repository. Sie listet jeden Breaking Change. Das ist die Quelle der Wahrheit, nicht Blog-Posts (einschließlich dieses hier).

  4. Aktualisieren Sie das Admin-SDK-Paket, wenn Ihre Plugins es verwenden:

    npm uninstall @shopware-ag/admin-extension-sdk
npm install @shopware-ag/meteor-admin-sdk@^4.0.0

  5. Aktualisieren Sie Ihre composer.json-Einschränkung, um 6.6 zu erlauben: "shopware/core": "~6.6.0".

  6. Führen Sie composer update shopware/* aus – nur auf Staging. Nicht auf Produktion. Noch nicht.

  7. Führen Sie bin/console cache:clear aus unmittelbar danach.

  8. Öffnen Sie den Admin und prüfen Sie jede Seite, die Ihre Plugins betreffen. Klicken Sie durch. Schauen Sie sich nicht nur das Dashboard an. Öffnen Sie die spezifischen Module, die Ihre Plugins hinzufügen oder ändern.

  9. Prüfen Sie PHP-Fehlerprotokolle auf Fatals. Fatal-Fehler hier bedeuten PHP-seitige Brüche – entfernte APIs, Symfony-7-Inkompatibilitäten oder Typfehler.

  10. Beheben Sie Vue-2-Muster in Admin-Komponenten: $set, $listeners, v-model, Filter, Lifecycle-Hooks.

  11. Benennen Sie $tc() in $t() um in all Ihren Admin-Templates und JavaScript-Dateien, um Deprecation-Warnungen zu beseitigen.

  12. Prüfen Sie Storefront-JS-Plugins. Wenn ein Plugin Code in src/Resources/app/storefront/src/ hat, überprüfen Sie, ob es unter dem neuen Multi-Compiler-Modell kompiliert. Suchen Sie nach JS-Fehlern in der Browser-Konsole – fehlendes Storefront-Verhalten ohne PHP-Fehler ist das Kennzeichen eines all.js-Migrationsproblems.

  13. Bauen Sie alle Assets neu nach JS-/Template-Änderungen:

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

  14. Führen Sie Ihre Test-Suite aus. Wenn Sie keine automatisierten Tests für Ihre Custom-Plugins haben, ist diese Migration ein starkes Argument für das Schreiben solcher. Manuelle Tests in diesem Umfang übersehen Dinge.

  15. Deployen Sie auf Produktion in einem Wartungsfenster. Planen Sie es, kündigen Sie es an, haben Sie einen Rollback-Plan bereit.

Der Kompatibilitäts-Check: Was vor dem Start zu tun ist

Das Erste, was ich vor jeder 6.6-Migration mache, ist ein Plugin-Audit. So geht man dabei vor:

Für Shopware Store-Plugins: Das Kompatibilitäts-Badge ist auf der Store-Seite jedes Plugins sichtbar. Wenn es 6.6-Unterstützung zeigt, hat der Entwickler eine kompatible Version getestet und veröffentlicht. Aktualisieren Sie das Plugin zuerst, bevor Sie Shopware selbst aktualisieren.

Für Custom- oder Agentur-Plugins: Es gibt kein Badge. Sie müssen den Code überprüfen. Zwei Verzeichnisse zeigen das Risikoprofil:

  • src/Resources/app/administration/ — Admin-UI. Gehen Sie davon aus, dass Vue-3-Migrationsarbeit erforderlich ist.
  • src/Resources/app/storefront/src/ — Storefront-JavaScript. Die all.js-Entfernung kann das betreffen.

Ein Plugin ohne keines dieser Verzeichnisse ist für das 6.6-Upgrade höchstwahrscheinlich in Ordnung – reine PHP-Plugins sind nur den Änderungen durch veraltete APIs und Symfony 7 ausgesetzt. Ein Plugin mit Admin- oder Storefront-JS: Nehmen Sie an, dass Arbeit erforderlich ist, bis jemand es speziell gegen 6.6 verifiziert hat.

Bevor Sie die Migration planen, bitten Sie Ihre Agentur oder Ihren Entwickler schriftlich um einen Kompatibilitäts-Audit. Nicht „glauben Sie, dass es gut geht” – bitten Sie um eine spezifische Beurteilung jedes Admin-berührenden Plugins gegen die 6.6-Breaking-Changes-Liste. Das schützt Sie und erstellt eine Aufzeichnung dessen, was geprüft wurde.

Was ist mit 6.7?

Wenn Sie das lesen, nachdem Sie 6.6 gerade überlebt haben, oder wenn Sie Ihren weiteren Weg planen: 6.7 ist der Punkt, an dem die Meteor-Komponentenmigration obligatorisch wird. Die sw-*-Komponenten, die mt-*-Entsprechungen haben, sind in 6.7 formal veraltet – mit Konsolenwarnungen und @deprecated-Tags – und die PHP-Mindestversion steigt auf 8.3.

Die gute Nachricht: Der Sprung von 6.6 auf 6.7 ist deutlich kleiner als von 6.5 auf 6.6. Die architekturellen Störungen sind bereits passiert. 6.7 ist Verfeinerung, nicht Rekonstruktion.

Meine Empfehlung: Wenn Sie noch auf 6.5 sind, versuchen Sie nicht, zu 6.7 zu springen. Migrieren Sie zuerst zu 6.6, stabilisieren Sie, beheben Sie alles, was kaputt gegangen ist, betreiben Sie es einen Monat oder zwei in Produktion, und gehen Sie dann 6.7 als separates Projekt an. Zu versuchen, beide Sätze von Breaking Changes gleichzeitig zu absorbieren, ist der Weg, auf dem Projekte schiefgehen.

Häufig gestellte Fragen

Kann ich 6.6 überspringen und direkt zu 6.7 gehen?

Technisch ja – Shopware erlaubt Versionssprünge. Aber Sie entkommen den 6.6-Breaking-Changes dadurch nicht. Die Vue-3-Migration, die all.js-Entfernung, das Symfony-7-Upgrade, die entfernten veralteten PHP-APIs – all das gilt immer noch, und Sie debuggen gleichzeitig zwei Releases’ Brüche. Sofern Sie keinen sehr spezifischen Grund für einen Sprung haben, gehen Sie zuerst durch 6.6.

Wie lange dauert die Migration eigentlich?

Das hängt fast ausschließlich davon ab, wie viele Admin-berührende Plugins Sie haben und ob sie gepflegt wurden. Ein Shop mit drei oder vier gut gepflegten, häufig aktualisierten Plugins von aktiven Entwicklern: ein konzentrierter halber Tag auf Staging, ein einstündiges Deployment-Fenster. Ein Shop mit zwölf Plugins, von denen einige seit 6.4 nicht mehr angefasst wurden, manche von einer Agentur entwickelt, die es nicht mehr gibt: Wochen Arbeit. Es gibt keine universelle Antwort. Zuerst auditieren, dann schätzen.

Wird Rise/Evolve/Beyond (SaaS) automatisch aktualisiert?

Ja. Shopware kontrolliert den Update-Zeitplan für ihre SaaS-Editionen. Das ist tatsächlich eines der stärksten Argumente dafür, Plugin-Kompatibilität proaktiv zu prüfen – wenn Sie auf Rise SaaS sind, wird Shopware Sie nach seinem Zeitplan aktualisieren, nicht nach Ihrem. Die Benachrichtigungsfrist variiert, ist aber nicht großzügig. Wenn Sie die Kompatibilität nicht bereits geprüft haben, bevor die Benachrichtigung eintrifft, sind Sie im reaktiven Modus.

Gibt es einen Kompatibilitätsmodus oder Shim für alte Komponenten?

Shopware hat während der 6.6-Übergangszeit einige Deprecation-Shims bereitgestellt, die einige entfernte Muster vorübergehend am Laufen hielten. Verlassen Sie sich nicht darauf. Sie wurden ausdrücklich als temporär dokumentiert und werden entfernt. Wenn Ihr Plugin von einem Shim abhängt, ist das geliehene Zeit. Beheben Sie das zugrunde liegende Problem.

Wie es weitergeht

Wenn Sie einen Shopware-6.5-Shop verwalten und noch nicht migriert haben, beginnen Sie mit dem Plugin-Audit. Das ist die Arbeit, die Ihren eigentlichen Zeitplan und das Budget für diese Migration bestimmt. Alles andere folgt daraus, zu wissen, womit man es zu tun hat.

Wenn Sie 6.6 bereits hinter sich haben und jetzt an 6.7 denken, ist der Prozess derselbe – zuerst auditieren, vorwärts beheben, keine Schritte überspringen.

Für mehr Hintergrund darüber, wie Shopware strukturiert ist und was Sie eigentlich betreiben, deckt die Shopware-6-Übersicht die Plattformgrundlagen ab. Wenn Sie verstehen möchten, ob ein Upgrade der Editionsstufen neben der Versionsmigration sinnvoll ist, finden Sie die Zahlen in der Shopware-6-Preisübersicht.

Wenn Sie eine spezifische Migration anstehen haben und eine zweite Meinung dazu möchten, was tatsächlich getan werden muss – zögern Sie nicht, sich zu melden. Ich sage Ihnen ehrlich, was ich im Code sehe, nicht das, was Sie hören wollen.

An einem Shopware-Projekt beteiligt?

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

Ähnliche Artikel