leider konnte mir der Support bei diesem Problem nicht weiterhelfen bzw. sieht es nicht als Standard Support, obwohl es eindeutig so aussieht, als obs eine Corefunktion wäre, die nicht funktioniert.
Kurze Vorgeschichte:
Wir nutzen die Artikelattribute u.a. um den Kunden ein MHD unserer Produkte anzuzeigen - dafür nutzen wir ein externes Script, welches über ein einfaches Update Query einmal täglich das MHD aktualisiert - das hatte bisher auch super funktioniert und passiert unabhängig von Shopware.
Wir haben nun bei einem Varianten Artikel das Problem (eventuell liegt der Fehler daran, dass es ein Varianten Artikel ist), dass das entsprechende Freitext Feld (attr1) weder richtig ausgegeben noch richtig im Backend hinterlegt wird, obwohl der Wert in der Datenbank eindeutig hinterlegt ist. Beim Grundartikel (andere Artikelnummer) funktioniert das ganz normal und wie gehabt.
Woran liegt das? Kommt das aus irgendeinem Cache?
Anbei ein paar Screenshots, wie der Wert in der Datenbank drin steht und wie er in den Stammdaten korrekt drin steht, aber auf der Artikelseite nicht angezeigt wird.
Find es etwas komisch, dass die DetailsID gleich der ArtikelID ist. Passt das denn?
Das wichtige ist hier die DetailsID, die ArtikelID kann ruhig leer bleiben.
Ansonsten, teste es doch über das Backend. Wenn es da funktioniert, ist es eher ein Fehler deiner Implementierung.
Zu der Detail & Artikel ID kann ich nichts sagen - das kommt von Shopware und wird von uns nicht angefasst.
Ich glaub die Konstellation meiner Screenshots ist nicht ganz eindeutig.
Ich erklärs kurz noch einmal anders.
Wir haben den Artikel mit unserer Artikelnummer (ordernumber) 150010, im ersten Screenshot suche ich quasi die Shopware Interne „articleID“. Auf dem zweiten Screenshot suche ich anhand der Shopware internen Artikelnummer nach den vergebenen Freitextfelder in der attributes Tabelle.
Im dritten Screenshot rufe ich den Artikel (150010) im Backend auf, scrolle runter und sehe, dass das attr1 Feld - in dem Fall also „MHD“ (Screenshot 4) leer ist.
Beim Grundartikel funktioniert es ja ebenfalls problemlos. Da ist der Wert aus der Datenbank auch in den Shopware Stammdaten. Daher schließe ich das Problem mit dem Datumsfeld aus @useg
Daher verstehe ich nicht woran das liegt, weil der Wert in der DB gesetzt ist, im Backend aber leer.
Die Details-ID ist aber falsch in deinem Screenshot. Wenn du in der s_article_details nach der ordernumber suchst, dann ist die ID vorne die DetailsID die in der s_article_attributes stehen muss - bei dir im Screenshot ist das die 983.
Shopware macht das im Standard schon richtig, aber deine Attributes sind einfach durcheinander/falsch zugeordnet von der ID her. Das kann so also nicht klappen.
Wie kommen die Produkte denn in den Shop? Über das Backend angelegt?
Die Produkte wurden damals extern über die Shopware API gepflegt, seitdem wir Varianten Artikel besitzen gabs da jedoch häufig mal Fehler. Seitdem legen wir diese manuell im Backend an.
Screenshot 2 war dahingend falsch, da ich die articledetailsID zum Suchen für die articleID verwendet habe. Daher sah das falsch in dem Screenshot aus.
Also noch einmal richtig, fangen wir bei Screenshot 1 an.
ich bin in der s_articles_details und suche nach der ordernumber 150010 - diese besitzt die articledetailID 983, articleID 302 (da Variante von ordernumber 150004 bzw 302). Wenn ich nun mit der in den attributes „richtig“ suche, nämlich nach der articledetailsID 983, dann gibt er mir folgendes aus:
Genau, ab 5.2 wird die articleID auch garnicht mehr befüllt. Zudem würde das erste Querry ja auch bei allen Varianten das MHD verändern und nicht nur bei der einen. Das zweite Querry sollte richtig sein.
