Kurzer Überblick
Mit der Version 4.4.8 endete eine nicht ganz abgegrenzte Epoche des Oxid-Systems. In den Versionen danach kamen ein neues Template (Azure) und im Laufe dieses Jahres auch noch das neue Modulmanagement.
Hinsichtlich der Templates ist eine neue Verzeichnisstruktur nach zubauen. Selbst diejenigen, die sich nicht so weit vom Standard entfernt haben und bislang beispielsweise das Basic-Template als Ausgangsgrundlage ihrer Arbeiten benutzten, werden keine Freude damit haben, jede Datei einzeln anzufassen und gemäß Template-Änderungsdatei neu zusammenzubauen. Effizienter kann man wahrscheinlich arbeiten, wenn man von Grund auf neu beginnt und die Abweichungen nachbaut oder, wenn möglich, ins neue Template reinkopiert.
Wer jetzt eine Oxid-Version der Versionen vor 4.5 auf die aktuelle Plattform (derzeit 4.6.3) heben möchte, hat an zwei Punkten anzusetzen:
- Module müssen portiert werden
- Sind die Module fertig, muss das Template neu gebaut werden
In diesem Beitrag möchte ich einige Dinge ansprechen, die vor allem für diejenigen interessant sein dürften, die den großen Sprung noch vor sich haben.
Neuerungen des Modulmanagements in Kürze
Das Oxid-Shopsystem hat seit der Version 4.6 ein neues Modulmanagement an Bord, das zahlreiche Vorzüge gegenüber älteren Versionen bietet.
- Automatische Deaktivierung von Modulen, die “abstürzen”: Der Shop funktioniert auch weiterhin, wenn ein Modul ausgefallen ist.
- Kein manuelles Editieren der Registrierungseinträge im Stil von ‘klasse’ => ‘modulpfad/modul’;.
- Aktivieren und Deaktivieren von Modulen mit nur einem Klick. Es ist kein manuelles Auskommentieren der jeweiligen Einträge mehr vonnöten. Außerdem wird immer nur das gerade gewählte Modul und nicht alle Erweiterungen für bestimmte Views deaktiviert.
- Ändern der Reihenfolge. Wird eine Klasse mit mehreren Modulen erweitert (ganz häufig: oxviewconfig), kann die Reihenfolge schon mal eine Rolle spielen. Früher wurden die Einträge mit dem &-Zeichen verknüpft, jetzt ist das Festlegen der Reihenfolge per Drag & Drop möglich.
Dadurch, dass die Modulverwaltung jetzt komplett über eine grafische Benutzeroberfläche gesteuert werden kann, ist kein Bearbeiten mehr in einer Textarea notwendig, in der Klassen per Tastatureingabe erweitert wurden. Hier genügte zuvor schon ein Tippfehler an der falschen Stelle und der Shop wurde lahmgelegt.
Anforderungen an Module
In diesem Beispiel gehen wir davon aus, dass ein Modul, bestehend aus Erweiterungen für die Views details und start, portiert werden soll.
Damit selbst geschriebene oder alte Module im neuen Oxid-System funktionieren, müssen sie mit einer metadata.php genannten Datei ergänzt werden. Diese Datei enthält – vereinfacht gesagt – Konfigurationseinstellungen, die zuvor eingegeben werden mussten.
Diese Datei enthält in jedem Fall:
- ID – das Modulverzeichnis
- Name
- zu erweiternde Klassen (als Array im Array)
Das kann in seiner einfachsten Form so aussehen: