Varianten und Auswahllisten sinnvoll einsetzen - Designproblem

Deutsches Forum
1

Hallo,

auf der Suche nach einem flexiblen Shopsystem bin ich vor einer Weile auf die Oxid Community Edition aufmerksam geworden. Da wir die Warenwirtschaft „GS Auftrag“ von Sage einsetzen, wollten wir unseren Shop ursprünglich mit dem Sage Shop umsetzen. Relativ schnell habe ich allerdings eingesehen, dass wir mit diesem Shop nicht weit kommen werden.
Oxid CE scheint für uns für den Start eine Shoplösung zu sein, mit der wir auf Anhieb fast alles umsetzen können. Besonders ideal ist der direkte Zugriff auf die Datenbank und die Anpassbarkeit der Templates. Dennoch „plagt“ mich die Frage, wie ich am sinnvollsten den Shop aufbaue. Ich habe mir verschiedene Ansätze überlegt, aber keiner davon scheint mir ideal zu sein. Eventuell hat jemand von euch eine Idee wie einer der Ansätze zu einem „Idealen“ werden könnte, oder einen ganz Anderen (ich bin mir sicher das ich noch nicht alle Möglichkeiten von Oxid kenne).

Ausgangslage (gilt für ca. 27 Hauptartikel „Leisten“). Die Leisten können diverse Ausführungen haben:

  • Farbe (17 verschiedene)
  • Länge (im Schnitt ca. 40 verschiedene)
  • Klebefilm (ja / nein)
  • Schutz (Lack / Harz / nein)
  • Anschlussstück (ca. 11 verschiedene)
  • Staffelpreise (5 Gruppen)

Ansatz 1:
Farbe und Länge werden als Varianten angelegt, Klebefilm, Schutz und Anschlussstück als Auswahlliste. Die Artikel würden über ein PHP Skript angelegt werden.

Problem:

  • Artikelanzahl: 271740 = 18360St
  • Berechnung von Klebefilm- und Schutzaufpreis schwierig, da Preisberechnung basierend auf m
  • Artikelpflege ist eine Katastrophe (nur automatisch per Skript handhabbar, ich erwarte keine großen Änderungen und nur wenig Preisanpassungen)
  • Wir wollen zunächst mit normalem Webspace starten (ev. leidet die Performance bei einer großen Datenbank)

Ansatz 2:
Farbe wird als Variante, alles Andere als Auswahlliste angelegt

Gut:

  • nur 459 Artikel

Problem:

  • Preisberechnung unterschiedliche Längen. Zunächst war ich vom absoluten Aufschlag begeistert. Wie es der Name allerdings vermuten lässt habe ich dort schon das erste Problem. Kann man irgendwo einstellen, dass der Aufschlag auf dem Variantenstaffelpreis basiert (und nicht auf dem aktuellen Gesamtpreis für den Artikel)?
  • Berechnung von Klebefilm- und Schutzaufpreis schwierig, da Preisberechnung basierend auf m

Ansatz 3: (ähnlich wie Ansatz 2)
Länge wird als Variante, alles Andere als Auswahlliste angelegt:

Problem:

  • 27*40 = 1080 Artikel
  • Preisberechnung der Farbe als Aufschlagsberechnung führt zum gleichen Problem wie bei Ansatz 2 mit der Länge
  • Berechnung von Klebefilm- und Schutzaufpreis schwierig, da Preisberechnung basierend auf m. Dies könnte allerdings gelöst werden, wenn man für die 40 verschiedenen Längen jeweils eine Auswahlliste für Klebefilm und Schutzlack anlegt => führt zu weiterer „Pflege“

Vielleicht sehe ich auch den Wald vor lauter Bäumen nicht und habe eine deutlich einfachere Lösung übersehen?! Das Hauptproblem scheint mir zu sein, dass sich der prozentuale Aufschlag bei einer Auswahlliste nicht auf den ursprünglichen Variantenstaffelpreis, sondern den aktuellen Gesamtpreis (je nach ausgewählten Optionen) bezieht.

Erst einmal vielen Dank für das Lesen des etwas längeren Beitrags. Ich freue mich auf Antworten und auch auf die ein oder andere neue Idee von euch. :slight_smile:

Viele Grüße
Alex

2

Hallo Alex,

auf der Suche nach einem flexiblen Shopsystem bin ich vor einer Weile auf die OXID Community Edition aufmerksam geworden.
Geht mir genau so.

