Regressions-Register

REG-0001 — Das Element blieb leer, wenn ein anderes Plugin fehlte

Symptom. Auf der Verkaufsseite blitzte kurz die Grundstruktur auf, danach blieb die Liste leer — ohne Fehlermeldung. Im Adminbereich zeigte die Vorschau dieselbe Konfiguration korrekt an, weil sie die Produkte über die Admin-API holt und nicht über den Weg, den das Storefront nimmt. Im Netzwerkfenster des Browsers:

Der Stapelabzug nannte ProductTranslationDefinition — der fehlerhafte Filter steckte also nicht im Hauptfilter, sondern in einer Verknüpfung.

Ursache. Das Storefront-JavaScript filterte die Verknüpfungen translations und seoUrls auf window.activeLanguageId:

Diese globale Variable setzt Shopware nirgends — im gesamten Core gibt es keinen Treffer. Gesetzt hat sie einzig business-transactions, in dessen eigener meta.html.twig. Ohne dieses Plugin war der Wert undefined, fiel beim Serialisieren aus der Anfrage heraus, und der Server wies sie ab.

ajax-listing hing damit undeklariert an einem fremden Plugin — nicht über composer.json, sondern über eine zufällige Kopplung im Browser. Und business-transactions ist vom Verkauf genommen: Wer ajax-listing kaufte, bekam ein Element, das leer blieb.

Behebung. Sprache und Verkaufskanal kommen jetzt aus den Element-Optionen, die die Twig-Vorlage füllt — dort, wo accessKey und domain bereits standen. Zusätzlich entfällt associations.translations ersatzlos: sie wurde angefordert, aber nirgends gelesen; die Vorlage nutzt product.translated.name und .description, die die Store-API ohnehin passend zum Kontext liefert. Damit verschwand einer der beiden kaputten Filter, ohne dass er ersetzt werden musste.

business-transactions bleibt unangetastet — dort ist die Variable für den Eigengebrauch legitim.

Warum es lange unentdeckt blieb. In der Entwicklungsumgebung war das andere Plugin installiert; dort funktionierte alles. Nichts schlug fehl, was jemand gesehen hätte: kein Testfehler, kein Eintrag in der statischen Analyse, keine Fehlermeldung im Frontend. Der Adminbereich zeigte sogar das Gegenteil.

Test. src/Test/StorefrontGlobalsTest.php — prüft das gebaute Bündel: Jede gelesene globale Variable muss entweder vom Bündel selbst gesetzt sein, ein Baustein des Browsers, oder Storefront-Maschinerie (PluginManager). Alles andere ist eine Wette darauf, dass jemand Fremdes etwas bereitstellt. Bewusst allgemein gehalten: die Regel gilt für jede künftige Globale, nicht nur für diese eine.

REG-0002 — Das Element hatte im Editor kein Vorschaubild

Symptom. In den Erlebniswelten blieb beim Platzieren oder Ersetzen eines Elements die Kachel von ajax-listing leer — nur der Name stand darunter. Kein Fehler, keine Meldung, im Netzwerkfenster lediglich:

Die Fassung für Shopware 6.6 zeigte das Bild korrekt an.

Ursache. Die Vorschau-Vorlage bat um /ajaxlisting/static/ajax-listing-preview.png. Shopware veröffentlicht src/Resources/public/ eines Plugins jedoch ausschließlich unter dem technischen Namen, und der lautet seit der Vereinheitlichung der Leoparden-Namen LeopardenAjaxListing, ausgeliefert also /bundles/leopardenajaxlisting/…. Der alte Pfad stammte aus der Zeit davor und zeigte damit ins Leere.

Behoben wurde das auf der Linie shopware-6.6 bereits am 19.08.2026 mit d239734 — auf main wurde der Fix nie nachgezogen. Der Fehler ist also nicht 6.7-spezifisch, sondern eine nicht portierte Behebung.

Behebung. Der Pfad nennt jetzt den technischen Namen. Mitgezogen wurden die beiden übrigen Teile desselben Commits, die auf main ebenfalls fehlten: die Schaltfläche an der Produktkachel nutzt statt des geliehenen Fremdschlüssels shop.sub-navigation.configure den eigenen Textbaustein plugin.leoparden.AjaxListing.details (de/en ergänzt), und das erzwungene bg-white entfällt, damit die Themefläche durchscheint.

Nicht übernommen wurde die Zeile mit sw-button: main nutzt dort korrekt mt-button, weil 6.7 auf die Meteor-Komponenten umgestellt hat. Ein pauschales cherry-pick von d239734 hätte die Admin-Ansicht auf 6.7 beschädigt.

Warum es lange unentdeckt blieb. Weder Tests noch statische Analyse sehen einen Zeichenkettenpfad in einer Twig-Vorlage an. Die Storefront war nie betroffen — der Fehler lag ausschließlich im Adminbereich, und dort nur an einer Stelle, die man erst bemerkt, wenn man ein Element neu platziert. Wer das Element bereits im Layout hatte, sah nie etwas Falsches.

Test. src/Test/AdminAssetPathTest.php — prüft jede assetFilter('…')-Angabe der Admin-Quellen: das erste Pfadsegment muss der technische Name aus der composer.json sein, und die Datei muss unter src/Resources/public/ tatsächlich liegen. Bewusst allgemein: der erwartete Name wird abgeleitet, nicht festgeschrieben, damit eine künftige Umbenennung auffällt, statt die Vorschau erneut still zu zerstören.