Regressions-Register

REG-0027 — Die Warengruppe von Hand zuzuordnen blieb wirkungslos

Symptom. Wer im Produktreiter »Warengruppen« eine Gruppe auswählte und speicherte, sah die Auswahl danach wieder — der Artikel bekam aber keinen Rabatt.

Ursache. Der Reiter schrieb in customFields.product_group_api. Dieses Feld gehört nicht zu diesem Plugin, sondern zum CustomField Entity Matcher: dorthin überträgt das ERP den Rohwert, und der Matcher bildet ihn auf die Warengruppe ab. Das Plugin selbst legt product_group an (Typ entity), und ProductLoadedSubscriber liest genau dieses Feld und reicht den Wert als Kennung weiter:

Es passte also weder der Name noch die Art des Werts: der Reiter hielt über sw-entity-single-select bereits eine Kennung in der Hand und rechnete sie über .productGroupMatch in einen Text um, damit er in das ERP-Feld passte. Ohne laufenden Matcher kam die Zuordnung nirgends an.

Fix. Der Reiter schreibt und liest product_group und speichert die Kennung. Der ERP-Weg bleibt unberührt: Das ERP füllt weiterhin das API-Feld, der Matcher schreibt weiterhin in das Auswahlfeld. Beide Wege enden jetzt an derselben Stelle.

Test. src/Test/CustomFieldWiringTest.php und src/Resources/app/administration/test/SwProductGroups.spec.ts — letzterer schrieb den falschen Feldnamen zuvor ausdrücklich fest und sicherte damit den Fehler ab.

REG-0028 — Die Warengruppen-Definition war unter falschem Namen registriert

Symptom. Meldungen der Art »No definition found leoparden_product_group«.

Ursache. services.xml taggte ProductGroupDefinition als leoparden_category_discount_product_group, während die Klasse selbst leoparden_product_group führt — der Name, den zwölf weitere Stellen benutzen. Shopware registriert eine Definition unter dem Namen aus dem Tag; unter dem echten Namen war sie damit nicht zu finden.

Fix. Der Tag nennt jetzt den Namen, den die Klasse selbst führt. Der Test vergleicht jeden Entitäts-Tag in services.xml mit dem, was die getaggte Klasse antwortet — ein Auseinanderlaufen fällt künftig sofort auf.

Test. src/Test/ServiceWiringTest.php

REG-0029 — Eine uninitialisierte Property und zwei Nachlässigkeiten

Symptom. Typed property … ProductPriceCalculator::$decorated must not be accessed before initialization — eine Meldung, die eine interne Property nennt und nichts darüber sagt, was wirklich fehlt.

Ursache. Der dekorierte Rechner kommt erst nach dem Erzeugen des Objekts, über einen <call method="setDecorated"> in services.xml. Bis dahin ist die typisierte Property uninitialisiert, und sie zu lesen liefert nicht null, sondern einen Fehler.

Fix. Die Property ist nullable, und getDecorated() wirft eine DecorationPatternException — eine fehlende Dekoration ist ein Konfigurationsproblem, und dafür gibt es diese Ausnahme.

Im selben Zug entfernt: eine dynamische Property auf dem LineItem-Struct, die gesetzt und nie gelesen wurde (in PHP 8.2 verpönt, in 9 ein Fehler), sowie zehn verwaiste Bau-Artefakte unter public/static/js: Teilstücke des alten Bauverfahrens, deren Einstiegsdatei beim Umstieg auf das neue entfernt wurde. Sie werden von nichts mehr geladen und wurden trotzdem mitgeliefert.

Test. src/Test/ProductPriceCalculatorDecorationTest.php und src/Test/ServiceWiringTest.php