RESPONSE Zubehör direkt in den Warenkorb legen | Bidirektionales Cross Selling

Shopware-6.7-Plugin für kaufbare Zubehörkarten auf der Produktdetailseite.

Architektur 2.0

Version 2.0 ersetzt die frühere App-Architektur mit clientseitigem HTML-Scraping durch serverseitige Shopware-Daten:

• Cross-Selling-Auswahl und der Fallback über eine dynamische Produktgruppe werden beim Laden der Produktdetailseite serverseitig über Shopware Sales-Channel-Routen aufgelöst.
• Es gibt keinen Browser-Request mehr an /store-api/product für den Fallback.
• Es gibt keinen rekursiven Varianten-Graph-Walk, keinen DOMParser und keine vollständigen Produktdetailseiten-Requests zur Preis-/Variantenbestimmung.
• Der initiale „ab/from“-Preis wird serverseitig abgesichert: Das Plugin validiert Shopwares indexierte günstigste Variante in einer gebündelten Sales-Channel-Abfrage. Nur wenn dieser Treffer nicht mehr kaufbar ist, erfolgt eine kleine strukturierte Ersatzsuche für genau diese Variantenfamilie.
• Erst beim Klick auf „Variante wählen“ wird genau ein eigener, HTTP-cachebarer JSON-Endpunkt aufgerufen. Dieser lädt die kaufbaren Varianten strukturiert über die Sales-Channel-Produkt-Route.
• Pro Variantenfamilie werden maximal 500 kaufbare Varianten an den Browser übertragen. Bei größeren Matrizen wird bewusst auf die normale Produktdetailseite verwiesen, statt den Origin mit einem riesigen Variantenlauf zu belasten.
• Wiederholtes Öffnen derselben Variantenfamilie innerhalb einer Seitenansicht verwendet einen In-Memory-Cache im Browser.

Auswahl-Priorität

1. ausdrücklich am Produkt gewähltes Cross-Selling (response_csa_cross_selling_selection)
2. bei aktivierter Ersetzungsoption: automatisch passende, zentral konfigurierte dynamische Produktgruppe(n)
3. global konfigurierter Cross-Selling-Name bzw. erstes aktives Cross-Selling
4. ohne Ersetzungsoption: automatisch passende, zentral konfigurierte dynamische Produktgruppe(n) als Fallback

Die dynamischen Produktgruppen werden zentral in der Plugin-Konfiguration ausgewählt. RESPONSE prüft auf der Produktdetailseite automatisch, ob die aktuell geöffnete Produktfamilie Mitglied einer oder mehrerer dieser Gruppen ist. Eine Pflege von csa_compatibility_group an jedem einzelnen Produkt ist dafür nicht mehr erforderlich. Treffen mehrere ausgewählte Gruppen zu, werden deren Ergebnisse zusammengeführt und nach Produktfamilie dedupliziert.

csa_compatibility_group bleibt als optionaler produktspezifischer Override für Sonderfälle und zur Rückwärtskompatibilität bestehen. Ist dort eine Gruppe ausgewählt, wird diese für das konkrete Produkt vor der zentralen automatischen Erkennung verwendet.

Zusatzfelder

Das Plugin legt bzw. übernimmt das Set response_csa_product_settings mit diesen Produkt-Zusatzfeldern:

• response_csa_cross_selling_selection
• csa_compatibility_group – optionale produktspezifische Shopware-Dynamische-Produktgruppe (product_stream) für Sonderfälle
• response_csa_legacy_compatibility_group – interner Altwert einer früheren Freitext-Kompatibilitätsgruppe (siehe unten); ohne eigenes sichtbares Feld in der Administration (seit 2.0.20 wieder so, nachdem es in 2.0.18/2.0.19 vorübergehend als sichtbares Textfeld verfügbar war)

Für den normalen bidirektionalen Betrieb ist keine Produktpflege mehr erforderlich. Wählen Sie die gewünschten dynamischen Produktgruppen einmal zentral in der Plugin-Konfiguration aus. Enthält eine ausgewählte Gruppe A, B und C, erkennt RESPONSE die Mitgliedschaft automatisch: A zeigt B+C, B zeigt A+C und C zeigt A+B. Das aktuell geöffnete Produkt und seine gesamte Variantenfamilie werden aus den Treffern ausgeschlossen.

Beim Wechsel von der bisherigen App übernimmt das Plugin das vorhandene Set und entfernt die App-Zuordnung (appId), damit die bestehenden Produktwerte erhalten bleiben und das Set nach der Migration vom Plugin verwaltet wird. Ältere freie Textwerte aus csa_compatibility_group werden beim Update intern unter response_csa_legacy_compatibility_group gesichert und aus dem sichtbaren Entity-Auswahlfeld entfernt, damit Shopwares Produktgruppen-Auswahl nicht an einer ungültigen Legacy-ID hängen bleibt. Ist dieses Altfeld nicht leer, hat sein Wert weiterhin Vorrang vor der zentral konfigurierten automatischen Gruppenerkennung – ohne dass dies im Admin an diesem Produkt sichtbar wäre. Betrifft das ein konkretes Produkt (Zubehör kommt trotz korrekter zentraler Konfiguration nicht aus der erwarteten dynamischen Gruppe), kann das Feld bei Bedarf für ein Release vorübergehend wieder als sichtbares Textfeld freigeschaltet werden (siehe 2.0.18–2.0.20).

