Das Magento-Logo

Ich bin im Moment auf den letzten Metern eines Projekt auf Basis der E-Commerce-Plattform Magento. Zunächst das Positive: Man kann als Designer in die Vollen gehen und wirklich fast jeden HTML-Schnipsel den eigenen Bedürfnissen anpassen. Und es sieht Out-of-the-box mit seinen vielen Funktionen und seinem ganzen Ajax-Krempel und sehr sexy aus. Und es gibt auch schon eine ganze Latte an Büchern über das gute Stück. Und es basiert auf dem etablierten Zend-Framework. Obendrein hat mal irgendein Red-Hat-Heini gesagt I’ve never seen another ecommerce platform so well architected and well designed as Magento Was kann da schon schiefgehen?

Nun gab es ja im Laufe der Jahre so manches Tool, von dem man sich viel anfangs versprach und sich dann als mehr so mitteleffektiv erwiesen hat. Beispielsweise weil es zwar auf dem Papier was hermachte, dann aber so ernorm viele Ressourcen verschlang, dass man sich hinterher wünscht, man hätte die Finger davon gelassen. Magento besteht aus knapp 1000 Dateien mit mehr als 200.000 Zeilen Code. Einige dieser Dateien gehören zum Template-System und haben dann solchen Inhalt. Da hat ja auch durchaus auch jede Zeile so ihre Daseinsberechtigung (nehme ich jedenfalls an), aber es ist dann doch manchmal schon einfach recht viel und es ist nicht immer übersichtlich. Manchmal muss man ganz schön suchen. Meistens. Die meiste Zeit. Ich jedenfalls.

Denn wenn man die entsprechenden Ressourcen übrig hat (zu denen man, wenn man einigermaßen erträgliche Performance erreichen möchte, einen eigenen Server zählen sollte), muss man noch wissen wie man das Tool richtig zum Einsatz bringt – sonst baut man nur Blödsinn. Und da wäre dann ja Dokumentation ganz hilfreich. So hat zum Beispiel obriges Code-Beispiel einen Kommentar (der einzige neben dem Abschnitt über die Lizenz) in dem @see Mage_Catalog_Block_Product_Abstract empfohlen wird. Also navigieren wir zu der Datei /app/code/core/Mage/Catalog/Block/Product/Abstract.php, wo man uns dann umfassend über den Sinn und Zweck der diversen Funktionen informiert:

/**
 * Enter description here...
 *
 * @param Mage_Catalog_Model_Product $product
 * @return string
 */

Zuerst dachte ich, dass meine Verwirrung einfach daher kommt, dass ich nicht smart genug für Magento bin. Andererseits, Leute mit bedeutend mehr Ahnung von PHP scheinen ähnlich verwirrt zu sein wie ich. Da heißt es dann kurz und knapp Magento ist scheisse oder, etwas bedächtiger formuliert if that is what RedHat calls good software architecture and design, I’d better refrain from using any RedHat software in the future. Die Slides aus dem letzten Link sind durchaus ansehenswert.

Ich bin weder Zend-Experte noch ein ausgemachter PHP-Nerd allgemein, aber wenn ich die Core-Datei für den Output von CMS-Seiten hacken muss, damit dort die Warnungen an der gleichen Stelle angezeigt werden wie in meinem restlichen Template … bin ich dann derjenige der was falsch gemacht hat? Das ist doch eigentlich nicht der Sinn von MVC, oder? Ich weiß es nicht. Was ich aber als Frontendentwickler mit einiger Gewissheit kommentieren kann, ist der Einsatz von Javascript bei Magento. So findet man beispielsweise im Code des Blank-Themes, also der offiziellen Vorlage für neue Shopdesigns, sehr oft derartiges:

<button type="button" class="button" onclick="productAddToCartForm.submit()"><span><?php echo $this->__('Add to Cart') ?></span></button>

Wenn Javascript aus ist, funktioniert das natürlich nur bedingt. Das mag jetzt ja vielleicht angesichts von dem müden einen Prozent JS-freier Surfer mehr oder minder nebensächlich sein (ich sehe das nicht so) aber mich verblüfft einfach die völlige Sinnlosigkeit dieser Konstruktion. Warum sollte man das so machen? Warum keinen Submit-Button?

Wobei das da eigentlich noch kein Problem ist. Wenn man ein neues Template baut, kann man solche Teile ja entfernen. Schwieriger wird es dann, wenn man konfigurierbare Produkte hat (sowas wie die Auswahl einer Kleidungsgröße). Da werden dann eben die entsprechenden Select-Elemente gefüllt, indem irgendwo im Template per PHP JSON geprintet wird, das von Javascript dann in Option-Elemente verwandelt wird. Auch hier: das kann man ja gerne so machen (wenn einem Zugänglichkeit und so egal sind), aber... warum? Das nützt doch niemandem. Wer hat was davon, wenn man ohne Javascript sein Kundenpasswort nicht ändern kann?

Ich wäre vielleicht schlauer, wenn ich jemanden hätte der mir diese Fragen beantworten kann. Das Problem ist nur, dass im Forum von Magento so wenig los ist, dass da niemand ist, der einem antworten könnte. Das Wiki ist ist auch eher dünn und der offizielle Designer's Guide, der eigentlich – so würde man vermuten – Webworkern bei der Umsetzung von Designs helfen soll, besteht im wesentlichen aus OMG UNSER TEMPLATE-SYSTEM IST SOOOOO TOLL!!!!!111. Entschuldigung, aber das ist Masturbation, nicht Dokumentation. Erklärt wird da nicht so viel. Oder wenn da was erklärt wird, ist es mir nicht aufgefallen oder hat es mir nicht geholfen – ich habe alles, was ich heute über Magento weiß (und das ist dann doch mittlerweile einiges) durch Suchen und Probieren herausfinden müssen.

Ich möchte meine Ausführungen mit einem Zitat aus der Datei /app/code/Mage/Core/Model/Url.php schließen und ausdrücklich die Möglichkeit einräumen, dass ich einfach nicht schlau genug für Magento bin.

/**
 * All system params should be unseted before we call getRouteUrl
 * this method has condition for ading default controller anr actions names
 * in case when we have params
 */

Aber es kann natürlich auch sein, dass man aus einer Reihe von Gründen die Finger von diesem Stück Software lassen sollte.