Alle verfügbaren Varianten-Kombinationen als Tabelle unterhalb der Produktbeschreibung

Shopware 5 Programmierung
1

Ich hab mir für meinen Testshop ein Plugin geschrieben, das auf Basis der Artikel-ID des aufgerufenen Varianten-Artikels…

  • ordernumber, id, additionaltext, active, instock, laststock und releasedate aus der Tabelle s_articles_details
  • option_id aus der Tabelle s_article_configurator_option_relations
  • name und group_id aus der Tabelle s_article_configurator_options
  • name aus der Tabelle s_article_configurator_groups

abfragt und schleßlich mit $view->assign in frontend/detail als Array zur Verfügung stellt.

Mein Template /shop-url/custom/plugins/JoReuDetailVariantList/Resources/views/frontend/detail/tabs/description.tpl erweitert dann den Block frontend_detail_description_text , indem nach dem obligatorischen {$smarty.block.parent} abgeprüft wird, ob es sich um einen Varianten-Artikel handelt - und falls ja, dann erzeugt das Template mittels Daten aus dem Plugin-Array eine Tabelle , die sämtliche verfügbare Varianten-Kombinationen enthält.

Tabellen-Spalten: | AdditionalText | Bestellnummer | Varianten-Option1 | Varianten-Option2 | u.s.w. | Button zum Auswählen der Variante |

833×426 40.3 KB

Auf die Bestellnummer könnte wohlmöglich verzichtet werden, aber Hinweise wie AdditionalText und zum Beispiel auch das Verfügbarkeits-Datum sind an dieser Stelle doch nette Informationen.

Ebenso könnte man, unter Berücksichtigung der Kundengruppe, sicherlich noch die Preise der Varianten hinzufügen und statt der simplen Auswahl direkt auch den Warenkorb-Button einsetzen.

 

Die Fragen, die ich mir stelle:

  • a) Ist so eine Tabelle eine sinnvolle Ergänzung, unterhalb der Beschreibung - aber auch ganz grundsätzlich?
  • b) Lässt sich das auch ohne den Array aus dem Plugin, einzig durch das Template, lösen?
  • c) Welche Informationen müssen zwingend in so einer Tabellen-Zeile stehen, um zum Beispiel der PAngV gerecht zu werden, wenn ein Produkt hier direkt in den Warenkorb gelegt werden kann?
  • c.2) Macht es dann vielleicht auch Sinn ein Dropdown-Feld anzulegen für die Auswahl der Menge?
  • d) Gibt es vielleicht schon Plugins, die solche Tabellen generieren?

 

Ich würde mich sehr freuen, Meinungen aus der Praxis zu lesen.

 

Der Aufwand ist hier nicht besonders groß. Ein Plugin -Verzeichnis mit den Unterordnern bis zum Template und mit gerade mal 4 Dateien :

  • Plugin-PHP JoReuDetailVariantList
  • plugin.png
  • plugin.xml
  • Template-TPL description

Unter Enlight_Controller_Action_PostDispatch_Frontend_Detail => onFrontendDetail auch nur 1 createQueryBuilder.

Und das Template hat auch gerade mal 80 Zeilen Code.

2

Zu a: Die Idee ist cool. Kann mir gut vorstellen, das jemand so etwas gebrauchen kann. Warum auch nicht!?

Zu b und c kann ich leider nichts sagen.

Zu c2: Was spricht dagegen!?

Zu d: https://store.shopware.com/dreis3c1271daeda/varianten-als-tabelle-auf-der-detailseite.html & Varianten als Tabelle auf der Detailseite + Schnellkauf | Detailseite | Produktdarstellung | Storefront / Detailanpassungen | Erweiterungen | Shopware Community Store

3

@Murmeltier schrieb:

…

Zu d: https://store.shopware.com/dreis3c1271daeda/varianten-als-tabelle-auf-der-detailseite.html & https://store.shopware.com/imnxx28425192973/varianten-als-tabelle-auf-der-detailseite-schnellkauf.html

Danke für die Links… Und hier werden direkt schon wieder 100 bzw. 180 Euro aufgerufen.

4

Hallo,

der ausschlaggebendste Punkt ist ja wohl eher, falls diese Tabelle nicht per Ajax nachgeladen wird, dass diese Tabelle, speziell bei sehr vielen Varianten, sehr viel an Performance der Artikel - Detailseite kosten wird und die Artikel - Detailseite (wahrscheinlich enorm) verlangsamt - dies ist vielleicht bei super Servern nicht merklich spürbar, bei normalen Hostings aber auf jeden Fall.

