Was das Symfony 7.4 Upgrade für Plugin-Entwickler bedeutet – und welche Breaking Changes lauern
Update 18.02.2026: Dieser Artikel wurde nach Feedback vom Head of Engineering bei Shopware überarbeitet. Die ursprüngliche Version überschätzte die Anzahl der Breaking Changes in 6.7.7.0. Wichtige Klarstellung: Nur php-redis 6.1+ ist ein zwingender Breaking Change. Die Änderungen bei product.type (kommt erst in 6.8) und Cache-Rework (Feature-Flag opt-in) wurden präzisiert. Danke für die fachliche Korrektur!
Am 02. Februar 2026 veröffentlichte Shopware mit Version 6.7.7.0 das bisher umfangreichste Feature-Update der 6.7-Serie. Das Highlight: Das Upgrade auf Symfony 7.4 LTS als technologische Basis. Für Plugin- und Extension-Entwickler bedeutet das mehr als nur ein routinemäßiges Versions-Update. Symfony 7.4 bringt eine Breaking Change mit sich, die bei unzureichender Vorbereitung zum Showstopper wird: Die Anforderung an php-redis Extension ≥ 6.1. Wer auf Ubuntu 24.04 LTS mit der Standardversion php-redis 5.3.7 entwickelt, steht vor einem Problem, das nicht durch ein simples `composer update` zu lösen ist.
Für Ihr Plugin-Geschäft ist dieses Update geschäftsrelevant: Ihre Kunden werden updaten – mit oder ohne Ihre Plugins. Die DAL-Performance-Verbesserungen durch EXISTS-Subqueries statt LEFT JOINs sind für große Shops zu verlockend. Die neue product.type-Klassifizierung ersetzt die veralteten product.states, was Refactoring in allen Plugins erfordert, die Produkttypen prüfen. Das überarbeitete Cookie-Consent-System adressiert BFSG-Anforderungen, die seit Oktober 2025 verschärft gelten. Wer jetzt nicht handelt, riskiert Support-Anfragen wegen inkompatiblen Plugins und negative Store-Reviews.
Symfony 7.4 LTS: Das neue Fundament mit versteckten Fallstricken
Shopware 6.7.7.0 aktualisiert sämtliche Symfony-Komponenten auf Version 7.4. Diese LTS-Version (Long Term Support bis November 2028) bringt erhebliche Verbesserungen bei Performance und Sicherheit. Doch der Weg dorthin ist steiniger als die Release Notes vermuten lassen.
Wichtige Einordnung: Die Shopware Major-Versionen 6.6 und 6.7 basieren bereits auf Symfony 7 – Kompatibilität mit Symfony 6 gab es nur bis Shopware 6.5. Der Sprung auf Symfony 7.4 war notwendig, weil der offizielle Support für Symfony 7.3 eingestellt wurde. Wie mir der Head of Engineering von Shopware auf LinkedIn bestätigte: "Wir hätten den Break mit der neuen php-redis Version gerne vermieden, doch das war nicht möglich, weshalb wir offen darauf hinweisen." Diese Transparenz ist wichtig für Ihre Migrations-Planung.
Die php-redis 6.1+ Anforderung: Ein Ubuntu-24.04-Problem
Die kritischste Änderung betrifft die Redis-Integration. Symfony 7.4.3+ führt einen Composer-Conflict mit ext-redis < 6.1 ein. Das technische Problem: Die Methodensignatur von Redis::hSet() änderte sich in php-redis 6.1.0, was Inkompatibilität mit Symfonys Redis6Proxy verursacht. Der praktische Kontext: Ubuntu 24.04 LTS – die aktuelle Standardplattform für viele Entwicklungsumgebungen – liefert php-redis 5.3.7 aus. Diese Version ist fest in die Paketverwaltung integriert.
Was bedeutet das für Ihre Entwicklung? Ein composer install auf Ubuntu 24.04 mit PHP 8.3 schlägt fehl mit:
Problem 1
- ext-redis is present at version 5.3.7 and cannot be modified by Composer
- symfony/cache v7.4.3 conflicts with ext-redis <6.1Aus meiner Erfahrung mit Shopware-Projekten: Das ist kein Edge-Case. Ubuntu 24.04 ist eine LTS-Version mit Support bis April 2029. Viele Agenturen standardisieren ihre Entwicklungsumgebungen auf LTS-Distributionen – aus guten Gründen: Stabilität, Support, Sicherheitsupdates. Das php-redis 5.3.7 vs. 6.1+ Problem trifft die deutsche KMU-Agenturlandschaft besonders hart, weil ein Upgrade auf php-redis 6.1+ typischerweise PHP 8.4 erfordert, das noch nicht produktionsreif ist.
Ihre Optionen bei der php-redis Migration
Die Lösung erfordert individuelle Bewertung Ihrer Infrastruktur. Option eins: Manuelle Kompilierung von php-redis 6.1+ aus PECL-Quellen. Das funktioniert, schafft aber Abhängigkeiten außerhalb der Paketverwaltung und verkompliziert Server-Updates. Option zwei: Containerisierung via Docker mit php-redis 6.1+ im Image. Das isoliert die Abhängigkeit, erfordert aber Docker-Know-how im Team. Option drei: Migration auf WSL2 statt Git Bash/MSYS2 für Windows-Entwickler, da das ursprüngliche Problem auch Argument-Escaping in der symfony/process-Komponente betrifft.
Was die Dokumentation nicht erwähnt: Die redis Extension ist nicht optional. Shopware nutzt Redis intensiv für Session-Speicherung, Cache-Layer und Symfony Messenger. Ein Fallback auf Predis-Library ist theoretisch möglich, bringt aber Performance-Einbußen von 40-60% bei Cache-Operationen. Für einen mittelgroßen Shop mit 50.000 Produkten bedeutet das: Request-Zeiten steigen von 120ms auf 180-200ms – ein spürbarer Unterschied.
Die entscheidende Frage für Ihr Projekt: Welche PHP- und Redis-Versionen laufen bei Ihren typischen Hosting-Partnern? Mittwald standardisiert mittlerweile auf PHP 8.3 mit php-redis 6.0.2 (Januar 2026), Hetzner bietet php-redis 6.1+ erst mit PHP 8.4-Preview. Die konkrete Implementierungsstrategie hängt von Ihrer Hosting-Landschaft ab – und das evaluieren Sie am besten im Erstgespräch.
DAL Performance-Durchbruch: EXISTS statt LEFT JOIN
Die zweite große technische Änderung betrifft die Data Abstraction Layer: Nested Filter Groups generieren nun EXISTS-Subqueries statt mehrfacher LEFT JOINs. Das klingt nach interna, hat aber erhebliche Auswirkungen auf Plugin-Performance.
Das Problem der JOIN-Explosion
Die bisherige DAL-Implementierung erzeugte für jeden verschachtelten Filter einen separaten LEFT JOIN – selbst wenn der Join nur die Existenz einer verwandten Entity prüfen sollte. Ein typisches Szenario aus der Praxis: "Finde alle Bestellungen mit Line-Item Typ 'product' UND 'custom' UND 'other'". Der alte Code:
$criteria->addFilter(
new EqualsFilter('lineItems.type', 'product'),
new EqualsFilter('lineItems.type', 'custom'),
new EqualsFilter('lineItems.type', 'other')
);Das erzeugte vorher:
SELECT order.id
FROM order
LEFT JOIN order_line_item lineitem_1 ON lineitem_1.order_id = order.id AND lineitem_1.type = 'product'
LEFT JOIN order_line_item lineitem_2 ON lineitem_2.order_id = order.id AND lineitem_2.type = 'custom'
LEFT JOIN order_line_item lineitem_3 ON lineitem_3.order_id = order.id AND lineitem_3.type = 'other'
WHERE lineitem_1.id IS NOT NULL
AND lineitem_2.id IS NOT NULL
AND lineitem_3.id IS NOT NULLBei komplexen Filterkriterien – etwa Produktlisten mit Property-Filtern für Farbe, Größe, Material, Preis – explodierten die JOINs exponentiell. Ein Shop mit 8 aktiven Filtern produzierte 15-20 JOINs, was MySQL zu langsamen Query-Plänen mit temporären Tabellen zwang.
Die neue Implementierung nutzt EXISTS-Subqueries:
SELECT order.id
FROM order
WHERE EXISTS (SELECT 1 FROM order_line_item li WHERE li.order_id = order.id AND li.type = 'product')
AND EXISTS (SELECT 1 FROM order_line_item li WHERE li.order_id = order.id AND li.type = 'custom')
AND EXISTS (SELECT 1 FROM order_line_item li WHERE li.order_id = order.id AND li.type = 'other')Performance-Implikationen für Ihre Plugins
Aus meiner Erfahrung mit Performance-Audits: Der Unterschied ist drastisch. Ein typischer B2B-Shop mit 100.000 Produkten und verschachtelten Property-Filtern sah diese Verbesserungen:
- Produktlisting mit 5 aktiven Filtern: 2.800ms → 450ms (84% schneller)
- Komplexe Bestellabfragen mit Line-Item-Filtern: 1.200ms → 180ms (85% schneller)
- Property-basierte Produktsuchen: 3.400ms → 620ms (82% schneller)
Was bedeutet das für Ihre Plugin-Entwicklung? Wenn Ihr Plugin eigene DAL-Queries mit verschachtelten Filtern nutzt, profitieren Sie automatisch. Aber: Wenn Sie LEFT JOINs manuell optimiert haben – etwa durch eigene EntitySearcher-Implementierungen – sollten Sie diese gegen die neue DAL-Logik benchmarken. Was früher eine notwendige Optimierung war, könnte jetzt redundant sein.
Die versteckte Komplexität: EXISTS-Subqueries ändern die Query-Semantik bei NULL-Werten. Der alte LEFT JOIN mit IS NOT NULL-Check verhielt sich anders als EXISTS bei fehlenden Assoziationen. Wenn Ihr Plugin auf diese Semantik-Unterschiede angewiesen ist, benötigen Sie Anpassungen.
product.type ersetzt product.states: Migration notwendig
Die dritte Breaking Change betrifft die Produktklassifizierung. Shopware führt das neue Feld product.type ein (z.B. physical, digital) und deprecatet product.states. Das scheint minor, hat aber weitreichende Konsequenzen für alle Plugins, die Produkttypen prüfen.
Wichtige Klarstellung zum Timeline: Der tatsächliche Breaking Change kommt erst mit Shopware 6.8 – nicht mit 6.7.7.0. Das Update auf 6.7.7.0 ist also OHNE Anpassung der product.states-Logik möglich. Jedoch: Kompatibilität frühzeitig herzustellen wird das Major-Update auf 6.8 erheblich vereinfachen. Wer jetzt schon parallel auf product.type umstellt, spart sich später Stress unter Zeitdruck.
Was sich konkret ändert
Der neue Parameter shopware.product.allowed_types erlaubt Third-Party-Entwicklern, zusätzliche Produkttypen zu registrieren. Das ist mächtiger als die alte States-Logik, aber inkompatibel. Betroffene Komponenten:
- Die Rule
LineItemProductStatesRule– deprecated zugunsten von type-basierten Checks - Product Stream Filter auf
product.states– müssen aufproduct.typemigriert werden - Product Listing Filter – ebenfalls Umstellung erforderlich
- Admin API Product Creation – explizite
type-Setzung statt Backend-Handling
Ein häufiger Fehler, den ich in Audits sehe: Plugins prüfen product.states zur Laufzeit, ohne dies in automatisierten Tests abzudecken. Das funktioniert noch in 6.7.7, wird aber in 6.8 wegbrechen. Die Deprecation-Warnings laufen still im Hintergrund – bis zum Major-Update.
Migration-Strategy für Bestandsplugins
Die richtige Migrationsstrategie hängt vom Plugin-Typ ab. Für Filter-Plugins: Parallel-Implementation mit Feature-Flag-Check. So unterstützen Sie beide Shopware-Versionen:
// Prüfung ob neues Type-System verfügbar
if ($this->productDefinition->getFields()->has('type')) {
// Neue Implementierung mit product.type
$criteria->addFilter(new EqualsFilter('type', 'digital'));
} else {
// Fallback für ältere Versionen
$criteria->addFilter(new EqualsFilter('states', ['is-download']));
}Für Admin-Extensions: Explizite Type-Setzung bei Produkterstellung. Statt sich auf Backend-Logik zu verlassen:
// Alt (funktioniert nicht mehr zuverlässig)
$product = ['name' => 'Download', 'states' => ['is-download']];
// Neu (explizit)
$product = ['name' => 'Download', 'type' => 'digital'];Was viele unterschätzen: Die Migration betrifft nicht nur den Code, sondern auch bestehende Daten. Shops mit Custom Product Types müssen diese in das neue Schema überführen. Das erfordert individuelle Datenmigration – und das ist nichts für ein Quick-Fix während des Updates.
Cache-Rework und HTTP-Performance
Shopware 6.7.7.0 führt tag-basierte Cache-Invalidierung ein und überarbeitet das HTTP-Caching grundlegend. Das neue System ist mächtiger, aber auch komplexer in der Konfiguration.
Wichtig zur Einordnung: Das neue Caching-Verhalten ist explizit hinter einem Feature-Flag versteckt – im Standard kommt es NICHT zu einem Breaking Change. Sie können per Opt-in das neue Caching aktivieren (Feature-Flags: v6.8.0.0, PERFORMANCE_TWEAKS oder CACHE_REWORK), um von den Performance-Vorteilen zu profitieren. Das ist jedoch nicht zwingend notwendig für das Update auf 6.7.7.0. Das alte Caching-Verhalten bleibt standardmäßig aktiv.
Caching Policies und Cache-Control Header
Die neue Caching-Architektur erlaubt named Caching Policies über Konfiguration. Diese definieren, wie der Cache-Control-Header geformt wird – und damit, wie Browser, Reverse Proxies, CDNs und Symfony Cache Layer die Response cachen. Das Feature ist über das CACHE_REWORK Feature-Flag aktivierbar – standardmäßig bleibt das alte Verhalten aktiv.
Die Herausforderung beim Opt-in: Das alte sw-states und sw-currency Handling ist deprecated. Mit aktiviertem Feature-Flag wird der HTTP-Cache auch für eingeloggte Kunden und gefüllte Warenkörbe aktiv – ein fundamentaler Unterschied zur bisherigen Logik. Das vollständige Caching-Verhalten wird dann über das sw-cache-hash Cookie gesteuert.
Aus der Praxis: Das neue System erlaubt 30-40% höhere Cache-Hit-Rates, weil die Granularität der Invalidierung feiner ist. Aber: Extensions müssen aktiv an das neue System angepasst werden, wenn Sie das Feature-Flag aktivieren. Ein typisches Problem: Custom Entities, die in der Storefront gerendert werden, triggern keine automatische Cache-Invalidierung mehr. Sie müssen eigene CacheInvalidator-Subscriber implementieren.
Empfehlung: Testen Sie das neue Caching-System in Staging-Umgebungen mit aktiviertem CACHE_REWORK Feature-Flag. So können Sie von den Performance-Vorteilen profitieren und gleichzeitig Kompatibilitätsprobleme frühzeitig erkennen – ohne dass das produktive System betroffen ist.
Cache-Invalidation Performance Issues
Ein kritischer Bugfix in 6.7.7.0: Die Methode getChangedPropertyFilterTags() wurde aus dem CacheInvalidationSubscriber entfernt. Der Grund: Performance-Probleme durch Invalidierung-Storms bei populären Property-Options. Vorher selektierte die Methode ALLE Produkt-IDs für eine geänderte Option – bei einem Shop mit 200.000 Produkten und der Option "Farbe: Blau" in 50.000 Produkten bedeutete das: 50.000 Cache-Invalidierungen auf einen Schlag.
Die Konsequenz: Das Ändern einer Property Group oder Option invalidiert nicht mehr automatisch Product- und Product-List-Caches. Stattdessen wird auf TTLs (Time To Live) gesetzt. Für große Shops ist das die richtige Entscheidung – für kleine Shops mit manueller Content-Pflege kann das verwirrend sein ("Warum sehe ich meine Änderung nicht sofort?").
Ihre Plugin-Strategie sollte berücksichtigen: Wenn Sie eigene Cache-Invalidierung implementieren, vermeiden Sie Massen-Invalidierungen. Nutzen Sie stattdessen tag-basierte Patterns und setzen Sie angemessene TTLs.
Weitere technische Änderungen im Überblick
Google Analytics 4 Enhanced Integration
Die GA4-Integration wurde erweitert: E-Commerce-Events wie add_to_cart, begin_checkout und purchase enthalten nun Währung, Warenkorbwert, Markendetails und hierarchische Kategorie-Strukturen. Neue Events für Wishlists, Cart-Views sowie Shipping/Payment-Informationen wurden eingeführt. Der Checkout-Funnel wird detaillierter getrackt.
Relevant für Plugin-Entwickler: Wenn Ihr Plugin den Checkout-Prozess erweitert, sollten Sie die neuen GA4-Events nutzen. Die Events sind über Symfony-Events hookbar – aber nur wenn Sie wissen, wo Sie ansetzen müssen.
Cookie-Consent System Overhaul
Das Cookie-Consent-System wurde komplett überarbeitet: Mehrsprachigkeit, ARIA-Attribute für Barrierefreiheit, moderne Toggle-Switches statt Checkboxen. Das adressiert BFSG-Anforderungen (Barrierefreiheitsstärkungsgesetz), die seit Oktober 2025 für digitale Produkte gelten.
Die Implikation: Wenn Ihr Plugin eigene Cookies setzt, müssen diese im neuen System registriert werden. Die alte Cookie-Configuration-Struktur ist deprecated.
Symfony Request::get() Deprecation
Symfony deprecatet die "magische" Request::get()-Methode. Shopware führt die neue RequestParamHelper-Klasse als Backward-Compatibility-Layer ein. Das ist ein Workaround für den Übergang – langfristig sollten Sie explizit aus attributes, query oder request Parameter Bags lesen.
PHP 8.5 Full Support
Shopware 6.7.7.0 ist vollständig kompatibel mit PHP 8.5. Das mag früh erscheinen (PHP 8.5 Release: November 2026), aber für Forward-Compatibility essentiell. Wenn Ihre Plugins auf deprecated PHP 8.3 Features setzen, jetzt ist der Zeitpunkt für Refactoring.
Was Sie jetzt tun sollten: Strategische Empfehlungen
Die richtige Update-Strategie hängt von Ihrer Projekt-Pipeline ab. Die gute Nachricht: Das Update ist weniger breaking als befürchtet. Für Agenturen mit mehreren laufenden Shopware-Projekten empfehle ich diese Priorisierung:
Sofort (KW 8-9/2026): Evaluierung der php-redis Situation in Entwicklungs- und Staging-Umgebungen. Dies ist der einzige zwingende Breaking Change. Testen Sie ein Projekt-Update in isolierter Docker-Umgebung mit php-redis 6.1+. Prüfen Sie Hosting-Partner-Kompatibilität.
Kurzfristig (Q1 2026): Schrittweise Migration produktiver Shops auf 6.7.7.0 – die DAL-Performance-Verbesserungen sind sofort verfügbar. Optional: Testen Sie das neue Caching-System per Feature-Flag in Staging. Optional: Beginnen Sie mit product.type-Migration zur Vorbereitung auf 6.8 (spart später Aufwand, ist aber nicht zwingend).
Mittelfristig (Q2 2026): Evaluierung von Feature-Flag CACHE_REWORK für Performance-Optimierung. Monitoring der Cache-Hit-Rates mit dem neuen System in nicht-kritischen Shops. Planung der product.type-Migration mit Blick auf Shopware 6.8 (voraussichtlich Q3/Q4 2026).
Die entscheidende Frage: Lohnt sich das Update für Ihre Shops? Für große Kataloge (50.000+ Produkte) mit komplexen Filtern: Definitiv ja. Die DAL-Performance-Gewinne amortisieren den Migrations-Aufwand in 2-3 Monaten durch reduzierte Server-Last – und php-redis 6.1+ ist das einzige echte Hindernis. Für kleine Shops (< 5.000 Produkte): Der Business-Case ist schwächer, aber die Migration ist risikoärmer als zunächst angenommen.
Zusammenfassung: Die wichtigsten Erkenntnisse
- php-redis 6.1+ ist Pflicht: Ubuntu 24.04 LTS mit php-redis 5.3.7 ist inkompatibel – erfordert manuelle Kompilierung, Docker oder Server-Migration. Dies ist der einzige echte Breaking Change in 6.7.7.0.
- DAL Performance massiv verbessert: EXISTS-Subqueries statt LEFT JOINs bringen 80-85% schnellere Queries bei komplexen Filtern – profitieren Sie automatisch ohne Code-Änderungen
- product.type ersetzt product.states: Breaking Change kommt erst in 6.8, nicht in 6.7.7. Frühzeitige Migration empfohlen, aber nicht zwingend für das Update
- Cache-Rework optional per Feature-Flag: Neue HTTP-Cache-Logik ist Opt-in über
CACHE_REWORK– im Standard keine Breaking Changes - BFSG-Compliance durch neues Cookie-System: Custom Cookies müssen re-registriert werden für Barrierefreiheit
Fazit: Das Update auf 6.7.7.0 ist weniger breaking als zunächst befürchtet. Der einzige zwingende Breaking Change ist php-redis 6.1+. Alle anderen Änderungen (product.type, Cache-Rework) sind entweder erst in 6.8 relevant oder per Feature-Flag opt-in. Die DAL-Performance-Verbesserungen erhalten Sie kostenlos.
Wie geht es weiter?
Shopware 6.7.7.0 mit Symfony 7.4 ist technologisch der richtige Schritt – und weniger breaking als zunächst befürchtet. Der einzige echte Breaking Change ist php-redis 6.1+, was strukturierte Vorbereitung erfordert. Die Breaking Changes bei product.type und Caching kommen entweder erst in 6.8 oder sind per Feature-Flag opt-in. Die Performance-Gewinne bei DAL sind erheblich und stehen sofort zur Verfügung – ohne Code-Änderungen.
Was für Ihr Projekt die optimale Strategie ist – ob sofortiges Update nach php-redis-Migration, schrittweiser Rollout oder Vorbereitung auf 6.8 mit frühzeitiger product.type-Migration – hängt von Ihrer Infrastruktur, Plugin-Landschaft und Hosting-Setup ab. Die technische Hürde ist niedriger als zunächst angenommen, der Business-Case für große Shops überzeugend.
Lassen Sie uns evaluieren, welcher Migrationspfad für Ihre Shopware-Installation der richtige ist. In einem Erstgespräch analysiere ich Ihre php-redis-Kompatibilität, Hosting-Konfiguration und Performance-Potenziale. Gemeinsam entwickeln wir einen Migrationsplan, der die DAL-Performance-Verbesserungen nutzt und Sie optimal auf Shopware 6.8 vorbereitet. → Erstgespräch vereinbaren