Diese letzten zwei Wochen hatte ich das “Vergnügen” zwei Magento Shops auf die Version 1.9 der Enterprise Edition zu hieven. Ich möchte hier einige Erfahrungen zusammenfassen.

Die neue Version enthält nicht mehr den mit in Version 1.8 eingeführten verschlüsselten Code. Es muss also kein IonCube Encoder Modul mehr auf allen Plattformen installiert werden. Man hat also bei Varien (oder wie es neuerdings heißt Magento Inc.) festgestellt, dass der eingeschlagene Weg schlecht war und die Entwickler und Administratioren einfach nur genervt hatte.

Magento kämpft immer wieder um Performance. Bei mittelgroßen Systemen mag die Performance eines einfachen Root-Servers noch ausreichen. Im Enterprise Bereich wo die Begriffe Cluster, Load Balancing, etc. eine Rolle spielen muss man einfach sagen ist Magento zu langsam. Aus diesem Grund führt die neue Version einen Full-Page Cache ein. Allerdings keinen wirklichen, dess es gibt doch noch eine Menge Dynamik in der Seite. Der neue Cache teilt die Webseite in dynamische und nicht dynamische Bereiche ein. Über eine cache.xml die in jedem Modul liegen bekommt Magento mitgeteilt wie es einen Block im Layout behandeln soll. Jedem Block kann ein eigenes Cache Model zugewiesen werden da z.B. eine Kategorie anders als ein persönlicher Begrüßungstext zu handhaben ist. Das hört sich auf den ersten Blick gut an. Allerdings zeigt die Praxis, dass man nun noch weniger versteht was im System passiert. Der Block selbst könnte ebenfalls noch vom Standard-Block-Caching gecached sein. Eine Dokumentation fehlt wie immer. Man muss sich das Wissen durch Durchsichten des Codes aneignen. Das kann so nicht sein. Ein System mit >1 Mio. Zeilen Code kann nicht jedes mal neu gesichtet werden.

Ebenfalls neu ist ein Manager für Kunden- und Kunden-Adress-Attribute. Es lassen sich jetzt analog zum gewohnten Anlegen z.B. bei den Produkten die Attribute direkt über eine GUI anlegen. Das klingt auch wieder schön. Der negative Part (und mal wieder nicht in einer einzigen Zeile erwähnt) ist, dass vorher über die API von Magento angelegte Attribute nicht richtig migriert werden. Die Attribute werden dann zwar im neuen Manager angezeigt. Allerdings kann man nicht speichern. Und was noch besser ist… sind Attribute z.B. im Checkout eingebaut, dann werden diese nicht mehr gespeichert und zwischen Quote / Adressen usw. weitergereich. Es sind nämlich jetzt mindestens 5 Tabellen im Spiel in denen nun Daten fehlen da nicht korrekt migriert wurde. Die Attribute müssen nun einzelnen Formularen mit Elementen und Fieldsets zugewiesen werden (gilt nur für die Enterprise Editon).

Die Lösung des Problems ist auf Datenbankebene die Attribute zu bearbeiten und zwar die Spalte “is_used_definied” in der Tabelle “eav_attribute”.
Dies kann auch gerne über ein Update Script eines eigenen Moduls geschehen. Danach ist das Speichern über den neuen Manager möglich und Magento erstellt die notwendigen Einträge in einen Tabellen. Das Speichern im Checkout funktioniert dann ebenfalls.

Umgestellt wurde auch die Speicherung der Bestellungen. Diese sind nun komplett flach. Das heißt, das man sich ebenfalls um die Anlage seiner Attribute die in den Bestellungen hinzugefügt wurden selbst kümmern muss. Das wird wie erwartet nicht von Magento übernommen.
Besonders schön ist, die nicht eingehaltene Abwärtskompatibilität. Warum kann man etwas nicht fertigstellen und dann auf den Markt werfen? Oder alte Features wenigstens für einen Release als Deprecated markieren? Immerhin bietet PHP die Möglichkeit mittels des Werfens einer E_DEPRECATED Warnung.

Abwärtskompatibel? Das sieht anders aus!

Eine Bitte an Magento: Nicht nur neue Features auf den Markt werfen sondern auch mal was dokumentieren.

Es kann doch nicht sein, dass man es nicht hinbekommt einen Migration Guide für die Entwickler bereitzustellen in dem die groben API Änderungen enthalten sind.