wir haben hier ein seltsames Problem. Wir haben Artikel mit Varianten. In diesem Fall ist der Gruppenname “Color”.
Diesen sind Attributsoptionen zugewiesen (in diesen Fall “Sunkissed”, “Bassin” und “Ballon”). Diese möchten wir von der Reihenfolge her ändern (geht per Drag & Drop).
Nach der Änderung der Reihenfolge haben wir das Set gespeichert und die Varianten neu generiert. Soweit funktioniert alles. Wenn wir aber andere Artikel ändern und dort die Reihenfolge ändern, verändern sich auch willkürlich zuvor geänderte Artikelvarianten. Scheinbar aber nur wenn diese auch den Farb-Namen haben (z.B. “Sunkissed”).
Wir haben alles versucht:
bei “Set speichern” einen neuen Namen vergeben
Varianten generieren: “Zusammenführen” oder “Überschreiben” versucht.
Nach dem Speichern das Set noch einmal neu gespeichert-
Alles kein Erfolg. Auch bei den anderen Varianten-Artikeln haben wir einen neuen Set-Namen vergeben.
Hier der Screenshot wo die Varianten zu finden sind (Shopware-Version 5.5.6, Build Rev. 201901211535):
nur so einfach liegt es leider nicht oder ich missverstehe da etwas.
Die Sortierung der Optionen erfolgt in der Stammdatentabelle der Optionen “s_article_configurator_options”.
Somit ist es doch so, dass die Änderung der Position einer Option die Sortierung in allen Artikeln betrifft, welche diese Option (in unserem Fall “Farbe”) verwendet. Und das ist das Problem.
Besser wäre es, es gäbe eine Tabelle, wo die Artikel-Set-Gruppen-Optionen-Beziehung gespeichert würde und darin die Position der Option. Dann könnte pro Artikel eine individuelle Sortierung der Optionen erfolgen.
Lustigerweise gibt es scheinbar eine solche Tabelle > “s_article_configurator_option_relations”, aber es ist schleierhaft, wie man hier die Zuordnung Artikel > Option UND die Position speichern kann, zumal es a) in dieser Tabelle keine Spalte für die Position gibt und b) Shopware in dieser Tabelle scheinbar nichts mehr speichert.
Die konkrete Frage lautet also, wie kann man einem Artikel Farben zuzordnen und diese individuell pro Artikel sortieren, ohne, dass die Sortierung in anderen Artikeln beeinträchtigt wird?
Wir arbeiten aktuell nur mit einer Gruppe (Größe). Hatten aber auch mal zusätzlich die Gruppen Länge und Farbe. Und das hat alles funktioniert.
Ist schon ziemlich lange her, das wir genau das gleiche Problem hatten, weshalb ich eine .xlsx-Tabelle erstellt habe, um Varianten vernünftig sortieren zu können.
Du findest in der Tabelle s_article_configurator_options die Spalte “group_id”. Die Gruppen bzw. deren ID findest Du in der Tabelle s_article_configurator_groups.
In der Tabelle s_article_configurator_option_relations findest Du die Spalte option_id. Diese ID findest Du in der Tabelle s_article_configurator_options in der Spalte ID.
Sortier in der DB in der Tabelle s_article_configurator_options mal nach Name und schau, ob es doppelte Einträge gibt.
Zu Deiner letzten Frage: Das geht wie oben beschrieben, ist aber erstmal aufwendig.
Aber vielleicht gibt es auch ein Plugin dafür.
Ich kenne die Tabellen und die Sortierung bringt auch über eine Exceltabelle nichts, denn es ist nicht möglich, Optionen speziell für einen Artikel zu sortieren, solange das Sortierkennzeihen in der Tabelle der Optionen steht.
Ich mag mich täuschen und lerne gerne dazu, aber das führt das Prizinip “privater” Sets eigentlich ad absurdum, denn was brächten diese, wenn angewendete Änderungen, wie die Sortierung der Optionen dann doch auf alle Artikel wirken, welche diese Optionen verwenden.
Klar könnte man ein Plugin schreiben, welches beispielsweise die Tabelle “s_article_configurator_option_relations” um die Spalte “position” erweitert UND noch dazu das Backend und Frontend so anpasst, dass individuelle Sortierungen in Verbindung zum Artikel darin gespeichert und im Frontend berücksichtigt werden.
Irgendwie fehlt mir dazu aber der Antrieb, denn warum sollte es dann diese “relations”-Tabelle und “private” Sets geben?
Was habe ich nicht verstanden?
Doubletten gibt es in der s_article_configurator_options tatsächlich. Dazu musste ich aber nicht sortieren und hunderte Einträge durchsuchen . Da gibt es eine einfache Abfrage:
SELECT *, COUNT(NAME) count_duplicates FROM s_article_configurator_options GROUP BY NAME HAVING COUNT(NAME) > 1 ORDER BY NAME;
Keine der Doubletten betrifft das Problem mit der individuellen Sortierung von Optionen.
Übersehe ich einen Zusammenhang?
Da eine Sortierung der Varianten-Optionen (auch wenn man Sets speichert) nicht funktioniert, haben wir uns für eine andere vorgehensweise entschieden:
Man legt eine neue Gruppe an die den gleichen Namen hat (z.B. Farbe) und vergibt dann NEU die Farben (ohne diese aus den inaktiven Optionen heraufzuschieben.
Problem bei der ganzen Sache ist, dass man nach geraumer Zeit eine ziemliche Ansammlung an gleich lautenden Gruppen erhält was sehr unsauber ist.
Mich hat das jetzt auch beschäftigt da bei mir der wechsel der Variantendarstellung nicht funktioniert hatte. Die Lösung war aber eigentlich ganz einfach. Ich musste nur die „Art des Konfigurators“ von Bild auf Standard umstellen. Danach hat es mir die gwünschte Reihenfolge übernommen.
. Da gibt es eine einfache Abfrage: