Blick in die Ladenwerkstatt

Module für PHP-basierte E-Commerce-Systeme schreiben
Kommentare

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 Onlineshop-Projekten 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-Designpattern. In den letzten Jahren machte Magento vor allem durch seine vollständige Übernahme durch eBay von sich reden.

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/ verbergen sich, gekapselt in den jeweiligen Modulordnern, die Klassen der Applikation. Wird dieser Pfad repliziert – also beispielsweise /app/code/local/Mage/, 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 sind.

Weiter mit: Teil 2

Alle Teile: Teil 1, Teil 2, Teil 3, Teil 4, Teil 5, Teil 6, Teil 7, Teil 8, Teil 9, Teil 10

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -