Was Shopware 6.7 fertig mitliefert und abgeschaltet lässt
Achtzehn Feature-Flags, sechzehn davon aus. Acht werden im nächsten Major zum Standard — und drei davon ändern Verhalten, auf das heute Integrationen bauen.
Eine Versionsnummer sagt, was da ist. Sie sagt nicht, was davon eingeschaltet ist. Bei Shopware 6.7 liegt zwischen beidem eine ganze Liste.
Die Zahlen
| 6.6.10.6 | 6.7.13.1 | |
|---|---|---|
| Feature-Flags im Kern | 7 | 18 |
| davon ab Werk an | 0 | 2 |
| davon ab Werk aus | 7 | 16 |
davon aus und major | 5 | 8 |
Die beiden, die in 6.7 an sind, waren in 6.6 aus: DISABLE_VUE_COMPAT und
ACCESSIBILITY_TWEAKS. Das ist der normale Lauf — ein Flag wandert von
„experimentell" über „Standard im nächsten Major" zu „an".
Interessant ist die letzte Zeile.
Der Unterschied, auf den es ankommt
Jedes Flag trägt im Kern zwei Angaben. default sagt, ob es heute an ist.
major sagt, ob es im nächsten Major zum Standard wird — ohne dass jemand
es einschaltet.
- name: JSON_LD_DATA
default: false
major: true
Ein Flag mit major: false ist ein Experiment. Man kann es ausprobieren,
und man muss es nicht.
Ein Flag mit major: true ist eine Ankündigung. Es beschreibt den Zustand,
in dem sich die Installation nach dem nächsten großen Update befinden wird.
Genau deshalb ist die Liste der acht das nützlichste Update-Dokument, das eine 6.7-Installation mitbringt — und es steht in keiner Änderungsliste.
Die acht, die 6.8 zum Standard macht
| Flag | was sich ändert |
|---|---|
JSON_LD_DATA | Microdata im Storefront wird durch JSON-LD ersetzt. Die itemprop-Attribute verschwinden aus dem HTML |
WEBHOOKS_REWORK | Webhook-Wiederholungen laufen über eine eigene Outbox statt über den Messenger |
FLOW_EXECUTION_AFTER_BUSINESS_PROCESS | Abläufe starten erst, nachdem die eigentliche Arbeitseinheit abgeschlossen ist |
DOCUMENT_GENERATION_REWORK | neue Implementierung der Dokumenterzeugung samt geänderter Oberfläche |
BREADCRUMB_REWORK | neues Laden der Brotkrumen, Produktpfade werden aufbaubar |
REPEATED_PAYMENT_FINALIZE | wiederholte Aufrufe von /payment/finalize-transaction mit demselben Token werden zulässig |
PERMANENT_AUTOMATIC_PROMOTIONS | automatische Aktionen lassen sich nicht mehr entfernen |
PERFORMANCE_TWEAKS | Sammelflag für Änderungen, die Leistung gegen Verhalten tauschen |
Dazu acht weitere mit major: false — echte Experimente, darunter
MCP_SERVER, CACHE_REWORK, TELEMETRY_METRICS und
ENABLE_OPENSEARCH_FOR_ADMIN_API.
Die drei, die in Projekten wehtun
WEBHOOKS_REWORK. Wer heute darauf baut, dass ein fehlgeschlagener Webhook
nach einem bekannten Muster wiederholt wird, baut auf den Messenger. Die
Umstellung verlegt das in eine eigene Outbox. Die Abstände und die Zahl der
Versuche sind heute Teil des Vertrags zwischen Shop und Empfänger — und dieser
Vertrag ändert sich.
FLOW_EXECUTION_AFTER_BUSINESS_PROCESS. Heute startet ein Ablauf innerhalb
der laufenden Arbeitseinheit. Künftig danach. Für die meisten Abläufe ändert das
nichts. Für einen Ablauf, der auf einen Datenstand zugreift, den die laufende
Transaktion gerade erst erzeugt, ändert es alles — in die richtige Richtung, aber
es ändert etwas.
DOCUMENT_GENERATION_REWORK. Wer eigene Dokumentvorlagen pflegt oder den
Erzeuger erweitert hat, bekommt eine neue Implementierung unter den Füßen.
Die Entscheidung
Die Frage ist nicht „einschalten oder nicht". Die Frage ist, wann man hinschaut.
| Situation | was zu tun ist |
|---|---|
| Update auf 6.8 steht an | Die acht Flags einzeln durchgehen. Jedes ist ein Verhaltensänderung, die ohne Zutun kommt |
| Integration wird gerade gebaut | Gegen das Verhalten mit aktiviertem Flag bauen, wenn der Bereich betroffen ist. Sonst baut man gegen einen Zustand mit Verfallsdatum |
| Storefront-Anpassungen im HTML | JSON_LD_DATA testweise einschalten. Wer itemprop im eigenen Template verarbeitet, merkt es sofort |
| Nichts davon trifft zu | Nichts tun. Acht Flags sind acht, nicht achtzig |
Der praktische Weg ist einfach: Ein Flag in einer Kopie der Installation
einschalten, die betroffene Funktion durchspielen, Ergebnis notieren. Genau so
haben wir JSON_LD_DATA und MCP_SERVER geprüft — und in beiden Fällen war das
Ergebnis eindeutiger als jede Beschreibung.
Ein Fallstrick beim Nachmessen
bin/console feature:list zeigt die registrierten Flags mit Status — aber
nicht die major-Kennzeichnung. Genau die ist die interessante Angabe. Sie
steht in feature.yaml im Kern.
Und noch eine Warnung aus eigener Erfahrung: Ein Flag zu setzen, das die
installierte Version gar nicht kennt, führt nicht zu einem Fehler. Es führt zu
einem stillen Nichts — die Umgebungsvariable wird angenommen, Feature::isActive
meldet sogar true, und trotzdem ändert sich nichts, weil kein Code darauf
hört. Wir sind darauf hereingefallen und haben es erst bemerkt, als die
Gegenprüfung ergab, dass die betreffende Version das Flag in null Dateien trägt.
Grenzen dieser Messung
Gezählt sind Flags, nicht Auswirkungen. Was ein Flag im Einzelnen ändert, steht in seiner Beschreibung im Kern — und die ist bei manchen ein Satz. Zwei der acht haben wir tatsächlich eingeschaltet und gemessen; über die übrigen sechs sagt dieser Text nur, dass sie existieren, aus sind und zum Standard werden.
Die Zahlen gelten für 6.6.10.6 und 6.7.13.1. Eine andere Patch-Version kann eine
andere Flagliste haben — 6.7.2.2 etwa kennt CACHE_REWORK noch nicht.
Häufige Fragen
- Was bedeutet major:true bei einem Feature-Flag?
- Dass das Verhalten hinter dem Flag im nächsten Major zum Standard wird. Das Flag ist dann keine Option mehr, sondern die Voreinstellung — und das Flag selbst verschwindet.
- Kann ich ein Flag einfach einschalten?
- Technisch ja, über eine Umgebungsvariable mit dem Flagnamen. Fachlich ist es eine Entscheidung je Flag: Einige ändern nur die Administration, andere ändern das HTML der Storefront oder das Wiederholungsverhalten von Webhooks.
- Wie sehe ich, welche Flags meine Installation kennt?
- bin/console feature:list zeigt die registrierten Flags mit ihrem Status. Die Datei feature.yaml im Kern zeigt zusätzlich die major-Kennzeichnung, die in der Konsolenausgabe fehlt.
- Betrifft das auch 6.6?
- 6.6 hat sieben Flags, fünf davon major. Das Prinzip ist dasselbe, nur der Umfang ist kleiner — und die relevanten Flags sind andere.