Und wie es bei d.) schon steht, gibt es bereits Plugins für diesen Zweck, die vom Preis her eigentlich auch völlig in Ordnung sind, sogar mit sehr vielen Bewertungen als auch Downloads - ob es da eines weiteren Plugins für den gleichen Zweck Bedarf, muss jeder selbst entscheiden.

Grüße

Sebastian

5

@sschreier schrieb:

… falls diese Tabelle nicht per Ajax nachgeladen wird, dass diese Tabelle, speziell bei sehr vielen Varianten, sehr viel an Performance der Artikel - Detailseite kosten wird und die Artikel - Detailseite (wahrscheinlich enorm) verlangsamt…

Meinst Du, dass dieser Punkt auch bei einer gecachten Seite zum Tragen kommt?

6

@jor schrieb:

@sschreier schrieb:

… falls diese Tabelle nicht per Ajax nachgeladen wird, dass diese Tabelle, speziell bei sehr vielen Varianten, sehr viel an Performance der Artikel - Detailseite kosten wird und die Artikel - Detailseite (wahrscheinlich enorm) verlangsamt…

Meinst Du, dass dieser Punkt auch bei einer gecachten Seite zum Tragen kommt?

Hallo,

ja, wird der Punkt zu 100%, es gibt hier schon Unmengen Themen genau für solche Fälle, wo solche Tabellen (auch inklusive Auswahlfeldern) soviel weiteren HTML - Code generiert haben, das die Artikel - Detailseiten merklich langsamer werden, ansich egal, wie gut das Hosting ist und ob die Seite bereits gecacht ist oder nicht. Bei wenigen Varianten und einer geringen Menge, die man über das Auswahlfeld auswählen kann, ist dies vielleicht noch nicht merkbar, sobald aber immer mehr Varianten dazu kommen und im Auswahlfeld ein höherer Wert auswählbar ist, wird es definitiv merklich sein, dass die Artikel - Detailseite langsamer lädt.

Wenn es also nicht über Ajax geladen wird, würde ich es nicht umsetzen, vor allem nicht, wenn es schon genug (bessere) Konkurrenz gibt.

Grüße

Sebastian

7

@sschreier schrieb:

@jor schrieb:

@sschreier schrieb:

… falls diese Tabelle nicht per Ajax nachgeladen wird, dass diese Tabelle, speziell bei sehr vielen Varianten, sehr viel an Performance der Artikel - Detailseite kosten wird und die Artikel - Detailseite (wahrscheinlich enorm) verlangsamt…

Meinst Du, dass dieser Punkt auch bei einer gecachten Seite zum Tragen kommt?

…es gibt hier schon Unmengen Themen genau für solche Fälle, wo solche Tabellen (auch inklusive Auswahlfeldern) soviel weiteren HTML - Code generiert haben, das die Artikel - Detailseiten merklich langsamer werden…

Wundert mich ein bisschen, zumal es reiner Text ist. Aber ich denke ich werde das mal mit 200 oder 300 Varianten ausprobieren; ungecacht.

8

Hallo,

ich glaube ja wohl kaum, dass:

a) deine Tabelle und jede Spalte und Zeile nur reiner Text ist und kein HTML (gerade die Unterteilung und farbliche Hervorhebung)

b) das Auswahlfeld für die Menge reiner Text ist

c) die Schaltfläche reiner Text ist

d) weitere Auswahlfelder für Variantenausprägungen reiner Text ist

Und logischerweise macht es am Ende die Summe des weiteren HTML - Codes etc auch aus, wie schnell die Seite gerendert und angezeigt wird.

Ebenso sollte man sich auch Gedanken machen, was beim Ajax - Variantenwechsel passieren und wie das ganze mobil aussehen soll.

Und wie erwähnt sehe ich bei dir bisher noch kein Auswahlfeld für die Artikelmenge, von dem ich aber auch gesprochen habe - und das macht meistens die Performance - Probleme aus, wenn man dann bei dem beispielsweise bis zu einer Menge von 10000 auswählen kann und das dann bei jeder Variante angezeigt wird.

Grüße

Sebastian

9

@sschreier schrieb:

Hallo,

ich glaube ja wohl kaum, dass:

a) deine Tabelle und jede Spalte und Zeile nur reiner Text ist und kein HTML (gerade die Unterteilung und farbliche Hervorhebung)

