Artikelvarianten als eigenständige Artikel in Kategorieübersicht

Hallo,

kennt jemand ein Lösung wie Artikelvarianten in der Artikelübersicht (Kategorie-Listing) als eigenständige Artikel ausgegeben werden können?

Ich meine nicht einen Variantenwechsel mit Javascript wie im Tutorial “Artikellisting mit Variantenwechsel” beschrieben (diese Lösung wird auch von einigen Kauf-Plugins angeboten).

Bei unseren Artikeln handelt es sich um Jacken, die eine Farb-/Größen-Variantenkombination haben. Die Farbvarianten sollen als eigene Artikel in der Artikelübersicht ausgegeben werden. Diese Darstellung ist im Fashionbereich inzwischen eigentlich Standard (zumindest bei großen Shops).  

Wir nutzen SW 5.1.1.

Grüße,

Nikolas

Beispiel-Bilder:
1 Varianten in Artikelübersicht
2 Produktseiten der Varianten

Ja und warum legst du dann nicht einfach Artikel an???

Hallo,

so machen wir es bisher auch. Varianten als Varianten anzulegen hat für uns aber mehrere Vorteile:

Der wichtigste Grund ist sicherlich die Vermeidung von Duplicate Content. Außerdem finden wir die grafische Darstellung (Bilder) aller Varianten auf der Produktseite (bei Variantenauswahl) sehr wichtig. Auch Kunden-Bewertungen pro Produkt (nicht pro Farbe) wären - zumindest in unserem Bereich - zielführender.

Hat jemand eine Idee?

Gruß,

Nikolas

Ahh, OK.

Naja ohne Plug-In wird das wohl nichts.

Grundsätzliches Vorgehen wäre im Listing die Varianten auszulesen (falls die Information dort nicht vorhanden ist eben anreichern).

In frontend/listing/index gibt es dann

{block name="frontend_listing_list_inline"}
                            {foreach $sArticles as $sArticle}
                                {include file="frontend/listing/box_article.tpl"}
                            {/foreach}
                        {/block}

und da müsste man dann im foreach article vorher kucken ob da varianten drin sind und wenn ja (in deinem Fall) z.B. definieren, dass falls es mehrere varianten mit variantenName ‘Farbe’ gibt er für jeden einen box_article generieren soll.

Geschickter ist es evtl. schon vorher, an dem Punkt an dem dem Frontend das sArticles-Array übergeben wird, dieses zu modifizieren und für jede Farb-Variante einen eigenen Artikel daraus für die Listing-Darstellung zu faken. Fraglich ist in wie weit das geht bei mehrdimensionalen Varianten zwecks id. Unter Umständen braucht man ne Zwischen-Tabelle mit eigenen Id’s so dass man die Farbvarianten der Hauptvariante wieder zuordnen kann.

1 Like

Danke für deine Ideen!

In frontend/listing/index gibt es dann

{block name=“frontend_listing_list_inline”}
{foreach $sArticles as $sArticle}
{include file=“frontend/listing/box_article.tpl”}
{/foreach}
{/block}

und da müsste man dann im foreach article vorher kucken ob da varianten drin sind und wenn ja (in deinem Fall) z.B. definieren, dass falls es mehrere varianten mit variantenName ‘Farbe’ gibt er für jeden einen box_article generieren soll.

Den Ansatz hatte ich auch schon verfolgt, bin aber nicht weiter gekommen. Das Array $sArticles beinhaltet - wenn ich richtig gesehen habe - keine Varianten-Informationen.

Ich dachte, wahrscheinlich müsste man $sArticles vorher “aufbohren”, indem man die mySQL Artikeldaten-Abfrage durch eine Varianten-Abfrage ergänzt. Ich habe aber keine Ahnung wie bzw. wo man das machen könnte, noch kann ich überblicken, ob $sArticles irgendwo anders Verwendung findet und der Eingriff ungewollte Ergebenisse in anderen Bereichen verursacht.

Geschickter ist es evtl. schon vorher, an dem Punkt an dem dem Frontend das sArticles-Array übergeben wird, dieses zu modifizieren und für jede Farb-Variante einen eigenen Artikel daraus für die Listing-Darstellung zu faken.

Mit “modifizieren” meinst Du eine zweite mySQL-Abfrage für die Variantendaten? Wie müsste die aussehen?

Gruß,

Nikolas

Hi,

generell kann man natürlich zusätzliche Queries ausführen, wie ihr das diskutiert; falls ihr das direkt im “ursprünglichen” Query angehen wollt, hat Shopware zumindest an folgenden beiden Stellen das derzeitige Verhalten hinterlegt:

  • \Shopware\Bundle\SearchBundleDBAL\QueryBuilderFactory::createProductQuery - hier muss das " $query->addGroupBy(‘product.id’);" durch " $query->addGroupBy(‘variant.id’);" ersetzt werden

  • \Shopware\Bundle\SearchBundleDBAL\QueryBuilderFactory::createQuery - hier muss 

              ->innerJoin(
                  'product',
                  's_articles_details',
                  'variant',
                  'variant.id = product.main_detail_id
                   AND variant.active = 1
                   AND product.active = 1'
              )
    

gegen das hier ausgetauscht werden:
 

            ->innerJoin(
                'product',
                's_articles_details',
                'variant',
                'variant.articleID= product.id
                 AND variant.active = 1
                 AND product.active = 1'
            )

 

Also einmal die \Shopware\Bundle\SearchBundleDBAL\QueryBuilderFactory dekorieren und die beiden Methoden ersetzen *oder* mit “resetQueryParts” das Original-Query modifizieren. Ist jetzt sicher noch nicht alles, aber viel mir gerade ein, dass man da auch die Queries modifizieren kann.

Vom Prinzip her “kann” Shopware dann schon mehrere Varianten im Listing, zumindest habe ich schon unterschiedliche Cover-Bilder erhalten:

Für eine vollständige Umsetzung müsste man dann vermutlich noch den CheapestPrice-Service so umstellen, dass er nicht mehr den günstigsten Preis *aller* Varianten anzeigt, sondern den für die jeweils aktuelle Variante, keine Ahnung, was da noch so dran hängt.

 

Daniel 

1 Like

Das ist ein toller Ansatz, der sehr gut funktioniert. Kannst du vielleicht noch etwas genauer auf CheapestPriceService eingehen?

hallo Nikolas,

konntet ihr das wie gewünscht umsetzen?

Ich suche gerade nach der gleichen Lösung :) 

Hi zusammen,

das würde mich auch interessieren.

Viele Grüße

Stefan