Migration von der App 1.4.x

Empfohlene Reihenfolge:

1. Bestehende App deaktivieren, noch nicht deinstallieren.
2. Plugin ResponseCrossSellingAccessoriesPlugin installieren und aktivieren.
3. Storefront/Theme kompilieren und Funktion prüfen.
4. Erst danach die alte App deinstallieren.

Beim Installieren/Update kopiert das Plugin die unterstützten Einstellungen aus ResponseCrossSellingAccessories.config.* nach ResponseCrossSellingAccessoriesPlugin.config.*, sofern am Ziel noch kein Wert vorhanden ist. Die alten App-Einstellungen storeApiAccessKey und previewConcurrency werden bewusst nicht übernommen, weil sie in der Plugin-Architektur nicht mehr benötigt werden.

Kompatibilität

• PHP >= 8.2
• Shopware >= 6.7.12 und < 6.8

Die Mindestversion wurde von 6.7.2 auf 6.7.12 angehoben: Ab 6.7.12 gilt sie zusätzlich, weil das Attribut cache-relevant in config.xml (siehe „Cache-Invalidierung bei Konfigurationsänderungen“) erst ab dieser Version vom Shopware-eigenen XML-Schema unterstützt wird; auf älteren 6.7.x-Ständen würde die Aktivierung sonst an der Schema-Validierung scheitern. Ursprünglich wurde 6.7.2 vorausgesetzt, weil das Plugin Shopwares CacheTagCollector::addTag() für korrekte HTTP-Cache-Invalidierung nutzt.

Installation

ZIP in Shopware unter Erweiterungen → Meine Erweiterungen hochladen, installieren und aktivieren. Anschließend das Theme/Storefront neu kompilieren, falls Shopware dies nicht automatisch ausführt.

2.0.21

• Behebt sämtliche von Shopwares statischer Codeanalyse gemeldeten shopware.noEntityRepositoryInLoop-Verstöße (potenzielle N:1-Abfragen): LegacyConfigMigrator::migrate() liest Quell- und Zielwerte jetzt über je eine gebündelte Abfrage über alle unterstützten Konfigurationsschlüssel und schreibt alle Änderungen über ein einziges gesammeltes Upsert, statt Repository-Aufrufe pro Schlüssel innerhalb einer Schleife auszuführen. VariantPriceResolver::resolve() löst den Ersatzpreis für alle noch offenen Variantenfamilien über eine einzige gebündelte, nach Preis sortierte Abfrage auf, statt pro Familie einen eigenen Repository-Aufruf abzusetzen.
• Bestätigt kompatibel mit Shopware 6.7.14: keine Breaking Changes für diesen Code, unter anderem weil die dort neu eingeführte automatische Ausschlusslogik für natives dynamische-Produktgruppen-Cross-Selling nur Shopwares eigenen Mechanismus betrifft, nicht die produktspezifische Fallback-Logik dieses Plugins.

2.0.20

• Entfernt das in 2.0.18 eingeführte sichtbare Textfeld „Interner Altwert (frühere Freitext-Kompatibilitätsgruppe)“ wieder aus dem Zusatzfelder-Bereich, auf ausdrücklichen Wunsch, nachdem der betroffene Altwert bereits geleert wurde. Dies geschieht automatisch beim Plugin-Update (Feld-Definition wird entfernt), unabhängig davon, ob Shopwares deklarative Custom-Fields-Synchronisierung (ab 6.7.13) greift.
• Der zugrunde liegende Mechanismus selbst bleibt unverändert bestehen: Ein noch vorhandener Altwert auf einem Produkt hat weiterhin Vorrang vor der zentral konfigurierten automatischen Gruppenerkennung, ist aber ab jetzt wieder ohne eigenes Admin-Feld unsichtbar. Bei einem erneuten, ähnlich gelagerten Fall kann das Feld bei Bedarf wieder vorübergehend freigeschaltet werden.

2.0.19

• Entfernt die in 2.0.17 nur zu Diagnosezwecken eingeführten data-csa-debug-*-Attribute sowie die zugehörigen internen Debug-Felder wieder, nachdem die eigentliche Ursache (siehe 2.0.18) bestätigt behoben wurde. Rein diagnostisch, keine Funktionsänderung.

2.0.18

• Behebt die eigentliche Ursache, warum „Name der dynamischen Produktgruppe als Zubehör-Überschrift verwenden“ (und die zentrale automatische Gruppenerkennung allgemein) bei einzelnen Produkten nicht griff: Ein aus der App-Migration stammender alter Freitext-Wert (response_csa_legacy_compatibility_group) hat bisher ohne jede Sichtbarkeit im Admin die zentral konfigurierten dynamischen Produktgruppen für dieses Produkt stillschweigend überstimmt.
• Dieses interne Feld wird jetzt zusätzlich als normales, sichtbares Textfeld „Interner Altwert (frühere Freitext-Kompatibilitätsgruppe)“ im Zusatzfelder-Bereich des Produkts registriert. Enthält es einen Wert, können Shop-Betreiber ihn dort direkt leeren und speichern, um wieder die automatische zentrale Erkennung zu verwenden – ganz ohne Datenbankzugriff.
• Ergänzt das entsprechende Feld auch in der deklarativen Resources/config/custom-fields.xml für Shopwares Lifecycle-Synchronisierung ab 6.7.13.

2.0.17 (temporäre Diagnose)

• Fügt am Zubehör-Container ausschließlich zu Diagnosezwecken fünf data-*-Attribute hinzu (data-csa-debug-source, data-csa-debug-stream-ids, data-csa-debug-headline-raw, data-csa-debug-use-stream-headline, data-csa-debug-stream-headline-name), sichtbar nur im HTML-Quelltext bzw. den Entwicklertools. Sie zeigen, welche Quelle (Cross-Selling vs. dynamische Produktgruppe) tatsächlich verwendet wurde und warum die Gruppenname-Überschrift ggf. nicht greift.
• Rein diagnostisch, keine funktionale Änderung. Wird nach Abschluss der Fehlersuche zum „Name der dynamischen Produktgruppe als Überschrift verwenden“-Problem wieder entfernt.

2.0.16

• Behebt, dass Änderungen an der Plugin-Konfiguration (u. a. „Name der dynamischen Produktgruppe als Zubehör-Überschrift verwenden“, aber auch Überschrift, Sichtbarkeits- und Anzeigeoptionen) auf bereits HTTP-gecachten Produktseiten nicht ankamen. Seit Shopware 6.7.12 invalidieren Systemkonfigurations-Änderungen den HTTP-Cache nur noch für Felder, die in config.xml explizit mit cache-relevant="true" markiert sind. Alle Zubehör-Anzeigeoptionen dieses Plugins sind jetzt entsprechend markiert (ausgenommen autoAddMainProduct, das rein beim Warenkorb-Hinzufügen ausgewertet wird und keine gecachte Ausgabe beeinflusst).
• Aus diesem Grund wird die Mindestversion auf Shopware 6.7.12 angehoben (siehe „Kompatibilität“) – auf älteren 6.7.x-Ständen wäre cache-relevant in config.xml kein gültiges Schema-Attribut gewesen.
• Ersetzt die veraltete EntitySearchResult::first()-Abfrage beim Auflösen des Namens einer dynamischen Produktgruppe durch getEntities()->first().
• Falls die neue Überschrift nach dem Update weiterhin nicht erscheint, bitte einmalig den Shopware-Cache leeren – anschließend werden künftige Änderungen an den oben genannten Einstellungen automatisch berücksichtigt.

2.0.15

• Das für die Zubehör-Anzeige im Buy-Widget konsumierte Shopware-Cross-Selling (produktspezifisch ausgewählt oder global/Standard) wird nicht mehr zusätzlich im nativen „Cross Selling“-Tab der Produktdetailseite angezeigt. Gibt es mehrere aktive Cross-Sellings am Produkt, bleiben die übrigen dort unverändert sichtbar.
• Stammt das oben angezeigte Zubehör hingegen aus einer dynamischen Produktgruppe (automatischer Fallback), bleibt der „Cross Selling“-Tab vollständig unangetastet, da dieser Fallback nichts mit den am Produkt hinterlegten Cross-Sellings zu tun hat.
• Technisch wird dazu das seit Shopware 6.7 als CMS-Element (cross-selling) auf der Produktdetailseite aufgelöste Cross-Selling direkt nach dem Laden der Seite gefiltert; es ist keine Twig-Template-Anpassung des Cross-Selling-Tabs nötig.

2.0.14

• Jede Zubehörkarte erhält einen eigenen Mengensteller (−/+ sowie Direkteingabe), begrenzt durch die Mindest-/Höchstbestellmenge und Bestellmengen-Intervalle des jeweiligen Artikels bzw. der gewählten Variante.
• Die gewählte Menge wird sowohl beim einzelnen „In den Warenkorb“ als auch bei der Mehrfachauswahl (gesammelter Warenkorb) korrekt als Positionsmenge übernommen.
• Beim automatischen Mitbestellen des Hauptprodukts wird nun dessen tatsächlich auf der Produktdetailseite ausgewählte Menge verwendet, statt stets die Mindestbestellmenge des Hauptprodukts anzusetzen. Ändert der Kunde die Hauptmenge, wird dies laufend in die Zubehör-Formulare übernommen.
• Bei Varianten-Zubehör bleibt eine bereits eingegebene Menge beim Wechsel der Variante erhalten, sofern sie zu deren Mindest-/Höchstbestellmenge und Bestellintervall passt; andernfalls wird sie automatisch angepasst.

