In der aktuellen OXID Version 4.6.x hat sich die Handhabung von Modulen, also eigenen Erweiterungen für den OXID eShop, etwas geändert. Module können nun über den Menü-Eintrag “Erweiterungen / Module” im Admin installiert werden (nachdem sie vorher wie gehabt per FTP in das “modules”-Verzeichnis hochgeladen wurden – hier gibt es leider noch keinen Upload von Zip-Files o.ä., aber das kommt hoffentlich noch in einer der nächsten Versionen).

Zentrale Voraussetzung für diese neue Installations-Fähigkeit von Modulen ist eine zusätzliche PHP-Datei mit Meta-Informationen namens “metadata.php”, welche im Hauptverzeichnis des Moduls liegen muss. Hintergrund-Informationen zu dieser Datei finden sich unter http://wiki.oxidforge.org/Features/Extension_metadata_file.
Wichtig hierbei ist v.a., dass eine eindeutige, gültige “id” definiert wird, die auch dem Namen des Modul-Verzeichnisses entspricht und dass alle eigenen, zusätzlichen Klassen im “files”-Array sowie alle verwendeten Modul-Klassen im “extend”-Array eingetragen werden. Das manuelle und damit oft fehleranfällige Eintragen von Modulen unter “Grundeinstellungen / System” im Admin entfällt damit, der Shop holt sich die Infos nun aus diesem “extend”-Array.
Die Reihenfolge der Module kann bequem per Drag&Drop geändert werden, danach müssen allerdings die Einstellungen per Button gespeichert werden, was man gerne mal vergisst

Alle eigenen, zusätzlichen Klassen, können damit nun auch innerhalb des Modul-Verzeichnisses liegen und müssen nicht mehr in den Shop selbst (z.B. in die Shop-Verzeichnisse “admin” oder “core”) kopiert werden. So ist eine saubere Trennung von Shop-Core und eigenen Dateien gewährleistet. Man kann also z.B. folgende Struktur anlegen:

Nutzt man wie hier noch einen “Vendor”-Ordner (im Beispiel “shoptimax”), so muss in diesem Order eine (aktuell noch leere) Datei “vendormetadata.php” liegen, damit der darunterliegende Modul-Ordner korrekt erkannt und automatisch eingelesen wird.

Spezielle Einstellungen für Module können über das “settings”-Array in metadata.php automatisch angelegt werden, müssen diese lokalisiert werden, so kann man dafür eine eigene Sprachdatei anlegen, z.B. “modules/yourmodule/out/admin/de/module_options.php”, siehe auch http://article.gmane.org/gmane.comp.php.oxid.general/1776.

Nach wie vor obligatorisch und technisch unverändert ist eine “menu.xml”-Datei nötig, die im Modulverzeichnis liegen muss und die dem Shop sagt, an welcher Stelle in der Admin-Navigation Menüpunkte für das Modul eingefügt werden sollen usw.

Wichtig für Template-Erweiterungen ist, dass zusätzliche Sprachdateien nicht in “out/<template_name>/de/” usw., sondern im “globalen” “lang”-Ordner, also z.B. “out/lang/de/” liegen.

Ein Bug ist im Moment noch, dass eigene AJAX-Popups für den Admin, die in der Regel für Zuordnungen von Objekten genutzt werden, nicht automatisch innerhalb des Modul-Ordners gefunden werden (siehe Bug-Eintrag unter https://bugs.oxid-esales.com/view.php?id=4037 und Diskussion in der Mailing-Liste unter http://article.gmane.org/gmane.comp.php.oxid.general/1790). Hier ist entweder ein eigener Fix nötig (z.B. eine Art Autoloader in functions.php) oder man muss diese Dateien nach wie vor in das entsprechende Shop-Verzeichnis kopieren (“admin/inc”).

Was leider noch fehlt ist das automatische Ausführen von SQL-Scripts, welche für die Installation gebraucht werden, aber auch hier will OXID wohl noch nachbessern.

Alles in allem ein Schritt in die richtige Richtung – wir sind gespannt, wie es mit der Modul-Verwaltung weitergeht!