Redaktioneller Hinweis vom 08.04.2026: Dieser Beitrag kommentiert gezielt das Release 6.7.7.0 vom 02.02.2026. Trotz späterer redaktioneller Anpassungen bezieht sich die fachliche Einordnung bewusst auf genau diesen Release-Stand.

Shopware 6.7.7.0 wurde am 2. Februar 2026 veröffentlicht und ist eines dieser Releases, die im Changelog schnell technisch klingen, im Alltag aber echte Auswirkungen haben. Für Entwickler sind vor allem drei Themen interessant: modernere Framework-Basis, spürbare Performance-Verbesserungen an kritischen Stellen und klarere Deprecation-Pfade.

Wenn du Shopware professionell betreust, lohnt sich dieser Release-Stand deutlich mehr als nur ein oberflächlicher "Update eingespielt"-Blick.

Was an 6.7.7.0 sofort auffällt

Shopware beschreibt 6.7.7.0 selbst als Minor Release mit starker Mischung aus Performance-Verbesserungen, developer-focused enhancements und Stabilitätsfixes. Getestet wurde dieser Stand laut Release Notes auf:

  • PHP 8.2, 8.4 und 8.5
  • MySQL 8 und MariaDB 11

Das allein ist schon ein Signal, wie modern die erwartete Zielumgebung inzwischen gedacht wird.

Symfony 7.4 ist nicht nur ein Häkchen im Changelog

Alle Symfony-Pakete wurden in 6.7.7.0 auf Version 7.4 angehoben. Für produktive Projekte ist das wichtig, weil damit nicht nur neue Framework-Versionen einziehen, sondern auch Kompatibilitätsfragen sichtbarer werden.

Besonders relevant ist das für:

  • eigene Plugins
  • interne Bundles
  • Admin-Erweiterungen
  • Caching-Setups mit Redis

Shopware verweist in den Release Notes außerdem darauf, dass Symfony 7.4 für bestimmte Cache-Szenarien eine aktuelle php-redis-Extension voraussetzt. Das ist genau die Art Detail, die in Staging oft funktioniert und in Produktion später Ärger macht, wenn sie übersehen wurde.

Die vielleicht wichtigste Verbesserung: DAL-Queries für verschachtelte Filter

Aus Entwicklersicht ist die Überarbeitung der DAL-Query-Generierung eines der stärksten Themen in diesem Release. Shopware stellt bei verschachtelten Filtergruppen von einer Join-lastigen Strategie stärker auf EXISTS-Subqueries um.

Warum das wichtig ist:

  • weniger Join-Explosionen bei komplexen Criteria
  • sauberere SQL-Generierung
  • bessere Performance bei komplizierten Relationen

Gerade in größeren Projekten mit komplexen Produkt- oder Order-Abfragen kann das einen echten Unterschied machen. Wer schon einmal zähe Criteria-Konstruktionen debuggt hat, weiß, wie schnell sich solche Dinge auf Antwortzeiten und Datenbanklast auswirken.

ProductCategoryDenormalizer: kleines Changelog, reale Wirkung

Zusätzlich wurde der ProductCategoryDenormalizer optimiert. Laut Release Notes läuft die zugrunde liegende SQL-Abfrage nun über besser eingeschränkte, indizierte Bedingungen und kann damit auf großen Katalogen drastisch schneller werden.

Das ist genau die Art Verbesserung, die man im Marketing selten groß herausstellt, die im Betrieb aber sehr viel wert sein kann.

Custom Fields: Suche bewusster statt automatisch

Ein weiterer spannender Punkt: Produkt-Custom-Fields sind in 6.7.7.0 nicht mehr automatisch suchbar. Stattdessen muss die Suchbarkeit gezielt aktiviert werden.

Das ist sinnvoll, weil in vielen Projekten über Jahre immer mehr Custom Fields wachsen, die in der Suche gar nichts verloren haben. Die neue Logik hilft dabei:

  • Indexgröße zu reduzieren
  • Suche gezielter zu steuern
  • Performance bei vielen Feldern besser im Griff zu behalten

Wichtig ist dabei der operative Teil: Wenn du bestehende Felder nachträglich als suchbar markierst, reicht die Option allein nicht. Dann muss der Suchindex sauber neu aufgebaut werden.