2.0.2

• Behebt die Erstinstallation: Lifecycle-Code greift nicht mehr auf plugin-eigene Services zu, bevor Shopware den Container mit dem aktivierten Plugin neu aufgebaut hat.
• Custom Fields werden bei Installation/Update direkt über die verfügbaren Shopware-Repositories verwaltet; ab Shopware 6.7.13 ist zusätzlich die deklarative Resources/config/custom-fields.xml enthalten, damit Shopwares Lifecycle-Synchronisierung dieselben Felder übernimmt und bei Updates nicht entfernt.
• Die Migration der App-Konfiguration verwendet ebenfalls das Core-Repository und überschreibt bei der Erstinstallation nur die zuvor von Shopware angelegten Plugin-Defaultwerte.

2.0.3

• Behebt den Shopware-DAL-Fehler beim direkten Laden der Produkt-parent-Association in der Cache-Invalidierung.
• Elternprodukte werden nun in einem separaten, gebündelten Repository-Aufruf über parentId geladen.
• Varianten-IDs werden separat ermittelt und anschließend gesammelt über den Sales-Channel geladen; kein HTML-Scraping und keine Einzel-PDP-Requests.
• Varianten und Fallback-Produkte verwenden VISIBILITY_LINK, entsprechend Shopwares Produktdetail-/Cross-Selling-Logik.

2.0.4

• Entfernt das Warenkorb-Symbol vollständig aus den Zubehör-Buttons.
• Entfernt die dadurch nicht mehr benötigten .csa__cart-icon-/Icon-Styles.

2.0.5

• Variantenverfügbarkeit wird nun über Shopwares nativen AvailableCombinationLoader ermittelt, den auch der Core-Konfigurator verwendet.
• Entfernt den zusätzlichen ProductAvailableFilter aus dem Varianten-Endpunkt, damit geerbte Variantensichtbarkeiten nicht doppelt bzw. widersprüchlich gefiltert werden.
• Varianten werden weiterhin in einem einzigen gebündelten Sales-Channel-Ladevorgang geladen; es gibt weiterhin kein PDP-Scraping und keinen Varianten-HTTP-Walk.
• Bei inkompatiblen Drittanbieter-Stock-Loadern fällt der Endpunkt kontrolliert auf die Sales-Channel-Produktflags zurück, statt mit HTTP 500 abzubrechen.
• Leere Variantenantworten werden im Browser nicht mehr gecacht und geben in der Entwicklerkonsole einen technischen Reason-Code aus.
• Der Varianten-Endpunkt verwendet einen neuen /response-accessories/v2/...-Pfad, damit eventuell vorhandene HTTP-Cache-Antworten älterer Plugin-Versionen sicher umgangen werden.
• Für die Kaufbarkeit wird Shopwares stock-aware available-Flag verwendet; availableStock wird nicht mehr zusätzlich als widersprüchlicher Legacy-Filter herangezogen.

2.0.8

• Korrigiert crossSellingAccessories.freeShipping auf exakt „versandkostenfrei“ bzw. „free shipping“ ohne führendes Komma.
• Trennt Steuer- und Versandhinweise im Twig strukturell durch einen geschützten Abstand, damit die Textbausteine selbst keine Satzzeichen oder Leerzeichen als Layout-Hack enthalten müssen.
• Stellt deutsche Benutzerhinweise und Zusatzfeld-Hilfetexte konsequent auf die formelle Sie-Ansprache um.

2.0.7

• Registriert den Storefront-Variantencontroller vollständig als Symfony/Shopware-Controller-Service.
• Setzt den für StorefrontController erforderlichen Service-Container explizit über setContainer, zusätzlich zum controller.service_arguments-Tag.
• Behebt damit HTTP 500 beim Varianten-Endpunkt mit "has no container set".

Warenkorb-Zuordnung (2.0.7)

• Zubehörpositionen werden im Shopware-Warenkorb über Line-Item-Payload dem Produkt zugeordnet, von dessen Detailseite sie hinzugefügt wurden.
• Im Warenkorb und Offcanvas-Warenkorb erscheint bei solchen Positionen „Zubehör zu: …“ bzw. „Accessory for: …“.
• Optional (standardmäßig aktiviert) wird das aktuelle Hauptprodukt beim ersten Zubehör-Hinzufügen automatisch mit in den Warenkorb gelegt, sofern es dort noch nicht als Produktposition vorhanden ist. Weitere Zubehör-Klicks erhöhen die Menge des Hauptprodukts nicht.

2.0.9

• Gruppiert Zubehörpositionen im Offcanvas-Warenkorb und auf der Warenkorbseite unmittelbar unter dem zugehörigen Hauptprodukt.
• Die Reihenfolge wird aus der bereits gespeicherten Line-Item-Zuordnung (responseCsaMainProductId) erzeugt; es sind dafür keine zusätzlichen Produkt- oder Datenbankabfragen nötig.
• Zubehörpositionen werden zusätzlich leicht eingerückt und mit einer linken Trennlinie dargestellt, damit die Zugehörigkeit auch visuell sofort erkennbar ist.
• Verwaiste Zubehörpositionen bleiben in ihrer ursprünglichen Position sichtbar, falls das Hauptprodukt nicht im Warenkorb vorhanden ist.

2.0.10

• Stellt csa_compatibility_group auf eine Auswahl von Shopwares dynamischen Produktgruppen (product_stream) um.
• Der Fallback wertet die Filterdefinition der ausgewählten dynamischen Produktgruppe serverseitig mit Shopwares ProductStreamBuilder aus.
• Das aktuell geöffnete Produkt und seine Variantenfamilie werden immer aus der Zubehörliste ausgeschlossen. Dadurch entsteht bei derselben Gruppenauswahl auf A, B und C automatisch A → B+C, B → A+C und C → A+B.
• Bestehende freie Textwerte bleiben als Legacy-Fallback lauffähig und müssen nicht sofort migriert werden.
• Änderungen an dynamischen Produktgruppen bzw. deren Filtern invalidieren den RESPONSE-Fallback-Cache.

2.0.12

• Abverkaufsartikel (isCloseout) werden konsequent aus RESPONSE-Zubehör und Variantenlisten ausgeschlossen, unabhängig vom Restbestand.
• Zusätzliche serverseitige Absicherung verhindert, dass veraltete oder manipulierte RESPONSE-Warenkorb-Requests einen Abverkaufsartikel hinzufügen.
• Produktbild und Produktname öffnen standardmäßig Shopwares native Quick View (widgets.quickview.minimal).
• In der RESPONSE-Quick-View führt ein eindeutiger Button „Zum Produkt“ auf die Produktdetailseite.
• Quick View kann in der Plugin-Konfiguration deaktiviert werden und ist standardmäßig aktiviert.

2.0.11

• Behebt die endlos ladende Auswahl der dynamischen Produktgruppe nach einem Update von älteren Versionen: alte Freitextwerte werden intern gesichert und aus csa_compatibility_group entfernt, bevor das Feld auf einen echten product_stream-Entity-Select umgestellt wird.
• csa_compatibility_group wird bei bestehenden Installationen jetzt ebenfalls explizit auf Shopwares zugrunde liegenden Custom-Field-Typ select migriert.
• Neue optionale Einstellung „Name der dynamischen Produktgruppe als Zubehör-Überschrift verwenden“. Ist sie aktiv und das Zubehör stammt aus dem Product-Stream-Fallback, wird der übersetzte Name der ausgewählten dynamischen Produktgruppe als Überschrift verwendet.
• Normales Cross-Selling behält weiterhin die konfigurierte bzw. lokalisierte Standard-Überschrift.

2.0.13

• Führt eine zentrale Mehrfachauswahl für Shopwares dynamische Produktgruppen in der Plugin-Konfiguration ein.
• Echtes bidirektionales Verhalten ohne Pflege am einzelnen Produkt: RESPONSE erkennt automatisch, ob die aktuell geöffnete Produktfamilie Mitglied einer ausgewählten Gruppe ist.
• Gehört ein Produkt zu mehreren ausgewählten Gruppen, werden deren Zubehörartikel zusammengeführt und nach Produktfamilie dedupliziert.
• csa_compatibility_group bleibt nur noch als optionaler produktspezifischer Override und zur Rückwärtskompatibilität bestehen.
• Ein explizit am Produkt gewähltes Shopware-Cross-Selling behält immer höchste Priorität; die bestehende Ersetzungsoption steuert, ob automatische Gruppen vor oder nach globalem/Standard-Cross-Selling verwendet werden.
• Der Name der dynamischen Produktgruppe wird als Überschrift nur verwendet, wenn genau eine Gruppe passt. Bei mehreren Treffern bleibt die konfigurierte/Standard-Überschrift erhalten.
• Stream-Mapping-Änderungen invalidieren den automatischen RESPONSE-Fallback-Cache, damit neue bzw. entfernte Gruppenmitglieder auch bei aktivem HTTP-Cache korrekt erscheinen.

Shopware-6.7-Plugin für kaufbare Zubehörkarten auf der Produktdetailseite.

Architektur 2.0

Version 2.0 ersetzt die frühere App-Architektur mit clientseitigem HTML-Scraping durch serverseitige Shopware-Daten:

• Cross-Selling-Auswahl und der Fallback über eine dynamische Produktgruppe werden beim Laden der Produktdetailseite serverseitig über Shopware Sales-Channel-Routen aufgelöst.
• Es gibt keinen Browser-Request mehr an /store-api/product für den Fallback.
• Es gibt keinen rekursiven Varianten-Graph-Walk, keinen DOMParser und keine vollständigen Produktdetailseiten-Requests zur Preis-/Variantenbestimmung.
• Der initiale „ab/from“-Preis wird serverseitig abgesichert: Das Plugin validiert Shopwares indexierte günstigste Variante in einer gebündelten Sales-Channel-Abfrage. Nur wenn dieser Treffer nicht mehr kaufbar ist, erfolgt eine kleine strukturierte Ersatzsuche für genau diese Variantenfamilie.
• Erst beim Klick auf „Variante wählen“ wird genau ein eigener, HTTP-cachebarer JSON-Endpunkt aufgerufen. Dieser lädt die kaufbaren Varianten strukturiert über die Sales-Channel-Produkt-Route.
• Pro Variantenfamilie werden maximal 500 kaufbare Varianten an den Browser übertragen. Bei größeren Matrizen wird bewusst auf die normale Produktdetailseite verwiesen, statt den Origin mit einem riesigen Variantenlauf zu belasten.
• Wiederholtes Öffnen derselben Variantenfamilie innerhalb einer Seitenansicht verwendet einen In-Memory-Cache im Browser.

Auswahl-Priorität

1. ausdrücklich am Produkt gewähltes Cross-Selling (response_csa_cross_selling_selection)
2. bei aktivierter Ersetzungsoption: automatisch passende, zentral konfigurierte dynamische Produktgruppe(n)
3. global konfigurierter Cross-Selling-Name bzw. erstes aktives Cross-Selling
4. ohne Ersetzungsoption: automatisch passende, zentral konfigurierte dynamische Produktgruppe(n) als Fallback

Die dynamischen Produktgruppen werden zentral in der Plugin-Konfiguration ausgewählt. RESPONSE prüft auf der Produktdetailseite automatisch, ob die aktuell geöffnete Produktfamilie Mitglied einer oder mehrerer dieser Gruppen ist. Eine Pflege von csa_compatibility_group an jedem einzelnen Produkt ist dafür nicht mehr erforderlich. Treffen mehrere ausgewählte Gruppen zu, werden deren Ergebnisse zusammengeführt und nach Produktfamilie dedupliziert.

csa_compatibility_group bleibt als optionaler produktspezifischer Override für Sonderfälle und zur Rückwärtskompatibilität bestehen. Ist dort eine Gruppe ausgewählt, wird diese für das konkrete Produkt vor der zentralen automatischen Erkennung verwendet.

Zusatzfelder

Das Plugin legt bzw. übernimmt das Set response_csa_product_settings mit diesen Produkt-Zusatzfeldern:

• response_csa_cross_selling_selection
• csa_compatibility_group – optionale produktspezifische Shopware-Dynamische-Produktgruppe (product_stream) für Sonderfälle

Für den normalen bidirektionalen Betrieb ist keine Produktpflege mehr erforderlich. Wählen Sie die gewünschten dynamischen Produktgruppen einmal zentral in der Plugin-Konfiguration aus. Enthält eine ausgewählte Gruppe A, B und C, erkennt RESPONSE die Mitgliedschaft automatisch: A zeigt B+C, B zeigt A+C und C zeigt A+B. Das aktuell geöffnete Produkt und seine gesamte Variantenfamilie werden aus den Treffern ausgeschlossen.

Beim Wechsel von der bisherigen App übernimmt das Plugin das vorhandene Set und entfernt die App-Zuordnung (appId), damit die bestehenden Produktwerte erhalten bleiben und das Set nach der Migration vom Plugin verwaltet wird. Ältere freie Textwerte aus csa_compatibility_group werden beim Update intern unter response_csa_legacy_compatibility_group gesichert und aus dem sichtbaren Entity-Auswahlfeld entfernt. Dadurch kann Shopwares Produktgruppen-Auswahl ohne ungültige Legacy-ID laden; die alte Freitext-Fallbacklogik bleibt im Hintergrund weiterhin funktionsfähig.

Migration von der App 1.4.x

Empfohlene Reihenfolge:

1. Bestehende App deaktivieren, noch nicht deinstallieren.
2. Plugin ResponseCrossSellingAccessoriesPlugin installieren und aktivieren.
3. Storefront/Theme kompilieren und Funktion prüfen.
4. Erst danach die alte App deinstallieren.

Beim Installieren/Update kopiert das Plugin die unterstützten Einstellungen aus ResponseCrossSellingAccessories.config.* nach ResponseCrossSellingAccessoriesPlugin.config.*, sofern am Ziel noch kein Wert vorhanden ist. Die alten App-Einstellungen storeApiAccessKey und previewConcurrency werden bewusst nicht übernommen, weil sie in der Plugin-Architektur nicht mehr benötigt werden.

