Shopware 6.7.16: Neuerungen im November

Ein Feature-Release mit zwei Pflichtprüfungen

Shopware hat am 2. November 2026 die Version 6.7.16 veröffentlicht, wie jeden Monat ein Feature- und Bugfix-Update innerhalb des 6.7-Zweigs. Nach dem großen Umbau der Administration in 6.7.15 fällt dieser Schritt äußerlich ruhiger aus. Zwei Änderungen verlangen trotzdem Aufmerksamkeit vor dem Update: Die Rabattdarstellung in der Storefront folgt jetzt dem 30-Tage-Niedrigstpreis, und Integrationen verlieren ihren MCP-Zugriff, bis jemand ihn ausdrücklich freigibt.

Zum Nachlesen: die Release News von Shopware für die Händler-Sicht und das vollständige Original-Changelog auf GitHub für alle Code-Änderungen. Getestet ist das Release auf PHP 8.2, 8.4 und 8.5 sowie MySQL 8 und 9.7, MariaDB 11 und 12.

Preise und GARAN in der Storefront

Die Ersparnis bezieht sich auf den Niedrigstpreis. Ist für ein Produkt der niedrigste Preis der letzten 30 Tage hinterlegt, berechnet die Storefront den Rabatt in Prozent jetzt gegen diesen Wert und nicht mehr gegen den Streichpreis. Der durchgestrichene Listenpreis entfällt in dem Fall, Rabatt-Badges und die Hervorhebung des Aktionspreises erscheinen nur noch, solange der Verkaufspreis tatsächlich unter dem Niedrigstpreis liegt. Shopware setzt damit Artikel 6a der EU-Preisangabenrichtlinie um, so wie ihn der Europäische Gerichtshof 2024 in der Rechtssache C-330/23 ausgelegt hat. Der Textbaustein lautet jetzt „Niedrigster Preis (letzte 30 Tage)" statt „vorher". Themes, die die Preis-Templates überschreiben, müssen nachziehen: Die Variable für den Streichpreis ist bei gesetztem Niedrigstpreis leer, eine neue Variable zeigt an, ob eine Ersparnis vorliegt.

GARAN bekommt Garantiebedingungen. Das GARAN-Label aus 6.7.14 wird in der dritten Runde ausgebaut. Je Produkt lassen sich Garantiebedingungen als PDF oder Link hinterlegen, die Kunden in der Storefront aufrufen. Das verkürzte Label ist jetzt eine Schaltfläche, die das vollständige Label öffnet, in Warenkorb und Bestellung als Dialog, auf der Produktseite ausgeklappt. Beim Bestellabschluss speichert Shopware die GARAN-Angaben an der Bestellung, spätere Änderungen am Produkt verändern die Bestellung also nicht mehr. Neu ist außerdem eine Warenkorb-Einstellung, die den vollständigen Gewährleistungshinweis direkt unter den AGB im Checkout anzeigt. Sie ist standardmäßig aus und setzt den allgemeinen Gewährleistungshinweis voraus. Der kombinierte Textbaustein für AGB und Gewährleistung wurde in zwei getrennte aufgeteilt, Theme-Überschreibungen der Bestätigungsseite brauchen deshalb eine Anpassung.

Checkout-Zustimmungen leben nur noch in der Sitzung. Die Häkchen für AGB und Widerruf sowie der Kundenkommentar überstehen weiterhin einen Seitenwechsel innerhalb des Checkouts, etwa nach dem Wechsel der Zahlungsart, aber nicht mehr das Schließen des Browsers. Leerer Warenkorb, Bestellbestätigung und Logout setzen die Daten zurück. Themes, die diese Templates ersetzen, müssen das zugehörige Datenattribut mitnehmen.

Vier kritische Fixes

Theme-Vererbung speichert durch. Wer ein Basis-Theme speichert, aktualisiert jetzt die Konfiguration aller abgeleiteten Themes über alle Ebenen hinweg und kompiliert sie neu. Bisher brauchte jedes Kind- und Enkel-Theme einen eigenen Speichervorgang. Eigene Überschreibungen der abgeleiteten Themes bleiben erhalten. Zugleich lässt sich ein Basis-Theme nicht mehr deaktivieren oder deinstallieren, solange ein abgeleitetes Theme einem Verkaufskanal zugewiesen ist; die Fehlermeldung nennt die betroffenen Themes und Kanäle.

Zwei Rule-Builder-Fehler mit Auswirkung auf Promotions. Seit 6.7.14 prüften die meisten Positionsbedingungen nur noch Positionen vom Typ Produkt. Individuelle Positionen, Gutschriften und alles, was Erweiterungen in den Warenkorb legen, fiel durch, und eine einzige solche Position konnte unter einer verneinten Bedingung Versandarten ausblenden oder Promotions blockieren. Jetzt zählt wieder, welche Daten eine Position trägt, nicht ihr Typ. Der zweite Fehler bestand seit 6.7.9: Die Bedingung „Verhältnis Preis zu Streichpreis" behandelte Produkte ohne Streichpreis so, als wäre das Verhältnis null. „Kleiner als 1" traf damit jedes Produkt ohne Streichpreis, und Aktionen für reduzierte Ware galten für das ganze Sortiment. Produkte ohne Streichpreis haben jetzt kein Verhältnis mehr, nur noch „ist ungleich" und „ist leer" treffen sie. Wer bisher „ist gleich 0" nutzte, um genau diese Produkte zu erfassen, stellt die Regel auf „ist leer" um.

Content Security Policy für statische Dateien. Die Apache-Vorlage .htaccess.dist liefert für vorhandene HTML-Dateien unter public/media und public/thumbnail sowie für SVG-Dateien jetzt eine strenge Richtlinie aus, die Skripte, eingebettete Objekte, Frames und Formulare unterbindet. Bilder und Stile bleiben erlaubt. Das greift nur, wenn die deployte .htaccess den aktualisierten Shopware-Abschnitt enthält; Installationen ohne die Shopware-Markierungen müssen den Block von Hand übernehmen.

Standardwährung wieder erreichbar. Seit 6.7.15 lieferte der Verkaufskanal im Kontext die aktuell gewählte statt der Standardwährung zurück. Erweiterungen, die die Standardwährung lesen, bekommen sie wieder; für die gewählte Währung gibt es weiterhin die Methode am Kontext selbst.

Was in der Administration sichtbar wird

Die Positionsliste einer Bestellung blättert ab mehr als zehn Positionen seitenweise mit wählbarer Seitengröße, und farbige Statuspunkte zeigen den Bestellstatus in der Auswahl an. Bei Produkten und Kategorien zählen die SEO-Felder ihre Zeichen gegen die empfohlene Länge und heben den Hinweis hervor, wenn sie überschritten wird: Kategorien 70 Zeichen für den Titel und 150 für die Beschreibung, Produkte 56 und 155. Das erste Hauptmenü heißt jetzt „Produkte", der Produktlisten-Eintrag „Übersicht", und die Rechtegruppen unter Benutzer und Berechtigungen folgen der Menüreihenfolge statt dem Alphabet. Autofill-Felder sind im Dark Mode lesbar, und Shopware weist darauf hin, dass die globale Schriftkonfiguration geändert wurde: Einige Glyphen sehen anders aus und Text fällt etwas schmaler aus.

Digitale Produkte lassen sich mit der neuen Option „Mehrere Einheiten pro Bestellung erlauben" mit Mindestmenge, Mengenstaffel und Höchstmenge konfigurieren und auf Wunsch ohne hochgeladene Dateien speichern, wenn die Dateizuordnung ein externes System übernimmt. Plugin-Konfigurationen können ihre Karten in Tabs gruppieren, sofern der Entwickler das in der config.xml vorsieht; Karten ohne Tab landen automatisch unter „Allgemein".

Für Entwickler

Jede Store-API-Route hat ein Extension Event. Statt die abstrakte Route zu dekorieren, hängt sich ein Subscriber an das Event der jeweiligen Route und verändert Eingaben, Ergebnis oder Fehlerbehandlung. Apps können über neue Manifest-Einträge eigene SEO-URLs für Storefront-Seiten und Entity-Routen definieren, die Shopware bei Änderungen an den Entitäten automatisch nachzieht.

Administration: Imports und Composables, experimentell. Erweiterungen können ausgewählte APIs direkt aus Modulen wie shopware:utils, shopware:data und shopware:composables importieren, statt über das globale Objekt zu gehen. Die Composables ersetzen die bisherigen Mixins. Beides ist ausdrücklich experimentell und soll mit 6.8 beziehungsweise 6.9 stabil werden. Eine Erweiterung, die shopware:composables importiert, muss in ihrer composer.json mindestens 6.7.16.0 verlangen, auf älteren Versionen wirft der Import einen Fehler. Die Entfernung von $tc() und der Komponente sw-empty-state ist von 6.8 auf 6.9 verschoben, Entwicklungs-Builds warnen jetzt pro Fundstelle. defineModel() funktioniert in Basis-Komponenten, Blöcke von sw-block werden über Komponente plus Blockname identifiziert statt über den Namen allein.

Textfelder gehen durch HTMLPurifier. Zeichenketten ohne HTML-Erlaubnis werden nicht mehr mit strip_tags() bereinigt. Ein <, das keinen Tag beginnt, bleibt erhalten, ein Produkt namens „I <3 Kisses" wird also wieder gefunden; der Inhalt entfernter script- und style-Elemente wird jetzt komplett verworfen. Nach dem Update gehört ein dal:refresh:index dazu, damit die Suchindizes bestehender Produkte den neuen Regeln folgen.

Weitere Punkte im Kern. Systemaktivitäten wie Logins oder Konfigurationsänderungen landen als Monolog-Einträge auf dem Kanal system_activity, standardmäßig in der Tabelle log_entry. Snippets für Administration und Storefront können aus dem privaten Dateisystem kommen, als unterste Prioritätsebene für Schlüssel, die sonst niemand liefert. Ein neues ProductBackInStockEvent meldet Produkte, die wieder verfügbar werden; das bisherige Event meldet nur noch die Gegenrichtung, wer beide Fälle behandelt, abonniert beide. Der Flow Builder bekommt eine Bedingung „Tage seit Bestellung". Drei Verhaltensänderungen aus 6.8 lassen sich einzeln vorab einschalten: kodierte Medien-URL-Pfade, anteilige Steuerberechnung im Warenkorb und das frühere Löschen des gespeicherten Warenkorbs nach der Bestellung.

Theme-Verzeichnisse und Deploy-Skripte. Ein nicht mehr genutztes public/theme-Verzeichnis wird frühestens 24 und spätestens 48 Stunden nach dem Wechsel gelöscht, gemessen ab dem Wechsel statt ab der Kompilierung. Bisher konnte ein Wochen zuvor kompiliertes Theme direkt nach dem Rekompilieren verschwinden, während ein CDN noch darauf zeigte. theme:compile und theme:change räumen selbst nicht mehr auf, die Option --no-cleanup ist wirkungslos und fliegt mit 6.8 raus, Deploy-Skripte sollten sie entfernen.

Für kommerzielle Pläne

Jenseits der Community Edition ist Shopware Nexus allgemein verfügbar. Konnektoren entstehen dort per Konfiguration statt per Programmierung, laut Shopware stehen über 40 vorgefertigte bereit, und Copilot hilft beim Erstellen und Fehlersuchen von Workflows. Aus dem Agentic Commerce Lab kommt mit Bright Shelf eine Research Preview, die aus der Shop-URL Markentonalität ableitet und daraus Produkt- und Marketingbilder vorschlägt. Beides läuft unabhängig vom regulären Release.

Was das für den Betrieb heißt

Zwei Punkte gehören vor das Update auf die Liste. Erstens die MCP-Allowlist: Eine leere Liste bedeutete bisher „alles erlaubt", jetzt bedeutet sie „nichts erlaubt". Bestehende Integrationen und Benutzer ohne Administratorrechte verlieren damit den Zugriff auf alle MCP-Funktionen, bis jemand sie unter Einstellungen, System, Integrationen oder am Benutzer freigibt. Wer den seit 6.7.11 experimentellen MCP-Server von Shopware produktiv nutzt, prüft das am besten direkt nach dem Update auf Staging. Zweitens die Preisdarstellung: Shops mit gepflegtem Niedrigstpreis sehen andere Rabattprozente und keine Streichpreise mehr. Das ist rechtlich richtig, überrascht aber Marketing und Kundenservice, wenn niemand Bescheid weiß.

Danach die üblichen Prüfungen: Theme-Überschreibungen an Preis-, GARAN- und Checkout-Templates abgleichen, den .htaccess-Block für die Content Security Policy übernehmen, dal:refresh:index laufen lassen, Rule-Builder-Regeln mit „ist gleich 0" auf dem Streichpreis-Verhältnis umstellen und Plugins mit eigener Admin-Oberfläche einmal durchklicken. Für den 6.6-Zweig erschien parallel 6.6.10.30 mit einer einzelnen Korrektur am App-System.

Wer die monatlichen Releases regelmäßig einspielt, hat bei jedem einzelnen den kleinsten Sprung. Auf der Shopware-Seite gibt es dafür Wartungspakete mit festem Update-Check, und wer vor einem größeren Rückstand steht, findet über die Wartung Unterstützung beim Aufholen.

Supportstatus aller Versionen

Welche Shopware-, PHP- und Datenbank-Version noch Updates bekommt und wo der aktuelle Patchstand liegt, steht dauerhaft unter Shopware-Versionen und Supportstatus. Die Seite wird mit jedem Release nachgezogen.