Problem:

  • Artikelanzahl: 271740 = 18360St
  • Berechnung von Klebefilm- und Schutzaufpreis schwierig, da Preisberechnung basierend auf m- Wir wollen zunächst mit normalem Webspace starten (ev. leidet die Performance bei einer großen Datenbank)
    Ebenso. Die Performance wird erschreckend schlecht mit steigender Anzahl an Varianten.

  1. Lösung
    Wenn es die Varianten sein müssen, würde ich alles daran setzen den kompletten Output der Varianten irgendwie zu cachen, am besten das komplette HTML (sollte ja mit dem smary-cache gehen), so das die eben nicht jedes mal neu gelesen werden müssen. Wenn Dir das gelingt, dürfte die Leistung wieder steigen.

  2. Als weitere Lösung, die allerdings nur klappt, wenn

  • man den Preis des Produktes selbst manupulieren kann bevor eine Bestellung daraus wird,
  • und die Varianten keine eigene Nr haben
  • Wenn man zu dem Artikel in Warenkorb-, und Bestellung eine zusätzlich Info einblenden kann
  • ich nicht völlig spinnert bin

könnte man versuchen das ganze Ding dahingehend zu bescheissen, dass die Auswahllisten per Hand gemacht werden. Den Preis on-the-fly kannst Du ja mit js anpassen lassen. Beim abschicken in den Warenkorb berechnest Du aus den eingegenen Werten dann den Preis.

Die Grundlage für die Werte der Auswahlliste könntest Du, falls es sowas wie “custom fields” in oxid gibt, ja dort vermerken, oder Du legst z.B. ein Attribut an wie “Auswahldaten”, dort steht dann z.b.

Farben:rot,grün,gelb
Länge:2.20;+4,2.30;+5,2.40;+6
Klebefilm: ja,nein

Die Ausgabe des Attributes unterdrückst Du natürlich und benutze es nur um eben Deine Auswahlliste zu füllen.

Der Staffelpreis sollte sollte standardmäßig ablaufen, nur eben mit den Aufschlägen die Du aus Deiner Liste hast.

Der Artikel hat dann im Warenkorb oder Bestellung einen zusätzlichen Text mit den gewählten Werten und deren Aufschläge.

Also z.B. so:

Leiste ‘Bern’ ------------------------------------ 15,00 Euro
Grundpreis : 10 Euro
Länge “5 m” : + 4 Euro
Farbe “Grün” : + 1 Euro

Ok, ich habe keinen blassen Schimmer ob sowas mit oxid geht, ich spinne nur mal so rum. Genau genommen stöbere ich erst sein vorgestern über die Seiten hier. Die Änderungen sollten mit dem Modul-konzept ja zu machen sein. Einzig die Übernahme des manipulierten Preises in den Warenkorb, bzw Bestellprozess ist eine mir gänzlich unbekannt Nummer.

Viel Erfolg
ciao, Stefan

3

Was spricht dagegen, alle Optionen als Auswahllisten zu definieren?

Dann hast Du nicht die Variantenprobleme.

4

Hallo Avenger,

fürs Verständnis, die Auswahllisten gibt es nicht so oft wie es Artikel gibt, sondern werden Artikeln zugewiesen?

Angenommen man hat ein Produkt das zig Varianten (Stichwort: Multidimensional) besitzt, die Varianten alle das gleiche kosten und sich nur durch die Art.Nr. unterscheiden.

Also man hat die “Leiste” mit der Nr. “123”

Die Nr. für die Länge ist “L[Nr]”, also z.B. “L2”, “L3”, usw
Die Nr. für für den Kleber ist “K0” oder “K1”

Die Leiste 2m lang mit Kleber hat also die Nr. “123-L2-K1”

Ist dann folgendes Szenario umsetzbar:

Diese Pseudo-Varianten lege ich als Auswahlliste an, die Art-Nr. der Pseudo-Variante bastle ich irgendwie in den Wert mit ein und erstelle aus der Auswahl dann die richtige Nr. für den Artikel wenn Diese in den Warenkorb geklickt wird.

Geht das, also das Manipulieren der Art-Nr. (oder z.B. des Preises) zur Laufzeit?

Das Ziel ist klar, ressourcen sparen im web und beim Import in die Wawi die richtige Nr haben… Andererseits fällt mir auf, das dieser Schritt ja auch beim Import in die Wawi erledigt werden könnte… hm… ich merke, ich bin einfach noch zu Anfängerhaft mit dem oxid

un tschüß, Stefan

5

