Shopware 6.7.14.0: Neue Kommunikation für Deprecated- und BC-Änderungen

KI-generiertes Beispielbild, kann von der Realität abweichen.

Shopware trennt künftig klarer zwischen echten Deprecations und anderen Rückwärtskompatibilitätsänderungen. Das soll Entwicklern bessere Migrationssignale geben und Upgrades planbarer machen.

Am 24.08.2026 kündigte Shopware mit Blick auf Version 6.7.14.0 eine veränderte Kommunikation technischer API-Änderungen an. Echte Deprecations bleiben als solche markiert. Andere Breaking-/BC-Änderungen werden künftig zusätzlich mit strukturierten PHP-Attributen beschrieben. Das ist besonders relevant für Plugin- und Extension-Entwickler, weil sich dadurch Migrationspfade und Release-Planung besser unterscheiden lassen; die Originalmitteilung finden Sie wie der Hersteller in seiner Mitteilung schreibt.

Was ändert Shopware mit 6.7.14.0 bei Deprecations und BC-Änderungen?

Shopware lässt echte Deprecations weiterhin als Warnsignal stehen und führt für andere Rückwärtskompatibilitätsänderungen strukturierte PHP-Attribute ein, die die Art der Änderung beschreiben. Das trennt künftig Migrationshinweise von bloßen Kompatibilitätsanpassungen und macht die Maske für Entwickler präziser.

Technisch bedeutet das: Methoden oder API-Endpunkte, die tatsächlich entfernt oder obsolet sind, bleiben mit Deprecation-Meldungen markiert. Änderungen, die zwar kompatibilitätsrelevant, aber nicht im Deprecation-Sinne entfernend sind, werden zusätzlich oder alternativ durch PHP-Attribute dokumentiert. Ziel ist weniger Rauschen in den Deprecation-Logs und bessere Signale für automatisierte Prüfungen. Die Umstellung betrifft vor allem die interne Dokumentation und Maschinerie, die bisher Deprecations und BC-Hinweise oft gleich behandelt hat.

Wen betrifft die neue Kennzeichnung praktisch?

Primär Plugin- und Extension-Entwickler sind betroffen; zweitens Shopbetreiber mit individuellen Anpassungen oder Third-Party-Plugins. Die Unterscheidung hilft beim Priorisieren von Änderungen und reduziert falsche Migrationsdringlichkeit.

Plugin-Entwickler sehen künftig klarer, ob eine API wirklich entfernt werden kann oder ob nur Verhaltensdetails angepasst wurden. Shopbetreiber, die eigene Anpassungen oder Integrationen betreiben, profitieren, weil die Upgrade-Checklisten weniger False-Positives liefern. Für reine Shop-Administratoren ändert sich wenig am Frontend; die Änderung ist vorwiegend für Code-Qualität, CI-Pipelines und die Release-Planung relevant.

Welche technischen Anpassungen müssen Plugin-Entwickler erwarten?

Erwarten Sie PHP-Attribute in Core-Quellcode und APIs, die semantische Hinweise liefern (z. B. auf Breaking-Änderungen ohne klassische Deprecation). Entwickler müssen Attribute parsen und CI-Checks anpassen, um die richtigen Migrationssignale zu filtern.

Konkreter: Plugins sollten künftig auf PHP-Attribute prüfen, die Rückwärtskompatibilitäts-Informationen enthalten. Das kann bedeuten, dass Static-Analysis-Tools, Composer-Checks oder eigene Upgrade-Skripte erweitert werden müssen, um diese Attribute auszulesen. Shopware selbst wird weiterhin klassische Deprecation-Mechanismen verwenden; die Attribute dienen ergänzend als strukturierte Metadaten. Die Originalquelle beschreibt die Änderung so: wie der Hersteller in seiner Mitteilung schreibt. Technisch sind Attribute seit PHP 8 verfügbar; falls Ihre Umgebung ältere PHP-Versionen verwendet, sind Anpassungen oder Kompatibilitätslayer erforderlich.

Wie beeinflusst das die Update- und Migrationsplanung?

Die Unterscheidung reduziert Upgrade-Unsicherheit: Sie erkennen schneller, welche Änderungen echte Entfernungsvorhaben sind und welche nur Verhaltens- oder API-Verfeinerungen darstellen. Das macht Prioritäten in Roadmaps verlässlicher.

Operativ heißt das: Migrationslisten lassen sich feiner priorisieren. Echte Deprecations bleiben rote Flags; BC-Änderungen können als gelbe Flags mit erläuternden Attributen markiert werden. Nutzen Sie dies, um automatisierte Tests gezielt auf Deprecations laufen zu lassen und Attribute-Checks in die CI zu integrieren. Erfahrene Teams werden Attribute in Release-Notes und Pull-Requests auswerten, um Aufwände besser abzuschätzen. Beachten Sie: Shopware nennt das primär eine Veränderung der Kommunikation, nicht der API-Break-Politik. Die inhaltliche Wirkung hängt weiter von den konkreten Änderungen in den jeweiligen Versions-Notes ab.

Was sollten Sie jetzt konkret tun?

Prüfen Sie Ihre Plugins auf Deprecation-Logs und erweitern Sie Tests/CI so, dass PHP-Attribute ausgelesen und bewertet werden. Erstellen Sie eine Prioritätenliste: sofort beheben (Deprecations), später prüfen (BC-Attribute).

Konkrete Schritte:

• Audit: Sammeln Sie Deprecation-Meldungen aus Logs und identifizieren Sie Code, der PHP-Attribute enthält oder enthalten könnte.
• CI anpassen: Ergänzen Sie Static-Analysis-Checks, die Attribute auswerten, damit BC-Änderungen nicht als Deprecations durchgehen.
• Tests schreiben: Ergänzen Sie Unit- und Integrationstests, die kritische API-Aufrufe abdecken; kennzeichnen Sie Tests, die auf Deprecations reagieren müssen.
• Kommunikation: Informieren Sie externe Plugin-Entwickler oder Integrationspartner über die neue Kennzeichnung, idealerweise mit Links zu Release-Notes.
• Backup-Plan: Behalten Sie weiterhin Pinning von Core-Versionen und eine Testumgebung für Major-Updates als Richtwert bei.

Zur Vertiefung können Sie unsere Kategorie Shopware für technische Hinweise nutzen oder in Technik nach Anleitungen für CI-Integrationen suchen. Als Richtwert: Wenn Sie auf PHP-8-Attribute umstellen, testen Sie Tools zum Auslesen der Attribute in einer Staging-Umgebung, bevor Sie Änderungen ins Produktivsystem übernehmen.

Lohnt sich die Umstellung sofort oder warten Sie erst die Praxisberichte ab?

Die Umstellung lohnt sich schrittweise: Priorisieren Sie Deprecations sofort, Attribute-getriebene Prüfungen nach Bedarf. Vollständig auf Attribute umzustellen, ist sinnvoll, sobald Ihre CI-Toolchain kompatibel ist.

Pragmatisch: Führen Sie zuerst Monitoring und Logging auf Deprecations fort. Ergänzen Sie dann sukzessive die Attribute-Auswertung in automatisierten Tests. Wenn Sie viele Drittanbieter-Plugins betreiben, ist ein stufenweiser Ansatz empfehlenswert: initiales Scannen, Anpassung kritischer Plugins, dann breitere Integration in die CI. Warten Sie nicht auf Praxisberichte, aber investieren Sie nicht sofort in große Overhauls der Build-Pipeline; testen Sie zuerst in einer isolierten Umgebung.

Häufige Fragen

Müssen alle Plugins sofort angepasst werden?

Nicht unbedingt. Echte Deprecations haben Vorrang. Prüfen Sie zuerst, ob Ihr Plugin Deprecation-Logs auslöst. BC-Änderungen, die nur durch Attribute markiert sind, können in einem zweiten Schritt bewertet und migriert werden.

Welche PHP-Version wird für Attribute benötigt?

PHP-Attribute sind ab PHP 8 verfügbar. Falls Sie ältere PHP-Versionen einsetzen, benötigen Sie einen Kompatibilitätslayer oder planen ein PHP-Upgrade. Die Shopware-Mitteilung nennt Attribute als Mechanik und setzt voraus, dass die Zielumgebung Attribute unterstützt.

Gibt es fertige Tools zum Auslesen der neuen Attribute?

Der Markt für Static-Analysis- und CI-Tools lässt sich anpassen; fertige Plugins für Shopware sind zum Veröffentlichungszeitpunkt nicht garantiert. Planen Sie daher Zeit für Anpassungen oder eigene Script-Lösungen ein.

Beeinflusst die Änderung das Store-Review-Verfahren?

Nicht unmittelbar. Die Änderung betrifft die technische Kennzeichnung und Entwickler-Kommunikation. Store-Reviews behalten eigene Kriterien; mögliche Auswirkungen hängen von den konkreten Qualitätsanforderungen der Store-Betreiber ab.

Fazit

Empfehlung: Priorisieren Sie Deprecations sofort und ergänzen Sie sukzessive die Attribute-Auswertung in Ihrer CI. Beginnen Sie mit einem Audit der Logs, ergänzen Sie Tests und informieren Sie Integrationspartner. Nutzen Sie die neuen Attribute, um Upgrade-Risiken präziser einzuschätzen, und testen Sie die Anpassungen zuerst in Staging-Umgebungen.