[Update 02.011.2012: ich habe das Beispiel-Modul Emzee_ExampleExtension online gestellt, das die Basis-Konfiguration für eine eigene Extension zeigt.]
Heute beschäftigen wir uns mit der Grundlage für die Erweiterungen, die ich hier vorstelle, nämlich mit der Frage: wie erstelle ich mein eigenes Modul in Magento? Ihr wundert euch vielleicht, warum ich jetzt damit ankomme, nachdem ich bereits einige komplexere Artikel veröffentlicht habe. Die Antwort: wie ich durch eure Rückmeldungen zu den Entwickler-Tipps erfahren habe, finden immer wieder Magento-Neulinge den Weg zu meinem Blog. Das freut mich, und nachdem ich weiß, dass der Einstieg in Magento verwirrend sein kann, greife ich gerne helfend unter die Arme. 😉
[toc levels=3 title=“Inhalt“]
Was sind Extensions / Module?
Zu aller Anfang: der Code von Magento ist in viele Module aufgeteilt, um trotz der vielen Dateien bestmögliche Übersichtlichkeit zu gewährleisten. Häufig werden die Module auch als Extensions bezeichnet (besonders wenn sie nicht direkt mit Magento ausgeliefert werden). Im Normalfall kann man davon ausgehen, dass damit das gleiche gemeint ist. Ich schreibe im Weiteren von Extensions und meine sowohl die Module von Magento als auch Erweiterungen, die man selbst entwickelt bzw. die von Drittanbietern bereitgestellt werden.
Der Name einer Extension setzt sich in der Regel aus zwei Teilen zusammen. Der erste Teil ist das Package. Das Prinzip ist das ähnliche wie bei einem Namespace (nicht mit Namespaces aus PHP 5.3 zu verwechseln): jede Agentur bzw. jeder Entwickler sucht sich einen eindeutigen Namen aus, unter dem sie ihre bzw. er seine Erweiterungen in die Welt trägt. Dadurch vermeidet man Konflikte mit dem Code anderer Entwickler. Magento selbst beansprucht das Package „Mage“ für sich.
Der zweite Teil ist der eigentliche Name des Moduls. Er sollte möglichst bezeichnend für das sein, was die Extension tut. Mitgelieferte Module heißen unter anderem CatalogSearch, GiftMessage, Payment oder Widget. Somit wird angezeigt, wofür der jeweilige Code verantwortlich ist.
Den vollständigen Namen der Extension erhält man, indem man die beiden Teile mit einem Unterstrich zusammenführt. Aus den obigen Beispielen werden somit Mage_CatalogSearch, Mage_GiftMessage, Mage_Payment und Mage_Widget.
Wo finde ich die Extensions im Dateisystem?
Die Extensions werden unterhalb des Verzeichnisses app/code/ abgelegt. Werft ihr einen Blick in das Verzeichnis, so findet ihr drei Unterverzeichnisse, welche die 3 Code-Pools von Magento bilden:
- community: hier legt man selbstentwickelte Extensions ab, wenn man plant, sie der Community (z.B. über Magento Connect) zur Verfügung zu stellen.
- core: dieser Codepool sollte Magento vorbehalten bleiben.
- local: hier erstellt man Erweiterungen, wenn sie zu projektspezifisch sind, um wiederverwendet zu werden bzw. wenn die Veröffentlichung der Erweiterung nicht geplant ist.
In der ersten Verzeichnisebene des Code-Pools tummeln sich die Namespaces und im darunterliegenden Verzeichnis die Modulnamen. Das Core-Modul Mage_CatalogSearch findet man daher in app/code/core/Mage/CatalogSearch.
Diese Konvention, laut der Unterstriche im Klassennamen im Dateisystem durch Verzeichnisebenen ersetzt werden, kennen die meisten PHPler übrigens aus PEAR – dessen Modell wurde in das Zend Framework übernommen und auf diesem basiert wiederum Magento.
Was brauche ich für eine eigene Extension?
Eine eigene Extension besteht aus drei Teilen: erstens aus dem Extensionverzeichnis, wie ich es oben beschrieben habe, zweitens aus einer Konfigurationsdatei im Extensionverzeichnis und drittens aus einer Konfigurationsdatei im allgemeinem Konfigurationsverzeichnis.
Das Extensionverzeichnis
Zu Beginn entscheiden man sich, ob die Erweiterung im Code-Pool „local“ oder „community“ zu finden sein soll. Gehen wir heute von einer lokalen Extension aus. Ich wähle als mein Entwicklerkürzel „Emzee“ und möchte eine Erweiterung des Bezahlvorgangs (Checkout) vornehmen. Daraus ergibt sich die lokale Extension Emzee_Checkout. Das dazu korrespondierende Verzeichnis, das wir erstellen müssen, lautet app/code/local/Emzee/Checkout.
Die Konfigurationsdatei der Extension
Innerhalb der Extension muss eine Konfigurationsdatei angelegt werden. Sie bildet die Basis, um Magento auf jegliche erdenkliche Art zu erweitern. Dazu erstellen wir die Datei app/code/local/Emzee/Checkout/etc/config.xml:
<?xml version="1.0" encoding="UTF-8"?> <config> <modules> <Emzee_Checkout> <version>0.0.1</version> </Emzee_Checkout> </modules> </config>
Hierbei handelt es sich um die Minimalversion der Konfigurationsdatei. Sie enthält lediglich den Namen der Extension sowie die aktuelle Versionsnummer. Die Versionsnummer anzugeben und gegebenfalls anzupassen ist wichtig, wenn man die Extension im Laufe der Zeit ausbaut. Dadurch ist es Magento erstens möglich, die Dateien der Extension automatisch auf den aktuellen Stand zu bringen und zweitens kann kann man als Entwickler Migrationsskripte erstellen, falls das Datenbankschema erweitert werden muss. Wird die Extension in einer Magento-Installation aktualisiert, dann werden diese Skripte automatisch ausgeführt.
Die Konfigurationsdatei zur Aktivierung der Extension
Momentan wird die Extension noch nicht von Magento erkannt. Um das zu ändern, muss eine weitere XML-Datei angelegt werden. Hierzu gehen wir in das allgemeine Magento-Konfigurationsverzeichnis app/etc/. Hier finden wir einen Unterordner app/etc/modules vor, in dem die Extensions registriert werden.
Wir legen hier die Datei Emzee_Checkout.xml an:
<?xml version="1.0" encoding="UTF-8"?> <config> <modules> <Emzee_Checkout> <active>true</active> <codePool>local</codePool> </Emzee_Checkout> </modules> </config>
Hiermit weiß Magento, dass ein Modul Emzee_Checkout existiert, das aktiv ist und im Code-Pool „local“ zu finden ist.
Wie man anhand der Datei app/etc/modules/Mage_All.xml sehen kann, ist es denkbar, viele Extensions innerhalb einer Datei zu definieren. In der Praxis bewährt es sich aber, zwecks besseren Überblicks pro Extension eine XML-Datei anzulegen und sie mit dem Namen der Extension zu versehen.
Schnellzusammenfassung
Die Grundlage für die eigene Extension schafft man mit den folgenden vier Schritten:
- Einen Namen für die Extension (bestehend aus Packageund Modulname) überlegen.
- Im Code-Pool local oder community die entsprechende Verzeichnisstruktur anlegen, zum Beispiel app/code/local/Emzee/Checkout/ für die Extension Emzee_Checkout.
- Innerhalb des Extension-Verzeichnisses die grundlegende XML-Konfigurationsdatei etc/config.xml anlegen, im Beispiel app/code/local/Emzee/Checkout/etc/config.xml:
<?xml version="1.0" encoding="UTF-8"?> <config> <modules> <Emzee_Checkout> <version>0.0.1</version> </Emzee_Checkout> </modules> </config>
- Magento die Extension bekannt machen, indem man im allgemeinen Konfigurationsverzeichnis die benötigte XML-Datei mit einem sprechenden Namen erstellt, zum Beispiel app/etc/modules/Emzee_Checkout.xml:
<?xml version="1.0" encoding="UTF-8"?> <config> <modules> <Emzee_Checkout> <active>true</active> <codePool>local</codePool> </Emzee_Checkout> </modules> </config>
Fazit
Diese Anleitung ist euer erster Schritt, um eigene Extensions anzulegen. Noch bewirkt die Erweiterung nichts, doch mit ein wenig Arbeit könnt ihr Controller erstellen oder erweitern, Navigationsmenüs bearbeiten (Top-Navigation, Footer, Benutzerkonto), eure eigene API veröffentlichen, neue Zahlungs- und Versandarten definieren, das Design ausbauen und noch vieles mehr.
Phänomenal! Sehr verständlicher Artikel für einen Anfänger wie mich, der sich mit der Magento-Materie erst seit kurzem beschäftigt. Der Kritik meines Vorredners kann ich mich auch anschließen, da dass durchaus nur das fundamentale Grundgerüst aufzeigt und nicht mehr. Dennoch großes Lob 😉
Hi, Matthias.
Ich muss eine kleine Kritilk los werden, aber vorerst Lob zu deinen insgesammt sehr aufklährenden Artikel bez. Magento, das doch ein komplexes Framework darstellt, ich weis es, da ich als Magento-Developper spec. im Backend-Bereich schon länger fungiere. Ich würde sagen das dieser Artikel sehr gut beschreibt, wie man ein Modul/Extension „registriert“ oder „bekannt macht“, aber da fehlt eigentlich immer noch die Funktionalität und wo diese greift, im Admin-Panel oder eher im Shop-Frontend nach dem man es im Admin-Panel aktiviert hat.
Zumindest noch ein controller-Directory sollte erstellt werden mit einer Php-Datei die sagen wir mal:
echo ‚my first modul‘ ausführt, um die Sache zu kompletieren.
Dann hat man eine nette Ausgabe, was zum sehen. Mir ist völlig klahr, das man natürlich nicht alles erklären kann und ab da, absolut Fit in Sachen Software-Engineering und Desing-Patterns, wie auch Zend-Framework sein muss und man hier nur auf weitere Artikel und Bücher leiten kann, denn ohne Kenntnisse mindestens in Mvc-Patterns, deren implementierung im Zend-Framework ( Voraussetzung zum verstehen, wie diese wiederum in Magento implementiert wurden – konfigurationbasiertes Mvc, wieder ein Tick powervoller ) kann man auch kein valides Modul im Magento-Software-Design implementieren. Ein leidiges Thema für viele Webdesigner die mal etwas mit Joomla, etwas mit Oscommerce usw. lange Zeit hantierten und dann bei Magento-Projekten untergiengen. Anderes erlebtes Beispiel: Ein jahrelanger Java-Entwickler hat unglaublich schnell in Magento reingefunden und quasi durchgestartet, bei Java-Programmierer ist der Schwerpunkt im allgemeinen auf Design-Patterns aller Arten, ich will damit andeuten, das Magento eigentlich eine professionelle, durch und durch software-engineerisch gut designte Software ( Webware ) ist.
Hi Dennis, danke für deine Anregung. Ich habe den Artikel geschrieben, um bei anderen Posts auf dieses Grundgerüst zu verweisen und das nicht jedes mal wieder schreiben zu müssen. 😉 Deswegen lege ich keinen „Hello World“-Controller an. Du hast Recht, dass der Controller für ein richtiges „Hello World“-Beispiel sinnvoll wäre.
Eine wirklich super einfache und verständliche Anleitung – weiter so. Es ist – gerade für Magento-Einsteiger – zum Teil sehr schwer, da es nur sehr wenige gute und verständliche Anleitungen wie diese zu den verschiedensten Themen rund um Magento gibt.
Danke für die netten Worte!
Hi Matthias, obwohl ich schon über 10 Jahre ( oder mehr ?? ) in diversesten Perl, Php Bereichen Entwickle, muss ich sagen das Magento eine ziemlich umständliche Story ( geworden ) ist. Ich vergleiche gerne mit anderen genauso hochwertigen ( was Magento trotz der Komplexität ist ) Shopsystemen wie Interchange in Perl programmiert u.ä. Ich finde diesbezueglich das deine Erklährungen viel Licht ins dunkle bringen ( liest sich gut ), allerdings würde ich zu diesem Thema vielleicht noch eine Kurbeschreibung machen, wie man den auf so ein selbst erstelltes Modul von einer beliebigen „.phtml“-Datei zugreift bzw. wann diese in den „$this->“ Klub mit eintritt. Ansonsten finde ich deine Website wirklich, sehr, sehr informativ.
Hi Denis, danke für das Lob und die Anregung. Ich werde versuchen, demnächst etwas darüber zu schreiben.
Hallo Matthias,
vielen Dank für den super Einstieg in die Welt der Magento Extensions!
Ich habe noch eine technische Frage. Kann ich den Code meiner Extension verschlüsseln, sodass er Kopier-geschützt ist?
Vielen Dank!
Ima
Hallo Ima,
es gibt Encoder wie ionCube, mit denen man PHP-Code verschlüsseln kann. Ich rate jedoch davon ab. Möchtest du eine Extension verkaufen, so schreckst du damit viele potentielle Kunden ab. Ich denke, dass du damit mehr Umsatzverlust erleidest als wenn potentiell ein paar Kunden die Extension mehrfach verwenden/weitergeben. Tust du das aus Sicherheitsbedenken, sollte es auch hier andere Möglichkeiten.
Matthias
Hallo,
vielen Dank erst mal, jetzt ist mir klar geworden, wie ich meine erste Extension als Magento-neulinge erstellen kann. Also besser konnte man nicht erklären.
Besten Dank!
Musti
Hallo Musti,
danke, das freut mich. Viel Erfolg beim Erweitern!
Hallo!
Perfekt … somit passe ich das Template an und setzte den Status der Bestellung abhängig davon was geschehen soll z.B. „pending“, „cancelled“
Besten Dank!
hi!
danke nochmals für die ausführliche Erklärung des Bugs auf stackoverflow!
Meine Frage zu diesem Artikel : Kann man mit Modulen, Extension oder wie man diese in jenem Fall dann nennen mag, auch beispielsweise das Mage_Checkout-Modul „überschreiben“. Konkret möchte ich anstatt den Standard-Checkoutprozess zu durchlaufen, lediglich die Möglichkeit anbieten Produkte zu reservieren. Sprich einfach eine „Order“ erstellen und „Invoice“ und „Shippment“ überspringen. Ist dies überhaupt möglich.
Besten Dank
Fritz
Hi!
Du kannst das Checkout-Modul auf jeden Fall anpassen. Wie aufwändig das ist, hängt – natürlich – davon ab, wie stark der Bestellprozess geändert werden soll.
Gehen wir davon aus, dass
* die Schritte im Bestellfortschritt vorhanden bleiben (Rechnungsadresse, Versandadresse etc.),
* man eine Pro-Forma-Bezahlmethode verwendet (sprich: an dieser Stelle noch nichts über Drittanbieter abgebucht wird) und
* im Prinzip nur Bezeichnungen angepasst werden (z.B. „Reservieren“ statt „Bestellen“),
dann ist der Aufwand ziemlich gering.
Standardmäßig löst der Kunde zuerst nur einen Auftrag aus (Order) und die Rechnung (Invoice) bzw. Lieferung (Shipment) erzeugt der Händler über das Backend. Somit kann man steuern ob, Invoice und Lieferung „übersprungen“ werden.
Müssen Schritte im Checkout-Prozess wie die Adresseingabe, die Bezahlmethode etc. übersprungen oder andere größere Anpassungen vorgenommen werden, dann kann es jedoch aufwändiger werden.
Hi Matthias,
vielen Dank erstmal, ich habe schon viele nützliche Infos in deinen Artikeln gefunden 🙂
Zu diesem Artikel habe ich vielleicht noch eine sinnvolle Ergänzung (bzw. könntest Du noch einen kleinen Absatz ergänzen). Vor allem für blutige Anfänger wie mich, die sich fragen „was mach ich da überhaupt“, ist der Übergang von XML zu php eine große Hilfe 😉
This will allow usage of $obj = Mage::getModel(’example_mod/test_model’) and will return an instance of the class Example_Module_Model_Test_Model, located in app/code/local/Example/Module/Model/Test/Model.php. As you can see, example_mod is replaced with Example_Module_Model and together with test_model generate name of required class.
(aus: Magento Wiki – Customize Parts Of Magento Configuration. Bsp. für Example_Module anstatt wie hier Emzee_Checkout)
Hi Stefan,
danke für den Tipp! Das wäre vielleicht sogar einen eigenen Artikel wert, damit die Information nicht untergeht. 😉
lg Matthias
Danke für diesen guten Blogpost. Sehr verständlich erklärt 🙂 Überhaupt finde ich, dass sich deine Artikel sehr gut lesen lassen. 🙂 Das bringt mich als TYPO3-Fuzzie der für mich bisher relativ unlogischen Magentowelt doch ein ganzes Stück näher. 🙂
Gruß Björn
Hallo, das freut mich, danke! 🙂
lg Matthias
..ich finde Du hast die Vorgehensweise sehr gut erklärt. Ich habe schon einige Blog-Post zum Thema gelesen, aber nirgends war für mich bisher die Namensgebung (Abhängigkeiten) so gut erklärt.
Nun stellt es für mich kein Problem mehr dar, eigene Erweiterungen sauber abzulegen.
Manchmal müssen auch einfache Dinge sauber erklärt werden 😉
Vielen Dank!
Das freut mich – ich bin mir nämlich nicht immer sicher, ob meine Erklärungen so klar ‚rüberkommen, wie ich es gerne hätte. 😉
Viel Erfolg beim Umsetzen!