[QUOTE=stefan2;32944]fürs Verständnis, die Auswahllisten gibt es nicht so oft wie es Artikel gibt, sondern werden Artikeln zugewiesen?[/QUOTE]
Ja.

[QUOTE=stefan2;32944] Angenommen man hat ein Produkt das zig Varianten (Stichwort: Multidimensional) besitzt, die Varianten alle das gleiche kosten und sich nur durch die Art.Nr. unterscheiden.

Also man hat die “Leiste” mit der Nr. “123”

Die Nr. für die Länge ist “L[Nr]”, also z.B. “L2”, “L3”, usw
Die Nr. für für den Kleber ist “K0” oder “K1”

Die Leiste 2m lang mit Kleber hat also die Nr. “123-L2-K1”

Ist dann folgendes Szenario umsetzbar:

Diese Pseudo-Varianten lege ich als Auswahlliste an, die Art-Nr. der Pseudo-Variante bastle ich irgendwie in den Wert mit ein und erstelle aus der Auswahl dann die richtige Nr. für den Artikel wenn Diese in den Warenkorb geklickt wird.[/QUOTE]

Nein, da würde man sinnvollerweise eine Auswahlliste für die Leisten und eine für den Kleber machen

L1 bis Lx

K1 bis Kx

In der Bestellung würden dann die ausgewählten Optionen angezeigt.

z.B.

Leiste L7

Kleber K12

Die Artikelnummer hat damit nicht zu tun, da es sich ja nur um Optionen für denselben Artikel handelt.

Mögliches Problem:

Auswahllisten-Optionen haben keine eigene Artikelnummer…

Im Rahmen eines Kundenprojekts haben wir das gerade als Erweiterung realisiert, was ziemlich aufwändig ist.

6

Hallo Avenger,

Nein, da würde man sinnvollerweise eine Auswahlliste für die Leisten und eine für den Kleber machen

L1 bis Lx

K1 bis Kx
Was zur Folge hat, das es dann genau eine Leiste gibt. Die Leisten als richtige Artikel mit ihrer “Grundnummer” aufzunehmen würde also schon Sinn machen.

Die Artikelnummer hat damit nicht zu tun, da es sich ja nur um Optionen für denselben Artikel handelt.
Nicht wenn man so vorgeht wie Du es beschrieben hast. Wenn es aber eine Wawi gibt, die alle Varianten mit Nummern abdeckt braucht man für den Import des Auftrages schon die korrekte Nummer, die sich ja aus der Auswahl der Optionen (“Pseudo-Varianten” hab ich sie geannt) ergibt.

Mögliches Problem:

Auswahllisten-Optionen haben keine eigene Artikelnummer…
Ich denke das ist kein Problem. Die Ausgabe der Auswahlliste kann man ja abgreifen und die Nr. aus der Anzeige rausstrippen, wenn der Wert aussieht wie “[Wert]|[Art-nr]” braucht man ja, smarty sein Dank, nur ein “{$wert:replace:‘|[Art-Nr.]’:‘’}” anwenden. Oder ähnlich halt.
Im Rahmen eines Kundenprojekts haben wir das gerade als Erweiterung realisiert, was ziemlich aufwändig ist.
Kann ich mir grad nicht vorstellen, was da umgesetzt wurde. Das ein Artikel nur ein Alias ist und eigentlich aus der Summe seiner Optionen besteht? Wie auch immer, so genau brauch ich das nicht Wissen, was mich allerdings interessiert ist, ob diese Erweiterung vollständig als Modul/template-override gelöst ist. Also Du weißt schon, xtc-like Muffe vorm Update. Wenn die Antwort “Ja” ist, bin ich bester Dinge und alles wird gut.

Danke für die Auskunft.
ciao, Stefan

7

Hallo,

erst einmal vielen Dank für eure Antworten.

Genau, überall dort, wo es möglich ist, möchte ich Auswahllisten einsetzen um der Variantenvielzahl zu entgehen und am Ende einen einigermaßen gut pflegbaren Shop zu haben (ansonsten bleibt die Shoppflege später an mir hängen ;-).

Allerdings habe ich bei den Auswahllisten das Problem, das sich die prozentualen Aufschläge immer auf den aktuellen Preis und nicht auf den Grundpreis beziehen. So gesehen funktionieren die Auswahllisten nur gut in Verbindung mit absoluten Preisaufschlägen.
Die Idee, über ein eigenes “Modul” oder per JS den Preis zu manipulieren, klingt an sich nicht schlecht. Das Problem fängt allerdings dann an, wenn der Nutzer JS deaktiviert hat (k.A. wie viele Nutzer das sind, aber wahrscheinlich ist das eher eine Minderheit?!).
Ok, man könnte prüfen, ob JS abgeschaltet ist oder nicht und zur Not nach jeder Änderung einer Auswahlliste die Seite mit aktualisiertem Preis neu laden.

