Im Storefront wird der falsche Hauptartikel (Variante) angezeigt

Hallo zusammen,

bei einer SW6 (6.2.3) Storefront-Darstellung gibt es Probleme.

Wenn über die Produkteigenschaften im Katalog gefiltert wird, wird die falsche Variante im Storefront angezeigt. Heißt: geht man über das Hauptlisting unter “Produktkategorie” auf den Katalog, sind alle Produkte korrekt angezeigt. Wählt man jetzt eine spezifische Produkteigenschaft aus, wird automatisch die andere (größere und teurere) Variante angezeigt. Unabhängig davon welche Artikel-ID der Produktvariante als Hauptartikel gesetzt wird.

Ein Fehler wird nicht ausgegeben. Wie gesagt: der Fehler taucht erst auf, wenn man Produkteigenschaften zur Filterung auswählt.

Kennt jemand das Problem oder weiß wonach man suchen muss? 

VG

Hallo,
Wir sind unter Version 6.4.6.1 auch eben über das selbe Problem gestolpert. Im normalen Listing wird die Hauptvariante ausgegeben aber sobald ein Filter für mehrere Varianten greift, wird die teurste als Hauptvariante im Listing angegeben. Nach Test mit dem Preis-Filter kann ich aber ganz sicher sagen, dass der Filter auch die Hauptvariante enthalten würde. Hat dazu schon jemand eine Lösung gefunden?

Hallo!

Habt ihr das Problem mittlerweile lösen können?
Bei uns ( 6.4.18.1 ) tritt der Fehler immer noch auf sowie 2 Filter gesetzt sind.

Gruß,
Schmidt

Hallo zusammen,

ich hatte dazu letztes Jahr ein Ticket angelegt Shopware Issuetracker und jetzt kam die Antwort von Shopware, dass sie es auf absehbare Zeit nicht umsetzen (obwohl mir vor wenigen Monaten noch gesagt wurde, dass daran gearbeitet wird und es in einem der nächsten Updates kommt…).

Jedenfalls habe ich jetzt eine eigene Lösung implementiert, das bei einer „überschaubaren“ Menge an Varianten (also … keine Ahnung… weniger als 100 pro Artikel) funktionieren sollte, wenn ich nichts übersehe…

Das Ganze lässt sich über die \Shopware\Core\Content\Product\SalesChannel\Listing\ProductListingLoader::load steuern (dekorieren über ein eigenes Plugin).

Da werden erstmal alle Produkte für die ausgewählte Seite im Listing ausgelesen ($ids = $this->repository->searchIds($criteria, $context)).

Diese sind gruppiert nach der displayGroup, sprich je Artikel wird random genau eine Variante ausgelesen.

Erster Schritt der Lösung ist es jetzt, sich anhand dieser Liste alle anderen zugehörigen Varianten-IDs zu holen (EqualsAnyFilter auf die displayGroups der ausgelesenen Produkte). Dafür sollte das bereits bestehende criteria-Objekt verwendet werden, sodass potentiell eingestellte Filter greifen, und das Limit (das ursprünglich für die Paginierung genutzt wird) entfernt werden.

Dadurch hat man eine Liste aller Varianten der ausgewählten Kategorieseite, die auf die Filter zutreffen (limitiert in der Anzahl durch die ursprünglich ausgelesenen Produkt-IDs). Trifft eine Filterkombination nicht auf eine Hauptvariante zu, ist die Hauptvarianten-ID hier auch nicht enthalten.

Etwas später in der Methode führt Shopware die resolvePreviews-Methode aus, allerdings nur, wenn keine Filter gesetzt sind. Diese Methode ordnet jeder Varianten-ID ihre Main-Variant-ID zu. Die if-Bedingung um die Methode sollte entfernt werden, sodass sie immer ausgeführt sind, die Resultate allerdings nicht in $variantIds und $mapping speichern, sondern in anderen temporären Variablen.

Der Clou ist es jetzt einfach zu prüfen, ob die Main-Variant-IDs, die die resolve-Methode zurückliefert, Teil der zuvor ausgelesenen Varianten-IDs sind. Falls ja wird die Main-Variant-ID zurückgeliefert, falls nicht die random von Shopware ausgewählte ID.

Übersehe ich irgendwas?

Zumindest als einstellbare Option hätte Shopware das ja einbauen können. Dann hätte jeder anhand seines Produktkatalogs und Serverressourcen entscheiden können, ob er es nutzen möchte oder nicht.

Viele Grüße,
Malte