Mit Shopware 6.7.7.0 ist Anfang Februar ein Release erschienen, das aus Entwicklersicht deutlich interessanter ist, als es auf den ersten Blick vielleicht wirkt. Während manche Updates vor allem neue Funktionen für Händler in den Vordergrund stellen, liegt der eigentliche Wert dieses Releases für mich klar in den technischen Änderungen unter der Haube.
Genau dort hat sich in 6.7.7.0 einiges getan: Symfony 7.4, ein spürbares Performance-Update in der DAL, neue Regeln rund um Custom-Field-Suche, Veränderungen beim HTTP-Caching und eine wichtige Weichenstellung bei product.states und dem neuen product.type.
Wer Shopware-Projekte betreut, Plugins entwickelt oder individuelle Erweiterungen in bestehende Shops integriert, sollte sich dieses Release deshalb genauer ansehen.
Symfony 7.4 ist da – und das ist mehr als nur ein Versionssprung
Shopware hat in 6.7.7.0 alle Symfony-Pakete auf Version 7.4 angehoben. Das ist nicht einfach nur eine technische Randnotiz, sondern ein klares Signal für die weitere Modernisierung des Stacks. Für Entwickler bedeutet das vor allem: bestehende Eigenentwicklungen, Plugins und interne Integrationen sollten mit Blick auf Symfony-Kompatibilität sauber überprüft werden.
Besonders relevant ist dabei auch der Hinweis auf die Redis-Anbindung. Im Zuge des Symfony-Updates wird für bestimmte Cache-Szenarien eine aktuelle php-redis-Version vorausgesetzt. Wer also Redis aktiv nutzt, sollte nicht nur auf Shopware selbst schauen, sondern auch auf die Serverumgebung und die tatsächlich installierten Extensions.
Das vielleicht wichtigste technische Thema: schnellere DAL-Queries
Aus meiner Sicht ist die Überarbeitung der DAL-Query-Generierung für verschachtelte Filtergruppen eines der stärksten technischen Themen in diesem Release. Bisher konnte es bei komplexeren Criteria-Konstruktionen dazu kommen, dass Shopware immer mehr LEFT JOINs erzeugt hat. Gerade dann, wenn mehrere Filter auf dieselbe Relation angewendet wurden, wurde das schnell teuer.
Shopware geht hier jetzt einen anderen Weg und setzt in diesen Fällen auf EXISTS-Subqueries. Das klingt erst einmal technisch, hat aber in der Praxis klare Auswirkungen: weniger Join-Explosionen, sauberere SQL-Generierung und deutlich bessere Performance in komplexen Abfragen.
Wer schon einmal mit komplizierteren Criteria-Strukturen, Produktfiltern oder Order-Abfragen gearbeitet hat, weiß, wie schnell solche Dinge in größeren Datenbeständen problematisch werden können. Genau deshalb ist diese Änderung für mich kein kleines internes Detail, sondern ein echter Qualitätsgewinn für die Plattform.
ProductCategoryDenormalizer: kleines Detail, große Wirkung
Ebenfalls spannend ist die Optimierung beim ProductCategoryDenormalizer. Shopware beschreibt hier einen sehr deutlichen Performance-Sprung, weil die zugrunde liegende SQL-Abfrage nun besser über indizierte Spalten eingeschränkt wird, statt in problematischen Fällen unnötig große Datenmengen zu scannen.
Gerade in größeren Katalogen ist das relevant. Solche Stellen fallen im Alltag oft nicht sofort auf, sorgen aber genau dann für Reibung, wenn Sortimente wachsen und Prozesse unter Last laufen. Solche Optimierungen sind deshalb oft wertvoller als jede sichtbare UI-Neuerung.
product.states ist auf dem Weg raus – product.type wird wichtiger
Eine der wichtigsten Änderungen für Entwickler ist die Deprecation von product.states. Künftig soll stattdessen stärker mit product.type gearbeitet werden. Shopware trennt damit klarer zwischen fachlicher Produktart und dem bisher teilweise überladenen State-Konzept.
Für bestehende Projekte ist das kein Thema, das man ignorieren sollte. Wenn eigene Logik, Rules, Product Streams, Listing-Filter oder Plugin-Code noch auf product.states aufbauen, ist jetzt der richtige Zeitpunkt, diese Stellen zu identifizieren und mittelfristig umzubauen.
Besonders wichtig ist das auch für individuelle Erweiterungen rund um digitale Produkte oder Sonderlogiken. Wer hier früh reagiert, vermeidet später unnötigen Anpassungsdruck beim nächsten Major Release.
Custom Fields werden bei der Suche bewusster behandelt
Eine weitere technische Änderung betrifft die Suchbarkeit von Custom Fields. Diese sind nun standardmäßig nicht mehr automatisch suchbar. Stattdessen muss die Suchbarkeit gezielt aktiviert werden.
Das ist aus meiner Sicht ein sinnvoller Schritt. In vielen Projekten sammeln sich über die Zeit zahlreiche Custom Fields an, von denen ein großer Teil gar nicht in die Produktsuche gehört. Wenn wirklich alles indexiert wird, bläht das den Suchindex unnötig auf und kostet Performance. Die neue Logik sorgt hier für mehr Kontrolle und passt besser zu realen Projektanforderungen.
Wichtig ist allerdings: Wenn bestehende Felder nachträglich als suchbar markiert werden, reicht das Setzen der Option allein nicht aus. Dann muss auch der Suchindex entsprechend neu aufgebaut werden.
Mehr Kontrolle beim Caching – aber auch neue Verantwortung
Auch im Bereich Cache bringt Shopware 6.7.7.0 einige Änderungen mit, die man als Entwickler im Blick haben sollte. Unter anderem wurden zusätzliche Store-API-Routen besser in die tag-basierte Cache-Invalidierung eingebunden. Gleichzeitig hat Shopware an anderer Stelle bewusst eine bestehende Invalidierungslogik entfernt, weil sie in bestimmten Konstellationen zu Performance-Problemen und regelrechten Invalidation-Stürmen führen konnte.
Das zeigt gut, wohin die Reise geht: Shopware versucht, das Caching präziser und performanter zu machen. Für Entwickler heißt das aber auch, dass man eigene Caching-Annahmen regelmäßig hinterfragen sollte. Vor allem bei größeren Shops, individuellen Listings, property-basierten Filtern oder stark angepassten Storefronts kann das Verhalten nach einem Update an manchen Stellen anders ausfallen als bisher.
Auch kleinere technische Details sind für Entwickler relevant
Neben den großen Themen gibt es noch einige kleinere Punkte, die in Summe trotzdem wichtig sind. Dazu gehört zum Beispiel der neue RequestParamHelper als Reaktion auf Änderungen rund um Symfony Request-Zugriffe. Außerdem wurde der TranslationLoader dekorierbar gemacht, was für Erweiterungen mit eigener Logik interessant sein kann.
Auch die Domain Exceptions sind technisch sauberer aufgestellt, weil Shopware hier künftig konkretere Exception-Klassen zurückgibt statt pauschal generische RuntimeExceptions zu erzeugen. Solche Änderungen klingen zunächst unspektakulär, verbessern aber langfristig Wartbarkeit, Debugging und Klarheit im Code.
Mein Fazit zu Shopware 6.7.7.0
Für mich ist Shopware 6.7.7.0 vor allem ein starkes Entwickler-Release. Nicht wegen eines einzelnen großen Features, sondern weil viele technische Verbesserungen genau dort ansetzen, wo sie in echten Projekten Wirkung entfalten: bei Performance, klareren Strukturen, Deprecation-Pfaden und einer moderneren technischen Basis.
Besonders relevant sind aus meiner Sicht das Symfony-Update auf 7.4, die neue DAL-Strategie für verschachtelte Filter und der Wechsel von product.states hin zu product.type. Wer Shopware professionell entwickelt, sollte dieses Release nicht nur installieren, sondern auch inhaltlich verstehen.
Genau das ist am Ende der Unterschied zwischen „Update eingespielt“ und „Plattform sauber weitergedacht“.
Offizielle Release Notes
Die offiziellen technischen Details zu diesem Release findest du hier: Release Notes Shopware 6.7.7.0.