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 findest Du 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 kompatiblitä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?
Erwarte 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 richtige 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 Deine Umgebung ältere PHP-Versionen verwendet, sind Anpassungen oder Kompatibilitätslayer erforderlich.
Wie beeinflusst das die Update- und Migrationsplanung?
Die Unterscheidung reduziert Upgrade-Unsicherheit: Du erkennst 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. Nutze dies, um automatisierte Tests gezielt auf Deprecations laufen zu lassen und Attribute-Checks in CI zu integrieren. Erfahrene Teams werden Attribute in Release-Notes und Pull-Requests auswerten, um Aufwände besser abzuschätzen. Beachte: 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 solltest Du jetzt konkret tun?
Prüfe Deine Plugins auf Deprecation-Logs und erweitere Tests/CI so, dass PHP-Attribute ausgelesen und bewertet werden. Erstelle eine Prioritätenliste: sofort beheben (Deprecations), später prüfen (BC-Attribute).
Konkrete Schritte:
- Audit: Sammle Deprecation-Meldungen aus Logs und identifiziere Code, der PHP-Attribute enthält oder enthalten könnte.
- CI anpassen: Ergänze Static-Analysis-Checks, die Attribute auswerten, damit BC-Änderungen nicht als Deprecations durchgehen.
- Tests schreiben: Ergänze Unit- und Integrationstests, die kritische API-Aufrufe abdecken; kennzeichne Tests, die auf Deprecations reagieren müssen.
- Kommunikation: Informiere externe Plugin-Entwickler oder Integrationspartner über die neue Kennzeichnung, idealerweise mit Links zu Release-Notes.
- Backup-Plan: Behalte weiterhin Pinning von Core-Versionen und eine Testumgebung für Major-Updates als Richtwert.
Zur Vertiefung kannst Du unsere Kategorie Shopware für technische Hinweise nutzen oder in Technik nach Anleitungen für CI-Integrationen suchen. Als Richtwert: Wenn Du auf PHP 8-Attribute umstellst, teste Attribute-Auslese-Tools in einer Staging-Umgebung, bevor Du Änderungen ins Produktivsystem übernimmst.
Lohnt sich die Umstellung sofort oder lässt Du erst die Praxisberichte abwarten?
Die Umstellung lohnt schrittweise: Priorisiere Deprecations sofort, Attribute-getriebene Prüfungen nach Bedarf. Vollständig auf Attribute umzustellen, macht Sinn, sobald Deine CI-Toolchain kompatibel ist.
Pragmatisch: Setze zuerst Monitoring und Logging auf Deprecations fort. Ergänze dann sukzessive Attribute-Auswertung in automatisierten Tests. Wenn Du viele Drittanbieter-Plugins betreibst, ist ein stufenweiser Ansatz empfehlenswert, initiales Scannen, Anpassung kritischer Plugins, dann breitere Integration in CI. Warte nicht auf Praxisberichte, aber investiere nicht sofort in große Overhauls der Build-Pipeline; teste zuerst in einer isolierten Umgebung.
Häufige Fragen
Müssen alle Plugins sofort angepasst werden?
Nicht unbedingt. Echte Deprecations haben Vorrang. Prüfe zuerst, ob Dein 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 Du ältere PHP-Versionen einsetzt, benötigst Du einen Kompatibilitätslayer oder planst ein PHP-Upgrade. Die Shopware-Mitteilung nennt Attribute als Mechanik, sie 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. Daher plane 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: Priorisiere Deprecations sofort, ergänze sukzessive Attribute-Auswertung in Deiner CI. Beginne mit einem Audit der Logs, ergänze Tests und informiere Integrationspartner. Nutze die neuen Attribute, um Upgrade-Risiken präziser einzuschätzen, teste die Anpassungen zuerst in Staging-Umgebungen.
