Ein Shopware-Plugin-Kompatibilitätscheck zeigt, wie viel Arbeit ein Major-Update wird. Ich mache einen, bevor ich einen Shop anfasse, der von 6.4 auf 6.7 wechselt, und er beginnt mit einer schlichten Liste dessen, was installiert ist.
Ein Shop, der ein paar Jahre auf 6.4 lief, hat vermutlich Plugins von mehr als einem Entwickler gesammelt. Niemand weiss mehr, warum jedes einzelne da ist. Das Update findet jedes davon.
6.4 auf 6.7 sind drei Updates
Das sind drei Major-Versionen: 6.5, 6.6 und 6.7. Jede hat eine andere Art von Plugin gebrochen. Das sind die Änderungen laut Shopwares eigenen Upgrade-Guides:
- 6.5: PHP 8.1 wurde zum Minimum. Die Storefront wechselte auf Bootstrap 5, und jQuery verschwand aus der Plattform. Ein Theme oder Plugin, das auf jQuery setzt, muss umgeschrieben werden oder eine eigene Kopie mitbringen.
- 6.6: PHP 8.2 wurde zum Minimum. Die Administration wechselte auf Vue 3 und webpack 5, und Shopware warnt, dass eine für 6.6 gebaute Admin-Erweiterung auf 6.5 oder niedriger nicht läuft.
- 6.7: Der Admin-Build wechselte von webpack auf Vite, eine eigene
webpack.config.jsbraucht also einevite.config.js. Die Vue-2-Kompatibilitätsschicht ist entfernt, und die Zustandsverwaltung der Administration wechselte von Vuex auf Pinia. Die Vite-Anleitung von Shopware behandelt die Build-Änderung.
Ein Plugin, das nur die Storefront berührt, trifft seine Änderungen bei 6.5. Eine Admin-Erweiterung kann bei 6.6 brechen und bei 6.7 noch einmal. Deshalb beurteile ich ein Plugin nie nach Name oder Alter.
Schritt 1: die vollständige Liste holen
Alles, was installiert ist, aktiv oder nicht. Der Bereich Erweiterungen in der Administration zeigt sie, ebenso bin/console plugin:list auf dem Server.
Ein inaktives Plugin liegt weiterhin in Ihrer Installation, also braucht es wie jedes andere eine Entscheidung.
Schritt 2: jedes Plugin einem Fach zuordnen
- Eigenes Theme. Storefront-Code, der für Ihren Shop geschrieben wurde. Die Änderungen aus 6.5, Bootstrap 5 und kein jQuery, treffen Themes zuerst.
- Gekauftes Plugin. Von einem Hersteller geschrieben. Es nennt die unterstützten Shopware-Versionen in seiner
composer.jsonund auf seiner Store-Seite, und diese Angabe ist die erste Antwort, die Sie bekommen. - Eigenes Plugin. Von einem Entwickler für Ihren Shop geschrieben. Die Upgrade-Guides oben sind die Checkliste.
Schritt 3: aufschreiben, was jedes Plugin tut
Ein Plugin-Name sagt wenig. Die Funktion zeigt, was der Shop verlieren würde. Zu jedem Plugin halte ich fest, welche Funktion es liefert und was der Shop ohne es verlieren würde.
Kann das niemand beantworten, ist das eine Frage an den Shopbetreiber. Sie lässt sich besser vor dem Update stellen als danach.
Schritt 4: ersetzen oder neu bauen
Jede Funktion landet an einem von zwei Orten. Gibt es einen gepflegten Ersatz, ersetze ich das Plugin. Gibt es keinen, baue ich die Funktion neu.
Ich warte nicht darauf, dass ein Hersteller eine kompatible Version liefert. Der Release-Plan des Herstellers ist nicht Ihr Update-Termin.
Eine Ausnahme gibt es: Plugins, die von einem Drittdienst abhängen, etwa einem Zahlungsanbieter oder der API eines Versanddienstleisters. Hat der Anbieter seine Seite nicht aktualisiert, ändert ein Neubau des Plugins nichts, denn der Dienst bestimmt, was funktioniert. Nur in diesem Fall warte ich.
PHP gehört zum Update
Zwei dieser Schritte heben auch die PHP-Untergrenze an: 8.1 für 6.5 und 8.2 für 6.6. Plugin-Code muss auf dem neuen PHP laufen, ebenso wie auf der neuen Shopware-Version.
Es ist auch eine Sicherheitsfrage. Varonis, ein Sicherheitsanbieter, sagt, dass es für PHP 8.1 und älter keinen offiziellen Fix gegen die php2shell-Lücken gibt. Das behandle ich in Wer patcht Ihren Shopware-Shop.
Was ein Check meist zutage fördert
In meinen Checks sind es meist 3 bis 4 Plugins pro Shop, die einen Ersatz oder einen Neubau brauchen.
Diese Plugins bestimmen den Umfang des Updates.
Eine unordentliche Migrationshistorie ist ein eigenes Problem, und über eine habe ich in meiner 6.3-Update-Geschichte geschrieben. Wie ich Plugins baue, damit sie das nächste Update überstehen, steht in meinem Ansatz zur Plugin-Entwicklung.
Häufig gestellte Fragen
Welche Shopware-Änderungen brechen Plugins zwischen 6.4 und 6.7? 6.5 hob das PHP-Minimum auf 8.1, stellte die Storefront auf Bootstrap 5 um und entfernte jQuery aus der Plattform. 6.6 hob das Minimum auf PHP 8.2 und stellte die Administration auf Vue 3 und webpack 5 um. 6.7 wechselte den Admin-Build von webpack auf Vite, entfernte die Vue-2-Kompatibilitätsschicht und ersetzte Vuex durch Pinia. Jeder Schritt bricht eine andere Art von Plugin.
Soll ich warten, bis der Plugin-Hersteller eine kompatible Version liefert? Nein, mit einer Ausnahme. Gibt es einen gepflegten Ersatz, ersetze ich das Plugin. Gibt es keinen, baue ich die Funktion neu. Ich warte nur, wenn das Plugin von einem Drittdienst abhängt, denn dann bestimmt der Dienstanbieter, was funktioniert, und ein Neubau ändert nichts.
Wie viele Plugins brauchen bei einem Major-Update meist Arbeit? In meinen Checks sind es meist 3 bis 4 Plugins pro Shop, die einen Ersatz oder einen Neubau brauchen.
Wenn Ihr Shop auf 6.4 läuft und Sie diese Liste aufgebaut haben möchten, mit einer Entscheidung zwischen Ersetzen und Neubau für jedes Plugin, nehmen Sie Kontakt auf. Diese Arbeit übernehme ich als Shopware Freelancer, und das Festpreis-Audit dort umfasst das Plugin-Inventar mit diesen Entscheidungen. Weitere Arbeiten dieser Art finden Sie in meinen Fallstudien.