Also wäre die “einfachste” Möglichkeit wahrscheinlich wirklich den Preis “per Hand” zu manipulieren und die meisten Optionen in Auswahllisten anzulegen?!

Gruß,
Alex

8

Hallo Alex

Also wäre die “einfachste” Möglichkeit wahrscheinlich wirklich den Preis “per Hand” zu manipulieren und die meisten Optionen in Auswahllisten anzulegen?!
Ich glaube ja, das ist die Essenz.

Allerdings mußt Du zweimal eingreifen, einmal bei der Detailansicht und einmal beim Warenkorb. Du bastelst zwar in der Detailansicht schön die Anzeige des Preises auf Basis des Grundpreises zusammen, wenn der Artikel aber in den Warenkorb wandert, rechnet oxid wahrscheinlich den Preis nochmal neu aus und der ist dann wieder kaskadiert. Also müsstes Du auch dort dafür sorgen, dass die prozentualen Auf-, bzw Abschläge vom Basispreis berechnet werden.

Also da ich überhaupt keinen Schimmer haben, ob man den “echten” Preis in Warenkorb oder Bestellung manipulieren kann bzw. ob der manipulierte Preis dann auch im weiteren Verlauf bestand hat kann ich nur sagen das meine Vision der Lösung ist.

Ich denke mal, bzw. ich hoffe, dass die Berechnung des Preise in einer einzigen Funktion/Methode zu finden ist. Dann wäre die Mission diese Methode zu finden und per Modul zu überschreiben damit der Preis wie von Dir gewünscht erstellt wird.

Wenn Du da eine Antwort findest wäre nett wenn Du sie mit mir teilen könntest. Danke.

ciao, Stefan

9

Hallo,
die Methode Varianten zu verwenden, ist für den User, also den Endkunden, die Beste - der soll nämlich bequem und schnell zu seinem Kaufabschluss kommen. Wenn die oxid-Varianten eine bessere Performance hätten, müssten wir über all diese Umwege nicht nachdenken.
Ich habe einmal im oxid Demoshop getestet:

Oxid esales Testshop 4.3 mit Oxid multidimensionale Varianten (174 Varianten) gesamt 12 sek
aus der Listansicht zum Artikeldetail: 7 sek
Auswahl 1. + 2. Variante,
danach in den Warenkorb: 5 sek
Also in Summe 12 sek

Der Support hat ähnliches versucht:
“Zu Testzwecken habe ich auf meiner lokalen VM welche Parallel auf meinem Laptop
läuft eine frische unangepasste PE 4.3.2 installiert und einen Artikel mit 256
Varianten(4x4x4x4)angelegt, selbst hier beträgt die Ladezeit im Durchschnitt ca
10,6 Sekunden (Mittelwert von 20 Aufrufen).”

Oxid meint, das sei ein guter Wert - ich meine das ist deutlich zu langsam - wer kennt ähnlich “gute” Ergebnisse?
Wer hat schon einen oxid-Shop entdeckt, der mit mehr als 200 multi-dimensionalen Varianten arbeitet, entdeckt? Der oxid-Support darf aus datenschutzstechnischen Gründen die Links zu den Kunden. die diese Konfiguration einsetzen, nicht nennen.

Technisch gesehen dürfe es so sein, dass beim Aufruf des Variantenartikels alle Varianten geladen werden, auch wenn sie gar nicht benötigt werden - dadurch wird das neu laden der Seite nicht erforderlich, wenn die Variantenauswahl getroffen wird. Diese Vorgangsweise müssten wir ändern, ich kann aber nicht abschätzen wie aufwändig das ist - ich meine aber, es ist ein gröberer Eingriff in die Funktionsweise des Shops. Bitte berichtigt mich, falls ich mich irre.

Zu guter Letzt noch einen Shop des Mitbewerbes, bei dem diese Funktion schnell geht:
http://www.shopwaredemo.de/dialog-one/Beauty-Wellness/Test-Varianten

In diesem Fall werden die benötigten Varianten erst bei der Auswahl geladen.

Also wie kann ich meine Kunden zufrieden stellen, die 500 Varianten (manche kommen sogar auf 2000) benötigen? ZB 10 Farben mit 10 Größen und 5 Materialien - nicht so ungewöhnlich.

