Neu Einstellung: "Bilder des Vaterartikels un der folgenden Variationswerte übernehmen" und der Shopware Server "explodiert"

[JTL4Tom]

Hallo Zusammen,
ich hab ein schwerwiegendes Problem und beim JTL-Support hat man mir erneut das Ticket dazu ohne verwertbare Antwort geschlossen.

Wir können den Shop aktuell so nicht, wie vorgesehen, betreiben. Wirtschaftliche Nachteile sind damit bereits verbunden.


Ausgangslage:
Var-Kombi-Artikel mit 5 Produkt-Bilder und auch vier Variationen incl. Variatentenbild.

Ziel:
In Shopware 6 sollen immer alle Produktbilder gezeigt werden, sowie abhängig der Variatantenauswahl auch das jeweilige Variantenbild gezeigt werden.

Problem:
Funktion "Bilder des Vaterartikels un der folgenden Variationswerte übernehmen" kann nicht verwendet werden.

Grund:
Lege ich den Artikel manuell ins Shopware 6 an, wird Speicherplatz für 5 + 4 = 9 Bilder in Anspruch genommen. So wäre richtig. So war in SW5 auch über den kostenlosen Connector.

Wird der Artikel nun über den kostenpflichtigen JTL-Shopware-Connector mit der Einstellung:
"Bilder des Vaterartikels un der folgenden Variationswerte übernehmen" erstellt, so finden sich dann in der Medienverwaltung:
5 Bilder (beim Vater) + 4 x (5+1) Bilder bei den Kindartikel --> 29 Bilder !!!

Nun haben wir Artikel mit ca 720 Varkombis und 4-5 Produktbilder.
Wenn man bedenkt, dass dann auch noch mehrere Thumbnails erstellt werden, so komme ich auf mehrere Tausend Bilder in der Medienverwaltung.
z.B. 720 x 5 = 3600 plus vielfaches an Thumbnails. (https://www.ledclusive.de/fluxe-75-lv--805a03bl9t02)

Wir mussten, damit der Server nicht explodiert alle Variationskombi-Bilder abschalten.

Leider inzwischen mit negativer Auswirkung und deswegen jetzt auch dieser Post.
Aufgrund fehlender Bildumschaltung hatten wir jetzt durch die Fehlinterpretation von Kunden auch schon zu Fehlbestellungen erhalten.

In Shopware 5 gab es diese Problematik nicht. Warum nun diese Verschlechterung.

 

[JTL4Tom]

Hallo Zusammen,
ich hab ein schwerwiegendes Problem und beim JTL-Support hat man mir erneut das Ticket dazu ohne verwertbare Antwort geschlossen.

Wir können den Shop aktuell so nicht, wie vorgesehen, betreiben. Wirtschaftliche Nachteile sind damit bereits verbunden.


Ausgangslage:
Var-Kombi-Artikel mit 5 Produkt-Bilder und auch vier Variationen incl. Variatentenbild.

Ziel:
In Shopware 6 sollen immer alle Produktbilder gezeigt werden, sowie abhängig der Variatantenauswahl auch das jeweilige Variantenbild gezeigt werden.

Problem:
Funktion "Bilder des Vaterartikels un der folgenden Variationswerte übernehmen" kann nicht verwendet werden.

Grund:
Lege ich den Artikel manuell ins Shopware 6 an, wird Speicherplatz für 5 + 4 = 9 Bilder in Anspruch genommen. So wäre richtig. So war in SW5 auch über den kostenlosen Connector.

Wird der Artikel nun über den kostenpflichtigen JTL-Shopware-Connector mit der Einstellung:
"Bilder des Vaterartikels un der folgenden Variationswerte übernehmen" erstellt, so finden sich dann in der Medienverwaltung:
5 Bilder (beim Vater) + 4 x (5+1) Bilder bei den Kindartikel --> 29 Bilder !!!

Nun haben wir Artikel mit ca 720 Varkombis und 4-5 Produktbilder.
Wenn man bedenkt, dass dann auch noch mehrere Thumbnails erstellt werden, so komme ich auf mehrere Tausend Bilder in der Medienverwaltung.
z.B. 720 x 5 = 3600 plus vielfaches an Thumbnails. (https://www.ledclusive.de/fluxe-75-lv--805a03bl9t02)

Wir mussten, damit der Server nicht explodiert alle Variationskombi-Bilder abschalten.

Leider inzwischen mit negativer Auswirkung und deswegen jetzt auch dieser Post.
Aufgrund fehlender Bildumschaltung hatten wir jetzt durch die Fehlinterpretation von Kunden auch schon zu Fehlbestellungen erhalten.

In Shopware 5 gab es diese Problematik nicht. Warum nun diese Verschlechterung.

Yes Yes. Inzwischen wurde ein Bug-Ticket angelegt. bitte auch Voten: https://issues.jtl-software.de/issues/CO-2539

 

[Agentur Wolkenlos]

Wir haben das gleiche Problem! Dachte ernsthaft, es gibt eine Lösung dafür???

 

[Felix-lg]

Moin Tom,
danke für deine Hartnäckigkeit... Auch wir haben das Problem. Verstehe es auch einfach nicht und hatte bereits vor ein paar Monaten die Diskussion mit JTL.
Das Ticket habe ich gevotet und freue mich das nun scheinbar etwas passiert...

Wir verkaufen Bekleidung und sobald man da eine Kombi aus Farbe und Größe hat explodiert einem auch alles, obwohl natürlich alle Größen die gleichen Bilder haben sollten...

Verstehe auch wirklich nicht warum es so so viele Themen und Bugs mit SW6 gibt. Wir sind mittlerweile Live mit SW6 und zahlen schön die 199€/Monat für eine Menge Probleme.

Wirklich schade.
Gruß
Felix

 

[JTL4Tom]

Wir haben das gleiche Problem! Dachte ernsthaft, es gibt eine Lösung dafür???

dann bitte hier unbedingt schnell voten: https://issues.jtl-software.de/issues/CO-2539

 

[Belushi]

Ich will nicht unken (unser SW 6.4 verhält sich auch so!), aber... sicher, dass das ein Bug ist?

Ich denke, das ist sogar technisch unumgänglich:
Wenn ihr Varianten anlegt, z.B. 5 Größen, und nur den Vaterartikel mit 3 Bildern bestückt, existieren physisch natürlich nur 3 Bilder. Klar.
Sobald die Vererbung für die Bilder in der Wawi aktiviert wird, sind es rein logisch aber 5 x 3, + 3 für den Vater, also 18.
Ich hab's jetzt nicht getestet, aber ich denke mal, SW kann nur dann Bilder vom Vater vererben, wenn die Kinder überhaupt keine eigenen Bilder haben; das würde anders auch keinen Sinn ergeben. Der Connector "sieht" aber in jeder Variante die (vererbten!) Bilder, die ihm die Wawi anbietet - und überträgt die dann eben alle.

Ich kann das jetzt leider nicht an unserem anderen Shop mit JTL-5 prüfen, weil wir Varianten und Kombis grundsätzlich zumindest ein eigenes Hauptbild geben (ist fast immer "Farbe"), aber ich bin mir ziemlich sicher, der JTL-5 Shop verhält sich auch so. Dafür spricht unter anderem, dass die Bild-URLs ja indirekt über die Produkt-URLs bzw. SEO-URLs generiert werden, die für Varianten unterschiedlich sind. Und ich wüsste nicht, dass der Shop innerhalb einer Variante die URL seines Vaters referenzieren kann, um von dort das Bild zu ziehen. Das wäre auch für SEO gaaanz schlecht, wenn mehrere Produktvarianten identische Bild-URLs hätten. Auch mit gesetztem Canonical-Tag.

Sag ich mal so in meinem jugendlichen Leichtsinn.

 

[JTL4Tom]

HI Belushi,

danke, dass du dich damit beschäftigst.
ich kann zwei Dinge dazu sagen:
a) in shopware 5 war das mit Verknüpfungen gelöst. Die Bilder waren bei den Kindern als verknüpftes Bild vom Vater hinterlegt
b) legt man in sw6 variationskombis mit variantenbildern an, so benötigt es bei den Kindern auch jeweilig die Bilder vom Vater.
dazu werden die gleichen Bilder, wie beim vater aus der Medienverwaltung angeklickt. dh. Bild ist 1x in der Medienverwaltung wird neben Vater auch bei den Kindern ausgegeben.

Es ist der JTL Connector, der hier die Bilder vielfach in der Medienverwaltung jeweils für jede Variante extra anlegt. Das ist technisch ungünstig gelöst und kann auch anders.
Wie eben sw5 schon konnte.

 

[Belushi]

Hallo JTL4Tom,

Ja, so funktioniert das, wenn man die Varianten in Shopware 6 manuell anlegt. Mit Betonung auf "manuell". Wawi + Connector ist was ganz anderes
Ich gehe fest davon aus, dass der Connector genau das macht, was ihm die Wawi sagt - bzw. das Überträgt, was ihm die Wawi anliefert. Und die Wawi sagt, in den Varianten liegen Bilder! Das Siehst Du auch, wenn Du eine Variante öffnest; die ist ja nicht bilderlos.

Tatsächlich bin ich nichtmal sicher, ob die Wawi nach dem Generieren der Varianten und Varkombis selbst noch unterscheiden kann, ob die Bilder dort manuell eingefügt - oder vererbt wurden. In unserer 1.8er sehe ich da jedenfalls keine Hinweise. Beim Vererben passiert letztlich ja nichts anderes, als dass die Wawi die Datenbank-IDs der Bilder vom Vater in die Variante kopiert. Und da stehen sie dann drin. Und werden vom Connector pflichtbewusst übertragen. Dass das ggf. immer die selben Bilder sind, wird der Connector nicht mehr unterscheiden können.

Wenn das mit dem JTL-5 Connector (anders) funktioniert hat, liegt das vermutlich daran, dass das meiner Erinnerung nach kein SaaS war sondern eine Software, die man neben der Wawi installiert hat und die dann weitreichenden Zugriff auf die Wawi-Datenbank hatte. Vielleicht hat der das mit der Verknüpferei dann anders gehandhabt.
Aber, wie oben schon geschrieben: Wenn sich tatsächlich mehrere Varianten die selben Bilder (und damit auch Bild-URLs) teilen würden, wär das "nicht so gut" für's SEO Spätestens, wenn Du Exporte z.B. zu AdWords, Shopping oder ähnlichem via Shop-Verkaufskanal machst. Genau das (identische Bild-URLs) würde aber passieren, wenn Du immer die selben Bilder aus der Medienverwaltung einfügst.
Sprich: Nur, weil etwas geht (und zugegebenerweise den einen oder anderen Vorteil hat) muss es noch nicht richtig oder sinnvoll sein.

 

[JTL4Tom]

Hallo JTL4Tom,

Ja, so funktioniert das, wenn man die Varianten in Shopware 6 manuell anlegt. Mit Betonung auf "manuell". Wawi + Connector ist was ganz anderes
Ich gehe fest davon aus, dass der Connector genau das macht, was ihm die Wawi sagt - bzw. das Überträgt, was ihm die Wawi anliefert. Und die Wawi sagt, in den Varianten liegen Bilder! Das Siehst Du auch, wenn Du eine Variante öffnest; die ist ja nicht bilderlos.

Tatsächlich bin ich nichtmal sicher, ob die Wawi nach dem Generieren der Varianten und Varkombis selbst noch unterscheiden kann, ob die Bilder dort manuell eingefügt - oder vererbt wurden. In unserer 1.8er sehe ich da jedenfalls keine Hinweise. Beim Vererben passiert letztlich ja nichts anderes, als dass die Wawi die Datenbank-IDs der Bilder vom Vater in die Variante kopiert. Und da stehen sie dann drin. Und werden vom Connector pflichtbewusst übertragen. Dass das ggf. immer die selben Bilder sind, wird der Connector nicht mehr unterscheiden können.

Wenn das mit dem JTL-5 Connector (anders) funktioniert hat, liegt das vermutlich daran, dass das meiner Erinnerung nach kein SaaS war sondern eine Software, die man neben der Wawi installiert hat und die dann weitreichenden Zugriff auf die Wawi-Datenbank hatte. Vielleicht hat der das mit der Verknüpferei dann anders gehandhabt.
Aber, wie oben schon geschrieben: Wenn sich tatsächlich mehrere Varianten die selben Bilder (und damit auch Bild-URLs) teilen würden, wär das "nicht so gut" für's SEO Spätestens, wenn Du Exporte z.B. zu AdWords, Shopping oder ähnlichem via Shop-Verkaufskanal machst. Genau das (identische Bild-URLs) würde aber passieren, wenn Du immer die selben Bilder aus der Medienverwaltung einfügst.
Sprich: Nur, weil etwas geht (und zugegebenerweise den einen oder anderen Vorteil hat) muss es noch nicht richtig oder sinnvoll sein.

hmm. welche Schlussfolgerung würdest du ziehen aus diesen Zusammenhängen:
1) JTL-Wawi 1.5xx mit sw5 connector an sw5 --> kein Chaos
2) JTL wawi 1.5xx mit sw6 connector an sw6 --> Chaos
3) Varkombi-Bilder-Verwaltun in sw6 backend --> kein Chaos

Was hat sich geändert? jtlwawi konnte das mit dem sw5 connector ? also kann es nicht an der Wawi, sondern muss am Connector liegen. völlig egal, ob der als SaaS gelöst ist, oder nicht.
(by the way. inzwischen sind wir auch mit 1.8. unterwegs)

zu SEO und teilen von Bildern. ganz einfach. Varkombis also die Childs haben nichts im Index zu suchen, somit auch nicht die Bilder.

Schon fürs Ticket gevoted?

 

[Belushi]

Wie gesagt, ich bezweifle nicht, dass es mit dem SW-5 connector evtl. anders funktioniert hat als mit SaaS, aber mit SW-6 hat sich ja evtl. auch bei den Verknüpfungen selbst etwas geändert, auf das der Connector reagieren musste. Ich hab keinen Einblick ins Datenbankmanagement.
Ich hatte aber auch geschrieben, dass es IMHO JTL-5 mit dem normalen Worker auch so handhabt. Dass das alte verhalten aus Speichersicht wünschenswert ist, verstehe ich ja. Ich sehe es aber logisch richtiger, so, wie es jetzt ist. Für das Ticket vote ich gerne noch, aber ich glaube nicht, dass das Problem so lösbar ist.

 

[Belushi]

Ah, ein Nachtrag noch - Bilder, Kinder und SEO:
ja, bei Kindern sollte das mit den Bildern bei korrekt gesetzten Canonicals keine Rolle spielen. Aber trotzdem landen Kinder im Index, wenn man sie nicht auf noindex/nofollow setzt. Wenn also irgendjemand genau nach meinem Produkt sucht, explizit in Rot, und ich habe Rot als Variante, wird Google mir im Zweifelsfalle auch die rote Variante als Ergebnis anzeigen, und nicht den Canonical-Vater.

Das größere Problem sind z.B. adWords und Shopping - da spielen wir auf Wunsch des SEO/SEM-Teams die Varianten aufgefächert aus, also als einzelne Produkte. Da wären doppelte Bild-URLs nicht hilfreich.

PS: gevoted

 

[Felix-lg]

Gutem Morgen Zusammen!
Danke für euren Austausch hier...

Bei uns kommen Varianten vor allem im Bereich Bekleidung zu tragen. Da ist es aktuell bei uns so (und das empfinde ich leider nicht als gut):
- Es gibt nur Varianz in der Größe --> 5 Kinder, alle das gleiche Bild. Dafür müssen wir beim Anlegen in JTL Alle Kanäle beim Vater und den Kindern mit Bildern füllen, NUR den Kanal SW6 bei den Kindern lassen wir leer. So stellen wir sicher, das es wie beschrieben nur einmal die gleichen Bilder in Shopware gibt. In JTL wiederum brauchen wir die Bilder auch an den Kindern, z.b. für den Pickprozess über WMS App. Sonst hat man dort kein Bild beim picken. Bilder generell nur beim Vater geht also nicht.

- Farbvarianz stellen wir als eigene Artikel ein. Das ist total blöd, aber auch wegen den Bildern aktuell so umgesetzt. Wenn wir nämlich nun noch eine Farbvarianz zu den Größen einbringen würden, funktioniert die Logik nicht mehr wie oben beschrieben. Nun müssen alle Kinder Bilder in Shopware haben, da sie ja bei Farbwechsel ändern müssen. Wenn ich also Varianz Farbe --> Größe habe, habe ich bei 2 Farben mit jeweils 5 Größen theoretisch zwei verschiedene Bilder. Wenn ich allen Kindern ein Bild gebe und damit die Vererbung in SW6 deaktiviere, habe ich in Shopware anschließend 10 Bilder anstatt 2. Hier müsste also wie von Tom beschrieben irgendeine Logik greifen, die Bilder verknüpft anstatt sie doppelt hochzuladen. So wie es ja in der JTL Datenbank am Ende auch passiert

In Shopware 5 war es übrigens so gelöst, dass es ein Funktions-Attribut gab, dass für ausgewählte Varianz die Bilder "ignoriert" hat: sw_image_config_ignores siehe https://guide.jtl-software.com/jtl-connector/shopware/bilder-fuer-variationsartikel-zuweisen/
Das war eigentlich eine gute Lösung und ich könnte mir schon vorstellen, dass man das gleiche Prinzip auch für den SW6 SAAS Connector umsetzen kann.

Dann noch eine konkrete Frage @Belushi : Wo siehst du das Problem mit gleichen Bild-URLS für den Produkt-Export für GoogleAds? Wir machen das für die beschriebene Größenvarianz genau so. Kinder werden ausgespielt (gruppiert über das entsprechende Feld) und haben jeweils die gleiche Bild-URL hinterlegt. Mir scheint es da bisher kein Problem gegeben zu haben.

Vielleicht übersehe ich etwas, aber Stand jetzt bin ich ganz bei Tom und würde mir schnellstmöglich ein Funktionsattribut oder ähnliche Lösung für SW6 wünschen.

Schöne Grüße
Felix

PS: Im Ticket scheint es bisher nicht weiterzugehen?

 

[JTL4Tom]

Gutem Morgen Zusammen!
Danke für euren Austausch hier...


PS: Im Ticket scheint es bisher nicht weiterzugehen?

Ja ich höre leider auch nichts mehr von JTL dazu. Mir wurde mitgeteilt, dass man da dran ist und gab mir einen optimitisches Zeitfenster. aber das ist bald rum.
Leute, da hilft nur voten (link oben) und JTL-Support dazu von allen Seiten diesbezüglich kontaktieren.
Mich ärgert das maßlos, denn ich kann meine Produkte nicht so verkaufsfördernd anbieten und sicherlich auch mit ein Grund für geringere Umsätze.

 

[Felix-lg]

Hallo @JTL4Tom ! Hast du noch irgendetwas von JTL gehört dazu? Am Ticket scheint sich bisher nicht viel zu tun.
Gruß
Felix

 

[JTL4Tom]

Hallo @JTL4Tom ! Hast du noch irgendetwas von JTL gehört dazu? Am Ticket scheint sich bisher nicht viel zu tun.
Gruß
Felix

Nein leider nichts gehört. ich habe hier zu bisher auch keine andere Lösung gefunden, nur den schlechten Kompromiss auf die diese Bildumschaltung zu verzichten. Leider mit Verschlechterung der Conversion-Rate. Ich hätte niemals zu SW6 und diesem Connector wechseln sollen.

 

[Felix-lg]

Schade. Schon sehr ärgerlich das Ganze...
Wir nutzen mittlerweile als "Workaround" folgendes Plugin für Shopware: https://store.shopware.com/de/fgits40437994520/virtuelle-varianten.html
Funktioniert ganz gut mit JTL, da wir über ein Eigenes Feld die Verknüpfung machen können. Sprich Produktvarianten "Farbe" werden als eigene Artikel angelegt und dann über ein Eigenes Feld (identischer Wert) miteinander verknüpft.
Ergebnis im Frontend ist dann wie gewünscht.

Nicht optimal, aber zumindest eine Lösung die für uns halbwegs funktioniert.

 

[JTL4Tom]

Schade. Schon sehr ärgerlich das Ganze...
Wir nutzen mittlerweile als "Workaround" folgendes Plugin für Shopware: https://store.shopware.com/de/fgits40437994520/virtuelle-varianten.html
Funktioniert ganz gut mit JTL, da wir über ein Eigenes Feld die Verknüpfung machen können. Sprich Produktvarianten "Farbe" werden als eigene Artikel angelegt und dann über ein Eigenes Feld (identischer Wert) miteinander verknüpft.
Ergebnis im Frontend ist dann wie gewünscht.

Nicht optimal, aber zumindest eine Lösung die für uns halbwegs funktioniert.

danke Felix für deine Antwort und deinem Workaround.
das wäre ja wieder ca 15€ Fixkosten zur Lösung einer Unzulänglichkeit des JTL Connectors. Der alte zu SW5 konnte das.
Wo soll das noch hinführen.