product.states geht raus, product.type wird wichtiger

Eine der wichtigsten Architekturänderungen für Shopware-Entwickler ist die Deprecation von product.states zugunsten von product.type.

Das ist besonders relevant, wenn du bisher eigene Logik gebaut hast für:

  • digitale Produkte
  • Produkt- und Listing-Filter
  • Rules und Product Streams
  • Checkout-nahe Line-Item-Logik

Je früher du diese Stellen im Code identifizierst, desto weniger Anpassungsdruck entsteht später. In professionellen Projekten ist das genau die Art technische Schuld, die man lieber in einem planbaren Fenster abbaut als erst kurz vor dem nächsten Major Release.

RequestParamHelper und kleinere API-/Core-Details

Nicht jede Verbesserung in 6.7.7.0 ist spektakulär, aber mehrere kleinere Punkte sind für Entwickler trotzdem nützlich:

  • neuer RequestParamHelper als Reaktion auf Änderungen rund um Request::get()
  • TranslationLoader ist jetzt dekorierbar
  • Domain Exceptions sind klarer typisiert

Das sind keine Schlagzeilen-Themen, aber sie verbessern Debugging, Erweiterbarkeit und Wartbarkeit im Alltag.

Cache-Änderungen: mehr Kontrolle, aber auch mehr Verantwortung

Auch beim Caching hat sich in 6.7.7.0 etwas getan:

  • zusätzliche Store-API-Routen unterstützen Tag-basiertes Invalidieren
  • Logging für invalidierte Cache-Tags wurde ergänzt
  • bestimmte Invalidation-Pfade wurden wegen Performance-Problemen entfernt

Spannend ist dabei vor allem, dass Shopware nicht einfach "mehr Invalidierung" baut, sondern präziser werden will. Für größere Shops bedeutet das:

  • eigene Cache-Annahmen kritisch prüfen
  • Verhalten nach Updates nicht als gegeben ansehen
  • Property- und Listing-Setups nach Release-Wechseln bewusst beobachten

Wenn Performance ohnehin schon ein Thema ist, lohnt sich parallel ein Blick in meine Artikel zur Performance-Optimierung in Shopware und zur Datenbank-Optimierung für Shopware.

Für wen dieses Release praktisch besonders relevant ist

6.7.7.0 ist vor allem dann relevant, wenn du:

  • eigene Plugins entwickelst
  • Admin oder Storefront tief erweiterst
  • komplexe DAL-Queries im Projekt hast
  • digitale Produkte oder spezielle Produkttypen abbildest

Dann ist das Release kein Hintergrundrauschen, sondern ein echter Hinweis darauf, wo du Code und Architektur anpassen solltest. Wenn genau dort individuelle Logik in deinem Shop sitzt, ist saubere Shopware Plugin-Entwicklung meistens der Hebel, um das Update nicht nur technisch, sondern strukturell sauber mitzunehmen.

Fazit

Shopware 6.7.7.0 ist ein starkes Entwickler-Release. Nicht weil ein einzelnes Feature alles verändert, sondern weil mehrere technische Verbesserungen genau an den Stellen ansetzen, die in echten Projekten später teuer werden: Query-Performance, Caching, Deprecations und Framework-Kompatibilität. Wer Shopware professionell weiterentwickelt, sollte dieses Release nicht nur installieren, sondern inhaltlich verstehen.

FAQ

Was ist in Shopware 6.7.7.0 für Entwickler am wichtigsten?

Vor allem das Symfony-7.4-Update, die neue DAL-Strategie für verschachtelte Filter, die Deprecation von product.states und die präzisere Cache-Logik.

Warum sind die DAL-Änderungen in 6.7.7.0 so relevant?

Weil Shopware bei komplexen verschachtelten Filtern stärker mit EXISTS-Subqueries statt mit vielen LEFT JOINs arbeitet. Das kann in echten Projekten spürbar Performance kosten oder sparen.

Sollte ich meinen Plugin-Code wegen 6.7.7.0 aktiv prüfen?

Ja, vor allem wenn du eigene DAL-Logik, digitale Produkte, Custom-Field-Suche, Redis-Setups oder tiefere Admin- und Storefront-Erweiterungen im Einsatz hast.

Tags:

Shopware 6 Shopware