wir haben ein Plugin mit dem zu einem Produkt zusätzliche Daten anzeigt werden. Zum einen in den Produkt-Details und daneben auch im Cart.
Im Cart werden ja faktisch lineItems gezeigt. Bis 6.5 fanden sich im Payload der Items die customsFields des Products. Nun aber scheinbar NICHT mehr. Aktuell gibt es im Key lineItem. payload kein customFields mehr …
Wie bekomme ich die Daten wieder ins das Feld ?
Dann beantworte ich mich mal selbst 
Ich habe das jetzt so gelöst, dass ich mir einen Subscriber für AfterLineItemAddedEvent gebaut habe. Das perfide daran ist, dass man nicht einfach die Werte in Payload.CustomFields setzen kann, weil genau das dann am Ende wieder zurückgesetzt wird. Da gibt es dann wohl ein protected Feature (für 6.6.) evtl. wurde damit dann ein Problem hinein gemogelt.
However wenn ich dann direkt in den Payload schreibe rennt es.
Ich würde mal behaupten das Forum und deren Teilnehmer machen das auf freiwilliger Basis und kostenlos. Ich glaube mit der Erwartungshaltung das man innerhalb weniger Stunden eine Antwort/Hilfe bekommt ist man hier falsch. Dafür gibt es Agenturen.
Zum eigentlichen Problem: Du hast nicht mal deine Shopware Version erwähnt, das erschwert die Hilfe.
naja manchmal funktioniert es ja. Tatsächlich ging es darum ein 6.4.x Plugin auf 6.5.x zu portieren.
In Version 6.5.2.1 sehe ich die CustomFields im Payload Array mit {{dump(page.cart)}}.
Siehe 6.5 changelog: https://github.com/shopware/platform/blob/trunk/UPGRADE-6.5.md#custom-fields-in-cart
Viele Grüße
Ich habe auch das Problem das die customFields in der Payload von dem LineItem leer sind.
Die Einstellung „Verfügbar im Warenkorb“ habe ich aktiviert. Im CartSerializationCleaner habe ich auch geschaut da kommen die Erlaubten Felder richtig an, das Problem ist wohl das die CustomFields schon vor dem Cleaner leer sind.
Kann man mir jemand sagen woran es liegen könnte?
Ich habe das Problem auch nach dem Update von 6.4.20.2 auf 6.5.8.1. In den Zusatzfeldern habe ich „Verfügbar im Warenkorb“ eingestellt. Leider ohne Erfolg. In einem neu aufgesetzten Shop funktioniert das.
Gibt es hierzu eine Lösung?
Bei mir war es ein Problem mit der Standardsprache.
Ich habe dann die IDs von Englisch und Deutsch über die Datenbank getauscht, dann alle deutschen Texte unter der „neuen“ ID gespeichert und dann ging es.
Danke für deine Antwort.
Sorry wenn ich jetzt mal ganz blöd frage. Wie hast du das gemacht? Ganz stumpf über phpMyAdmin die IDs in der Tabelle language tauschen funktioniert wohl nicht.
Standardsprache ist bei mir auf „Deutsch“ eingestellt. Zusätzlich habe ich noch „Englisch“ und noch eine Sprache, die von „Deutsch“ erbt.
Bei mir werden die CustomFields, die ich an Produkten gebunden habe, seit dem Update auf 6.5 auch nicht in der Kategorieübersicht geladen.
Ich hatte das hier mal drin gefunden
Die kurz Version die ich in meine Doku aufgenommen habe sieht so aus
set foreign_key_checks=0;
UPDATE language SET id = UNHEX(REPLACE(UUID(), '-','')) WHERE name='English';
UPDATE language SET id = UNHEX('2FBB5FE2E29A4D70AA5854CE7CE3E20B') WHERE name='Deutsch';
UPDATE language SET id = UNHEX('018B865BA21D706D9EB8403F9457FA97') WHERE name='English';
set foreign_key_checks=1;
Vielen Dank. Allerdings bekomme ich das leider nicht hin.
Das ist schon eine ziemliche Hardcore Lösung, die Language-ID ist ja in etlichen anderen Tabellen vorhanden. Was ja hier passiert ist, nicht das ändern der Default-Sprache sondern der Tausch der Sprach-IDs.
Damit knippst man sich selbst beim nächsten Update aus. Dann gibt es einen Mix von DE/EN und alle Änderungen in PHP und JS, sind nicht mehr da.
Ich bin für andere Vorschläge offen, ich habe keine andere Möglichkeit gefunden.
Die andere wäre wohl gewesen wenn man die Konstante LANGUAGE_SYSTEM ändert, da war mir dieser Tausch einfacher.
Was passiert denn bei einem Update was zu solchen Problemen führen sollte das Änderungen in PHP und JS nicht mehr da sind, bei mir ist bisher nichts dergleichen passiert.
Wenn es einmal eine Änderung an diesen Dateien gibt, dann werden die Änderungen überschrieben.
Zumindest die Standard-Sprache EN mit der entsprechenden UUID ist hart-kodiert und wird halt so in Updates (für die DB) für den Core und sicher auch für Plugins genutzt.
Die Ursache ist sicherlich die „schräge Idee“ mit den UUIDs anstatt einfach ISO-Kürzel zuverwenden.
Eine echte Lösung sehe ich aber auch nicht; vermutlich muss man damit einfach leben, und halt English als Fallback mit rumschleppen. Notfalls haben dann die englischen Begriffe dann einfach auch deutsche Standardwerte …
Die Frage ist ja auch, wieso das an den Sprachen liegt. Shopware legt ja immer die Sprachen Deutsch und Englisch an. Dann hätten ja sehr viele dieses Problem, dass die Zusatzfelder nicht richtig angezeigt werden. Bei einem neu angelegten Shop funktioniert das. Wobei ich das nicht getestet habe, ob dies auch mit zusätzlichen eigenen Sprachen funktioniert. Allerdings sollte das doch möglich sein, da es (zumindest theoretisch) doch keinen zusammenhang geben sollte.
ich denke das sind 2 Probleme - evtl. gibt es aber eine Abhängigkeit.
„Früher“ war es so, dass ein Product-LineItem automatisch alle Custom-Felder des zugrundeliegenden Products „geerbt“ hat. Halt auch in alle definierten Sprachen.
Wenn man dann versucht nach 6.5. das „zu heilen“, und hier evtl. einen Fehler macht, dann laufen evtl. nicht alle Daten durch.
Vielleicht ist hier auch das Problem mit fehlenden Sprach-Werten ?
Beim Umbau unseres Shop für 6.5 ist das Problem aufgetreten von daher denke ich das @chamaw hier recht hat.
Die Lösung mit den IDs tauschen klingt zwar hart, aber ist es nicht so das es eigentlich nur ein umbenennen der Sprachen ist. Der Shop nutzt ja weiter die von ihm vorgesehen Standard ID 2fb… ob dahinter jetzt deutsche oder Englische Texte liegen ist ja eigentlich Total egal.
Ich habe bisher keine nachteile gemerkt, auch bei den durchgeführten Updates.
Anders wäre es wahrscheinlich gewesen wenn ich die Standard ID 2fb… geändert hätte.
Verstehe sowieso nicht wieso man sowas Grundlegendes wie die Standardsprache des Shop nichts „einfach“ irgendwo ändern kann
Ich weiß ja nicht, ob das nur bei mir so ist. Aber ich habe gesehen, dass es bei uns drei Sprachen der Benutzeroberfläche gibt. 2x Deutsch und 1x Englisch.
Angelegt sind zwar drei Sprachen (Deutsch, Englisch und eine eigene) und die werden an den meisten Stellen, wo man die einzelnen Sprachen zuordnen kann, auch korrekt wiedergegeben. Nun wollte ich einen neuen Nutzer anlegen und hier werden unter Sprachen der Benutzeroberfläche 2x Deutsch und Englisch angegeben. In der Tabelle language sind aber auch nur die Sprachen zu finden, die ich angelegt habe.
Wie kann das sein? Tritt dieser Fehler bei euch auch auf?
Bei mir nicht, ich habe aber aber nur zwei Sprachen angelegt.
Da ihr drei angelegt habt ist die Auswahl ja erstmal richtig ist wahrscheinlich nur die Anzeige falsch.
Meine Vermutung wäre jetzt das dir eine Übersetzung für die eigene Sprache fehlt und deshalb Deutsch als Fallback genommen wird