b) das Auswahlfeld für die Menge reiner Text ist

c) die Schaltfläche reiner Text ist

d) weitere Auswahlfelder für Variantenausprägungen reiner Text ist

Und logischerweise macht es am Ende die Summe des weiteren HTML - Codes etc auch aus, wie schnell die Seite gerendert und angezeigt wird.

Ebenso sollte man sich auch Gedanken machen, was beim Ajax - Variantenwechsel passieren und wie das ganze mobil aussehen soll.

Und wie erwähnt sehe ich bei dir bisher noch kein Auswahlfeld für die Artikelmenge, von dem ich aber auch gesprochen habe - und das macht meistens die Performance - Probleme aus, wenn man dann bei dem beispielsweise bis zu einer Menge von 10000 auswählen kann und das dann bei jeder Variante angezeigt wird.

Grüße

Sebastian

Selbstverständlich ist es HTML. „Reiner Text“ hab ich geschrieben, weil keine Medien zu laden sind.

200x ein SELECT mit OPTIONs von 1 bis 10.000 zur Verfügung zu stellen ist schon ein bisschen extrem. Sowas finden wir in der Praxis doch gewöhnlich bei anderen Schritten, wie zum Beispiel 10x Tausender oder 20x 500er. Aber dazu könnte alternativ auch ein INPUT verwendet werden.

Ich vermute Du meinst mit „d) weitere Felder Variantenausprägung“, etwas vergleichbar mit den Configurator-Dropdowns im oberen Bereich. Falls ja, die Tabelle zeigt ja sämtliche verfügbaren Kombinationen an - von daher gibt es, abgesehen von Menge und Warenkorb-Button, wenn denn eingebracht, auch keine weiteren Formular-Elemente, sondern lediglich Textinhalte in einer Tabelle.

Variantenwechsel betrifft die Tabelle nicht, weil ja sämtliche verfügbaren Varianten angezeigt werden, unabhängig von einer, oder der aktuellen, Auswahl.

Ich denke nicht, dass so eine Gesamtübersicht Varianten mobile wirklich sinnvoll ist. Vor Allem nicht, wenn wir von einer großen Menge Varianten sprechen. Darstellen lässt sich das wahrscheinlich noch recht gut, im Landscape View. Das Auge braucht einen gewissen Raum für solche Ansichten und ich halte den Smartphone-Sceen nicht dafür geeignet. Gerade mobile ist die Dropdown-Auswahl, meiner Meinung nach, ein Muss.

10

Hallo,

der Shopbetreiber legt aber die maximale Bestellmenge in seinem Shop fest, sprich hast du gar keinen Einfluss darauf, ob gerade dieser eine Shopbetreiber dort „10.000“ ausgewählt hat und bei Ihm deshalb die ganze Artikel - Detailseite endlos lädt (er kann ja auch 100 Varianten mit 100 haben, das wäre auch nicht viel anders). Und was ist, wenn weder der Shopbetreiber noch der Kunde aber ein Eingabefeld möchte sondern wie im Standard das Auswahlfeld? Es wäre ja durchaus komisch, wenn man auf der Artikel - Detailseite die Menge über ein Eingabefeld eingibt, im Warenkorb dann aber wieder über ein Auswahlfeld ändern kann.

Was passiert, wenn 300 Varianten da sind, werden die 300 Varianten dann sofort alle angezeigt? Dann kommt man ja nie beim Footer an.

Wenn ein Artikel bei dir 10 Auswahlfelder (also neben Farbe, Größe und Funktion noch 7 weitere) hätte oder die Werte lang wären (beispielsweise 30 Zeichen) - würde bei dir dann ja die Tabelle auch nicht wirklich sinnvoll mehr sein, auch nicht im Desktop, weil Sie dann ja gar nicht wirklich mehr nebeneinander darstellbar wäre?

Und wie willst du das dann mobil machen (Smartphone und Tablet), wird dann die normale Ansicht von Shopware mit den Auswahlfeldern nur angezeigt? Da stellt sich dann natürlich die Frage, ob solch eine „Desktop“-Lösung dann wirklich Sinn macht.

Grüße

Sebastian

11

@jor‍

So unrecht hat er da gar nicht.

Wir haben z.B ein Artikel mit über 4000 Varianten im Programm. Könnte also echt etwas lang werden Deine Tabelle… Wink

12

Da stimme ich zu. Für ausnahmslos jeden Fall ist so eine Gesamtübersicht nicht geeignet; selbst wenn nachgeladen.