© saicle/Shutterstock.com
Module für PHP-basierte E-Commerce-Systeme schreiben

Blick in die Ladenwerkstatt


Wer ein Onlineshopsystem durch neue Module erweitert, erwartet, dass die eigenen Funktionalitäten mit einem Softwareupdate nicht überschrieben werden. Alles andere passt heutzutage eher in ein Kuriositätenkabinett als in ein modernes Softwarekonzept. Doch welche Möglichkeiten der Modulerweiterung gibt es konkret? Ein Vergleich zwischen den quelloffenen Versionen der drei populären Shopsysteme Magento, OXID eShop und Shopware soll zeigen, wie die deren Modulsysteme im Einzelnen aufgebaut sind und mit welchen Strategien sich eigene Funktionalitäten implementieren lassen.

Bei vielen Onlineshopprojekten fängt die eigentliche Arbeit erst nach der Installation der Standardsoftware an: Ein individuelles Template soll erstellt werden. Außerdem wird eine Preisberechnung benötigt, die die Software out of the Box nicht leisten kann; es fehlt zudem eine Schnittstelle zu einem Payment-Provider. Last but not least sollen auch noch spezielle Produktdaten in einem bestimmten Format importiert werden. Magento, OXID eShop und Shopware haben jeweils eigene Strategien, damit umzugehen.

Magento

Magento hat in den letzten Jahren für Furore gesorgt. Das Multishopsystem, das auf dem Zend Framework basiert, ist in vielerlei Hinsicht komplex, was sich vor allem in seinem Modulsystem widerspiegelt. Es wurde 2008 zum ersten Mal als produktiv einsetzbare Version unter der Open Software License (OSL) veröffentlicht. Charakteristisch für Magento ist der häufige Einsatz von XML zu Konfigurations- und Definitionszwecken und das Entity-Attribute-Value-(EAV-)Datenmodell. Darüber hinaus orientiert es sich stark am MVC-Design-Pattern. In den letzten Jahren machte Magento vor allem durch seine vollständige Übernahme durch eBay von sich reden.

zenner_modulerweiterung_abb_1.tif_fmt1.jpgAbb. 1: Die Verzeichnisstruktur von Magento

Applikationsstruktur

Beginnen wir damit, uns die Strukturen der Software genauer anzusehen, die für die Modulentwicklung von Bedeutung sind. Das ist vor allem das Verzeichnis /app/code/, in dem die meisten funktionsrelevanten Dateien liegen. Darin enthalten sind die Codepools /community, /core und /local, in denen sich in den jeweiligen Namespaces die Module verbergen. Die Ladereihenfolge local – community – core bedingt gleichzeitig auch den ersten Eingriffspunkt für etwaige eigene Erweiterungen: Im Namespace /app/code/core/Mage/<Modulname> verbergen sich, gekapselt in den jeweiligen Modulordnern, die Klassen der Applikation. Wird dieser Pfad repliziert – also beispielsweise /app/code/local/Mage/<Modulname>, werden aufgrund der Ladereihenfolge die Klassen innerhalb des /local-Baums anstelle der Core-Klassen verwendet. Das ist für schnelle Anpassungen und Tests empfehlenswert. Richtige Module sehen aber anders aus, wie sich weiter unten zeigen wird.

In /app/design/ ist der Großteil des Template-Systems zu finden. Außerdem relevant für das Erstellen eigener Module ist /app/etc/modules/, in dem zentrale Konfigurations-XML-Dateien liegen, mit deren Hilfe man eigene Module am System anmeldet. Weiterhin von Bedeutung ist das /skin-Verzeichnis, in dem die browserlesbaren Bestandteile der Applikation, also beispielsweise CSS- und JavaScript-Dateien, abgelegt sind. Die Funktion dieses Verzeichnisses entspricht im Wesentlichen der des /public-Ordners im Zend Framework. Es ist eine der wenigen Stellen der Anwendung, die nicht durch .htaccess-Dateien zugriffsbeschränkt ist.

Strukturell unterscheiden sich die Core-Module von Magento bis auf wenige Ausnahmen nicht von denjenigen, mit denen man das System erweitert. Das ist insofern angenehm, als man sich bei der Neuentwicklung daran orientieren kann. Im Folgenden ist die Struktur eines typischen Magento-Moduls anhand des Checkout-Moduls (Abb. 2) erklärt:

  • Block: Hier sind Block-Klassen abgelegt

  • Controller: eigene, abstrakte Controller-Klassen

  • controllers: Controller-Klassen der Extension

  • etc: Konfigurations-XML, z. B. config.xml

  • Helper: Helper-Klassen

  • Model: Models und Resource Models

  • sql: Install- und Update-Scripts

zenner_modulerweiterung_abb_2.tif_fmt1.jpgAbb. 2: Struktur eines Core-Moduls

Um zu verdeutlichen, wie ein Modul in Magento aufgebaut ist, werden wir Schritt für Schritt eine einfache Extension erarbeiten, die eine zusätzliche E-Mail versendet, sobald eine Bestellung abgeschickt worden ist. Dabei machen wir Gebrauch von Magentos Event-Observer-Funktionalität und binden die Ausführung unserer Erweiterung an das Eintreten eines vorher definierten Zustands in unserer Applikation.

Listing 1

<?xml version="1.0"?> <config> <modules> <PHPM_OrderEmail> <active>true</active> <codePool>local</codePool> </PHPM_OrderEmail> </modules> </config> 

Modul erstellen

Zunächst müssen Sie da...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang