Magento 1.4 Grundlagen: Ablauf eines Page-Requests

Um den Geschäftsanforderungen gerecht zu werden, muss beinahe jede Webshop-Installation angepasst werden. Als Entwickler ist man da versucht, sich gleich in die erste eigene Erweiterung und das erste eigene Modul zu stürzen. Bei Magento kann der Schuss jedoch schnell ins Knie gehen: es handelt sich um ein mächtiges, aber komplexes System, deren Eigenheiten und Fähigkeiten man kennen lernen sollte, bevor man eigene Erweiterungen erstellt.

Wir wollen hier die Basis dafür schaffen, indem wir uns mit der ersten wichtigen Frage beschäftigen: was passiert beim Aufruf einer Webseite in Magento 1.4?

Überblick

Kurz zusammengefasst besteht das Grundgerüst eines Seitenaufrufs in Magento aus diesen Schritten:

1. Anfragen werden über eine RewriteRule an index.php weitergeleitet.
2. index.php nimmt grundlegende Einstellungen & Überprüfungen vor und bestimmt, welche Website zum Zuge kommt. Dann wird Mage::run() aufgerufen.
3. Mage legt die Basis für das Event-Handling und die Konfiguration. Dann wird die Methode Mage_Core_Model_App::run() aufgerufen.
4. Mage_Core_Model_App bereitet die Umgebung vor, lädt die Konfiguration und den Cache. Dann wird die Anfrage durch den FrontController verarbeitet.

Sehen wir uns das genauer an.

1. Der Eintritt in die Anwendung: index.php

Magento basiert auf dem FrontController-Pattern. Alle Anfragen (Requests) werden also an einen zentralen Eintrittsort geleitet und dort vom FrontController verarbeitet. In Magentos Basisverzeichnis befindet sich die Datei .htaccess:  Anfragen werden dort an die Datei index.php in demselben Verzeichnis weitergereicht.

In index.php passiert Folgendes:

• Das Error-Reporting wird so eingestellt, dass alle Fehlermeldungen registriert werden. Magento verwendet einen eigenen Error-Handler, der für den Betreiber die Fehlermeldung sowie den Stack-Trace aufzeichnet und dem Shop-Kunden eine ansprechende Fehlermeldung präsentiert (soweit das bei Fehlermeldungen möglich ist ;)). Das Handling erfolgt seit Version 1.4 in errors/processor.php, Magento 1.3 verfügte noch über ein eigenes Verzeichnis report/.
• Falls vorhanden, wird die Konfigurationsdatei für die Kompilierung des Codes eingebunden. Unter Kompilierung ist in diesem Fall zu verstehen, dass die Geschwindigkeit des Shops durch die Reduzierung der Include-Pfade und das Zusammenlegen häufig benötigter Dateien in eine Datei gesteigert wird. Diese Funktion kann im Administrationsbereich unter „System“ -> „Tools“ -> „Compilation“ aktiviert werden und wurde mit Version 1.4 als „stabil“ gekennzeichnet (vorher befand sich die Funktion im „Beta“-Status).
• Die Basis-Klasse „Mage“ wird gesucht. Kann sie nicht gefunden werden, so gibt es ein Problem. Ist der Magento-interne Downloader vorhanden, so wird zu ihm weitergeleitet, damit er die Installation reparieren kann.
• Nun überprüft Magento, ob sich der Shop im Wartungs-Modus befindet. Dazu wird im Basisverzeichnis nach einer Datei „maintenance.flag“ gesucht. Ist sie vorhanden, wird als Antwort eine HTML-Seite mit der Meldung „Service Temporarily Unavailable“ und dem HTTP-Status-Code 503 ausgeliefert. So praktisch es ist, den Shop über das schlichte Erstellen einer Datei zu sperren, so unpraktisch ist es, dass man auch als Administrator keinen Zugriff auf den Shop mehr hat – denn bei Wartungsarbeiten ist das natürlich unerwünscht. Das Team von Inchoo hat einen Workaround gepostet, mit dem sich das Problem auf IP-Basis umgehen lässt.
• Die Basis-Datei „app/Mage.php“ wird geladen. Sie enthält den Code für bestimmte Basis-Funktionen und richtet den Auto-Loader ein. Zudem enthält sie die gleichnamige Basis-Klasse „Mage“, die das Bootstraping  am Ende der index.php fortsetzt und die Verarbeitung des Requests erst so richtig anstößt. Die Fähigkeiten von Mage abseits der Request-Abwicklung sehen wir uns im nächsten Posting dieser Serie („Magento 1.4 Grundlagen: Mage“) genauer an.
• index.php bietet weiters die Möglichkeit, den Profiler zu aktivieren, indem der entsprechende Befehl einkommentiert wird.

  65: #Varien_Profiler::enable();

  Der Profiler ist ein sehr praktisches Werkzeug auf der Suche nach Performance-Engpässen. Leider muss man in dieser Core-Klasse Veränderungen vornehmen, um die Funktion verwenden zu können. Warum das nicht über eine Server-Variable bewerkstelligt wird, ist mir unklar.

• Den Entwicklermodus kann man nämlich seit Version 1.4 über eben eine solche Server-Variable aktivieren. Dazu wird in der Webserver-Konfiguration oder in .htaccess die Variable MAGE_IS_DEVELOPER_MODE gesetzt. Der Wert ist egal.
• Für den Betrieb von MultiStore-Websites ist wichtig, dass man über Server-Variablen die StoreView bzw. die Website festlegen kann, unter der jeweiligen Domain betrieben werden soll. Nähere Informationen liefert der Beitrag „Setting up Magento with multiple websites or stores“ im Blog von Baobaz.

2. Der Vermittler: Mage

index.php ruft als letzte Aktion die statische Funktion Mage::run() auf. In dieser werden drei wichtige Bestandteile initialisiert:

• Mage_Core_Model_App: hier passiert die Magie. Darauf gehen wir gleich genauer ein.
• Varien_Event_Collection: Magento definiert an verschiedenen Stellen im Code so genannte „Events“ (häufig auch als „Hooks“ bezeichnet). Man kann Erweiterungen schreiben, die sich an diesen Stellen in das System einklinken und somit Verhalten des Shops modifizieren. Es handelt sich dabei um eine Implementierung des Observer-Patterns.
• Mage_Core_Model_Config: Die XML-basierte Konfiguration wird in dieser Klasse abgelegt. Wie sich zeigen wird, kann man von überall auf sie und damit auf die Konfiguration zugreifen.

Als letzte Aktion ruft Mage die Methode Mage_Core_Model_App::run() auf.

3. Die Magie: Mage_Core_Model_App

Endlich geht es ans Eingemachte:

• Die Umgebung wird vorbereitet,
• die Konfiguration geladen,
• Caches und Module werden initialisiert.
• Der FrontController wird erzeugt und aufgerufen, womit die Anfrage analysiert und verarbeitet sowie die Antwort zusammengestellt wird, die letztendlich ihren Weg zurück zum Shop-Kunden findet.

Um die weitere Abarbeitung des Requests anschaulich zu präsentieren, haben die Betreiber von Magento Xperts die ursprüngliche Graphik aus dem Magento-Wiki hergenommen, auf Deutsch übersetzt und graphisch aufgepeppt. Herausgekommen ist der „Workflow des Magento Page Requests“.

Wie ihr vermutlich wisst, verwendet Magento das Zend Framework als Grundlage für seine Architektur. Kein Wunder, dass wir in diesem Chart daher viele Bekannte wiederfinden:

• die Einteilung in Model, View und Controller (MVC),
• die Verwendung von Layouts und Template-Dateien (wenn auch der Ansatz gegenüber den Zend-Framework-Komponenten stark erweitert wurde) sowie View-Helpern und
• die von Zend propagierte Trennung in Models für die Geschäftslogik und der dahinter stehende Persistenz-Layer in Form von Resource-Klassen, welche auf Zend_Db basieren.

Fazit

Wir haben mit diesem Beitrag den ersten Schritt in die Magento-Welt gemacht. Jeder Aufruf im Webshop-Frontend geht die beschriebene Route ab. Somit haben wir schon eine erste Vorstellung davon, was wir im Ablauf ganz grundlegend bestimmen können. Natürlich haben wir gerade einmal an der Oberfläche gekratzt: im Hintergrund läuft noch viel mehr ab.

Der Aufbau der Konfiguration, die Erstellung der View mit Layout-XMLs und -Blöcken, die Rolle der Models usw. sind durch viele Blogs und Websites ausgezeichnet erklärt. Daher empfehle ich euch, dass ihr die Ressourcen nutzt und euch mit diesen Punkten vertraut macht. In den nächsten Beiträgen werden wir uns Basis-Klassen von Magento genauer ansehen, um dieses Verständnis zu vertiefen und zu sehen, welche nützlichen Funktionen uns das Schreiben von Extensions erleichtern können.