Kompatibilität

• PHP >= 8.2
• Shopware >= 6.7.2 und < 6.8

Die Mindestversion 6.7.2 wird verwendet, weil das Plugin Shopwares CacheTagCollector::addTag() für korrekte HTTP-Cache-Invalidierung nutzt.

Installation

ZIP in Shopware unter Erweiterungen → Meine Erweiterungen hochladen, installieren und aktivieren. Anschließend das Theme/Storefront neu kompilieren, falls Shopware dies nicht automatisch ausführt.

2.0.2

• Behebt die Erstinstallation: Lifecycle-Code greift nicht mehr auf plugin-eigene Services zu, bevor Shopware den Container mit dem aktivierten Plugin neu aufgebaut hat.
• Custom Fields werden bei Installation/Update direkt über die verfügbaren Shopware-Repositories verwaltet; ab Shopware 6.7.13 ist zusätzlich die deklarative Resources/config/custom-fields.xml enthalten, damit Shopwares Lifecycle-Synchronisierung dieselben Felder übernimmt und bei Updates nicht entfernt.
• Die Migration der App-Konfiguration verwendet ebenfalls das Core-Repository und überschreibt bei der Erstinstallation nur die zuvor von Shopware angelegten Plugin-Defaultwerte.

2.0.3

• Behebt den Shopware-DAL-Fehler beim direkten Laden der Produkt-parent-Association in der Cache-Invalidierung.
• Elternprodukte werden nun in einem separaten, gebündelten Repository-Aufruf über parentId geladen.
• Varianten-IDs werden separat ermittelt und anschließend gesammelt über den Sales-Channel geladen; kein HTML-Scraping und keine Einzel-PDP-Requests.
• Varianten und Fallback-Produkte verwenden VISIBILITY_LINK, entsprechend Shopwares Produktdetail-/Cross-Selling-Logik.

2.0.4

• Entfernt das Warenkorb-Symbol vollständig aus den Zubehör-Buttons.
• Entfernt die dadurch nicht mehr benötigten .csa__cart-icon-/Icon-Styles.

2.0.5

• Variantenverfügbarkeit wird nun über Shopwares nativen AvailableCombinationLoader ermittelt, den auch der Core-Konfigurator verwendet.
• Entfernt den zusätzlichen ProductAvailableFilter aus dem Varianten-Endpunkt, damit geerbte Variantensichtbarkeiten nicht doppelt bzw. widersprüchlich gefiltert werden.
• Varianten werden weiterhin in einem einzigen gebündelten Sales-Channel-Ladevorgang geladen; es gibt weiterhin kein PDP-Scraping und keinen Varianten-HTTP-Walk.
• Bei inkompatiblen Drittanbieter-Stock-Loadern fällt der Endpunkt kontrolliert auf die Sales-Channel-Produktflags zurück, statt mit HTTP 500 abzubrechen.
• Leere Variantenantworten werden im Browser nicht mehr gecacht und geben in der Entwicklerkonsole einen technischen Reason-Code aus.
• Der Varianten-Endpunkt verwendet einen neuen /response-accessories/v2/...-Pfad, damit eventuell vorhandene HTTP-Cache-Antworten älterer Plugin-Versionen sicher umgangen werden.
• Für die Kaufbarkeit wird Shopwares stock-aware available-Flag verwendet; availableStock wird nicht mehr zusätzlich als widersprüchlicher Legacy-Filter herangezogen.

2.0.8

• Korrigiert crossSellingAccessories.freeShipping auf exakt „versandkostenfrei“ bzw. „free shipping“ ohne führendes Komma.
• Trennt Steuer- und Versandhinweise im Twig strukturell durch einen geschützten Abstand, damit die Textbausteine selbst keine Satzzeichen oder Leerzeichen als Layout-Hack enthalten müssen.
• Stellt deutsche Benutzerhinweise und Zusatzfeld-Hilfetexte konsequent auf die formelle Sie-Ansprache um.

2.0.7

• Registriert den Storefront-Variantencontroller vollständig als Symfony/Shopware-Controller-Service.
• Setzt den für StorefrontController erforderlichen Service-Container explizit über setContainer, zusätzlich zum controller.service_arguments-Tag.
• Behebt damit HTTP 500 beim Varianten-Endpunkt mit has no container set.

Warenkorb-Zuordnung (2.0.7)

• Zubehörpositionen werden im Shopware-Warenkorb über Line-Item-Payload dem Produkt zugeordnet, von dessen Detailseite sie hinzugefügt wurden.
• Im Warenkorb und Offcanvas-Warenkorb erscheint bei solchen Positionen „Zubehör zu: …“ bzw. „Accessory for: …“.
• Optional (standardmäßig aktiviert) wird das aktuelle Hauptprodukt beim ersten Zubehör-Hinzufügen automatisch mit in den Warenkorb gelegt, sofern es dort noch nicht als Produktposition vorhanden ist. Weitere Zubehör-Klicks erhöhen die Menge des Hauptprodukts nicht.

2.0.9

• Gruppiert Zubehörpositionen im Offcanvas-Warenkorb und auf der Warenkorbseite unmittelbar unter dem zugehörigen Hauptprodukt.
• Die Reihenfolge wird aus der bereits gespeicherten Line-Item-Zuordnung (responseCsaMainProductId) erzeugt; es sind dafür keine zusätzlichen Produkt- oder Datenbankabfragen nötig.
• Zubehörpositionen werden zusätzlich leicht eingerückt und mit einer linken Trennlinie dargestellt, damit die Zugehörigkeit auch visuell sofort erkennbar ist.
• Verwaiste Zubehörpositionen bleiben in ihrer ursprünglichen Position sichtbar, falls das Hauptprodukt nicht im Warenkorb vorhanden ist.

2.0.10

• Stellt csa_compatibility_group auf eine Auswahl von Shopwares dynamischen Produktgruppen (product_stream) um.
• Der Fallback wertet die Filterdefinition der ausgewählten dynamischen Produktgruppe serverseitig mit Shopwares ProductStreamBuilder aus.
• Das aktuell geöffnete Produkt und seine Variantenfamilie werden immer aus der Zubehörliste ausgeschlossen. Dadurch entsteht bei derselben Gruppenauswahl auf A, B und C automatisch A → B+C, B → A+C und C → A+B.
• Bestehende freie Textwerte bleiben als Legacy-Fallback lauffähig und müssen nicht sofort migriert werden.
• Änderungen an dynamischen Produktgruppen bzw. deren Filtern invalidieren den RESPONSE-Fallback-Cache.

2.0.12

• Abverkaufsartikel (isCloseout) werden konsequent aus RESPONSE-Zubehör und Variantenlisten ausgeschlossen, unabhängig vom Restbestand.
• Zusätzliche serverseitige Absicherung verhindert, dass veraltete oder manipulierte RESPONSE-Warenkorb-Requests einen Abverkaufsartikel hinzufügen.
• Produktbild und Produktname öffnen standardmäßig Shopwares native Quick View (widgets.quickview.minimal).
• In der RESPONSE-Quick-View führt ein eindeutiger Button „Zum Produkt“ auf die Produktdetailseite.
• Quick View kann in der Plugin-Konfiguration deaktiviert werden und ist standardmäßig aktiviert.

2.0.11

• Behebt die endlos ladende Auswahl der dynamischen Produktgruppe nach einem Update von älteren Versionen: alte Freitextwerte werden intern gesichert und aus csa_compatibility_group entfernt, bevor das Feld auf einen echten product_stream-Entity-Select umgestellt wird.
• csa_compatibility_group wird bei bestehenden Installationen jetzt ebenfalls explizit auf Shopwares zugrunde liegenden Custom-Field-Typ select migriert.
• Neue optionale Einstellung „Name der dynamischen Produktgruppe als Zubehör-Überschrift verwenden“. Ist sie aktiv und das Zubehör stammt aus dem Product-Stream-Fallback, wird der übersetzte Name der ausgewählten dynamischen Produktgruppe als Überschrift verwendet.
• Normales Cross-Selling behält weiterhin die konfigurierte bzw. lokalisierte Standard-Überschrift.

2.0.13

• Führt eine zentrale Mehrfachauswahl für Shopwares dynamische Produktgruppen in der Plugin-Konfiguration ein.
• Echtes bidirektionales Verhalten ohne Pflege am einzelnen Produkt: RESPONSE erkennt automatisch, ob die aktuell geöffnete Produktfamilie Mitglied einer ausgewählten Gruppe ist.
• Gehört ein Produkt zu mehreren ausgewählten Gruppen, werden deren Zubehörartikel zusammengeführt und nach Produktfamilie dedupliziert.
• csa_compatibility_group bleibt nur noch als optionaler produktspezifischer Override und zur Rückwärtskompatibilität bestehen.
• Ein explizit am Produkt gewähltes Shopware-Cross-Selling behält immer höchste Priorität; die bestehende Ersetzungsoption steuert, ob automatische Gruppen vor oder nach globalem/Standard-Cross-Selling verwendet werden.
• Der Name der dynamischen Produktgruppe wird als Überschrift nur verwendet, wenn genau eine Gruppe passt. Bei mehreren Treffern bleibt die konfigurierte/ Standard-Überschrift erhalten.
• Stream-Mapping-Änderungen invalidieren den automatischen RESPONSE-Fallback-Cache, damit neue bzw. entfernte Gruppenmitglieder auch bei aktivem HTTP-Cache korrekt erscheinen.