Über kurz oder lang trifft es jeden mal – Update von Produktbeschreibungen von ≥3000 Produkten für multilinguale storeViews steht an – kein Problem! CSV zurechtbasteln und rein in Magento’s import/export-Schnittstelle, genau!!
Denkste!! Unter unguten Umständen zerhaut es einem das Layout der Produktdetailseiten der ConfigProducts da deren Options-Auswahlfelder runter in den Block nach der Infospalte rutschen! Arghh.. tut das Not?
Normalerweise bekommt jetzt der ShopAdmin erst mal einen Heulkrampf, weil er sich schon die nächsten zwei Wochen damit beschäftigt sieht alle Produkte von Hand und per Backend wieder in die designierte Position zu befördern – Halt! Geht „Magento sei Dank!“ auch anders..
Wie kommts?
Gesetzt dem Fall, dass der Store ein TemplateLayout nutzt, dessen view.phtml die Optionsfelder nach der Artikelinformationsspalte setzt, ist noch alles gut, denn im System hat sich nix wirklich geändert.
Falls jedoch das Gegenteil der Fall ist und alle Produkte global per Standardwert für alle storeViews die Optionsfelder innerhalb der Produktinfospalte gesetzt haben [durch das Produktattribut „Display Product Options In“ des Designtabs in den Artikelinfos] brennt jetzt wirklich die Hütte. In diesem Fall scheint Magento’s Importer, beim Update der Produkte für explizit angegebene storeViews, das Produkt wie neu angelegt zu haben. Dabei werden die Zuordnungen für „Display Product Options In“ wieder auf Standardwert [also laut Standarddefinition in der DB in „mg_eav_attribute“.“default_value“ = „container2“] gesetzt, falls nicht explizit in der CSV definiert – was wiederum besagtem „Block nach der Infospalte“ entspricht. Da dies jedoch nicht dem global definierten Standardwert entspricht werden nun in der DB im Table „mg_catalog_product_entity_varchar“ für jedes upzudatende Produkt ein zusätzlicher Eintrag pro storeView geschrieben. Juhu => 3000 * storeViews!! Da kommen schnell mal 10.000 neue Einträge zusammen und spätestens jetzt lässt sich das blasse Gesicht unseres Shopadmins nachvollziehen.
Was tun?
Magento hat für diesen Fall ein nettes Feature das unser ShopAdmin die meiste Zeit übersieht oder vielleicht noch nie bemerkt hat! Unter „Artikel verwalten“ lassen sich mehrere Artikel gleichzeitig auswählen und per Aktionen-DropDown mit „Attribute aktualisieren“ gleichzeitig verwalten. Bietet sich an bei einem Update innerhalb der 100er Marke.
In unserem Fall mit ≥3000 Produkten jedoch muss jetzt ein ernsthaftes Tool her um direkt auf der DB die Notbremse ziehen zu können – phpMyAdmin wäre solch ein Tool der Wahl:
Um die irrtümlich in „mg_catalog_product_entity_varchar“ erzeugten Werte wieder los zu werden muss erst in „mg_eav_attribute“ nach der attribute_id des „options_container“s gesucht werden. Folgendes sql liefert was gesucht wird:
SELECT * FROM `mg_eav_attribute` WHERE `attribute_code` = "options_container"
In unserem Fall haben wir nun einen Eintrag der uns die attribute_id = 97 liefert und als default_value = „container2“, was wir uns ebenso merken da es der Standardwert der Optionsfelder ist.
Nun da wir unsere Shopinterne attribute_id kennen, wird in „mg_catalog_product_entity_varchar“ nach den zu beseitigenden Werten gesucht:
SELECT * FROM `mg_catalog_product_entity_varchar` WHERE `attribute_id` = 97 AND `value` = "container2" AND `store_id` != 0
Hier sollten nun alle fälschlich erzeugten Einträge kommen die Mutige mit folgendem sql aus der Table löschen:
DELETE FROM `mg_catalog_product_entity_varchar` WHERE `value` = "container2" AND `attribute_id` = 97 AND `store_id` != 0
Um alle Produkte zu finden die per Standardwert für alle storeViews also store_id = 0 immer noch nach der Artikelinformationspalte stehen läßt sich folgendes sql nutzen:
SELECT * FROM `mg_catalog_product_entity_varchar` WHERE `attribute_id` = 97 AND `store_id` = 0 AND `value` = "container2"
Falls obige Abfrage Ergebnisse erzielt, lassen sich mit UPDATE von value = „container1“ wieder für alle Produkte normale Layoutverhältnisse herstellen:
UPDATE `mg_catalog_product_entity_varchar` set `value` = "container1" WHERE `attribute_id` = 97 AND `store_id` = 0 AND `value` = "container2"
Um in Zukunft zu vermeiden dass sich selbiges Dilemma wiederholt, wird durch folgendes sql der Standardwert der Optionsfelder auf „Artikelinformationsspalte“ gesetzt:
UPDATE `mg_eav_attribute` set `default_value` = "container1" WHERE `attribute_id` = 97 AND `attribute_code` = "options_container"
Jetzt sollte auch unser ShopAdmin wieder etwas Farbe im Gesicht haben..
core.c3labs