lg
Hubert

10

Hallo Hubert,

…Varianten(4x4x4x4)angelegt, selbst hier beträgt die Ladezeit im Durchschnitt ca
10,6 Sekunden (Mittelwert von 20 Aufrufen)."

OXID meint, das sei ein guter Wert - ich meine das ist deutlich zu langsam
Das meine ich auch.

Also wie kann ich meine Kunden zufrieden stellen, die 500 Varianten (manche kommen sogar auf 2000) benötigen? ZB 10 Farben mit 10 Größen und 5 Materialien - nicht so ungewöhnlich.

Das Geheimnis ist das cachen. Es muss ja nicht bei jedem klick der ganze Quatsch immer neu geladen werden. Es ist immer genau solange aktuell, bis etwas an den Varianten geändert wird und im besten Fall zieht man das fertige HTML aus dem smarty-cache, anstatt die Varianten neu zu laden, dass bringt Geschwindingkeit.

Leider bin ich nicht so vertraut mit dem oxid, ich spiele erst seit in paar Tagen damit, doch eine Sache ist schon mal nicht so gut geeignet für die Art von Spaß. Die Templates müssten mehr aus “Blöcken” zusammengebaut sein, so das man einzelne Blöcke eben leicht cachen kann, während andere immer Top-Aktuell sind. Allerdings fällt mir da nur der Warenkorb ein, alles andere kann durchaus eine Weile in cache schlummern.

im “tmp”-Verzeichnis sind ja jede Menge Textdateien mit gecachten Objekten oder Arrays, für den Anfang wäre schon mal nicht schlecht, wenn es eine Datei gäbe wie “oxpec_oxarticle_[ID]_variants.txt”… Vielleicht gibt es das ja in der EE. Wie auch immer, wirklich Ahnung habe ich nicht.

Wenn Dir was einfällt findest Du in mir einen interessierten Zuhörer.

ciao, Stefan

11

Also ich hatte auch das Problem das bei meinem Testshop die Kategorie mit vielen Artikeln und Varianten (insgesamt 5000 Stück) recht langsam war. Jetzt habe ich mal ein kleines Modul geschrieben um die Performance zu verbessern. Eine kleine Kategorie braucht auf meinem Test System ca. 560ms, die große Kategorie (die mit 5000 Artikeln) braucht ohne Modul ca. 1600ms, durch das Modul sind es jetzt noch ca. 700ms. Ich wäre sehr an einem Dump von toto99 interessiert um mal zu schauen ob ich da auch noch optimieren kann. :wink:

12

Ich habe auch das Problem, das bei multidimensionalen Varianten, bei mir gerade mal 59, ich teilweise schon 7 Sekunden warten muss, bis der Artikel geöffnet wird. Wie kann ich die Cachefunktion in der CE ändern, damit es schneller geht?

Gruß René

13

Hallo René

schau doch mal ob folgendes Modul eine Besserung bringt:
http://www.oxid-esales.com/forum/showthread.php?t=6231

Gruß
Benny

14

Hallo !

Ich hab das[B] fastOxid[/B] Modul auch grad getestet und das bringt tatsächlich eine Verbesserung. Leider nicht um das doppelte.

Wir haben unseren Shop auf einem Managed Sever von Hetzner (der kleinste).

Ich hab mal mit dem Netzwerkmodul vom Firebug die Wartezeit für den 1. Request der Seite gemessen (also nicht die komlplette Ladezeit, die liegt um ca. 1,5 s höher)

Artikel mit Varianten - ohne Modul - mit Modul - Gewinn

18 - 1,35 s - 1,28 s - 6 %
21 - 1,46 s - 1,36 s - 7 %
75 - 3,55 s - 2,92 s - 18 %

Wir wollen eigentlich noch mehr Varianten verwenden, vielleicht steigt ja dann der Geschwindigkeitsgewinn noch mehr.

Also erst mal nicht schlecht.

mfg

15

Vielen Dank für Eure Infos. Ihr seid die Besten!

Ich habe es auch gerade getestet und musste feststellen, dass ich mit sämtlichen Optimierungen von 9 Sekunden immerhin auf 3,5 Sekunden komme.

Vielen Dank. Gruß René

16

[QUOTE=tobi73de;37712]Ich hab das[B] fastOxid[/B] Modul auch grad getestet und das bringt tatsächlich eine Verbesserung. Leider nicht um das doppelte.[/QUOTE]

ja, das doppelte bezieht sich auf das Profil “selectVariants” siehe debug modus.