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:

1. Module müssen portiert werden
2. 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.

1. Automatische Deaktivierung von Modulen, die “abstürzen”: Der Shop funktioniert auch weiterhin, wenn ein Modul ausgefallen ist.
2. Kein manuelles Editieren der Registrierungseinträge im Stil von ‘klasse’ => ‘modulpfad/modul’;.
3. 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.
4. Ä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:

$sMetadataVersion = ‘1.0’;
$aModule = array(
‘id’ => ‘acki_demo’,
’title’ => ‘Demo-Modul’,
’extend’ => array(
‘start’ => ‘acki_demo/views/acki_start’,
‘details’ => ‘acki_demo/views/acki_details’,
),
);

Diese Datei ist im Verzeichnis des Moduls abzulegen, zum Beispiel, vom Wurzelverzeichnis des Shops aus gesehen in /modules/acki_demo/metadata.php.

Hier wird auch klar, warum in Zukunft nur noch ein Verzeichnis für genau ein Modul genutzt werden muss. Die Modul-ID ist gleich dem Verzeichnis, in dem es sich befindet. Es ist also nicht sinnvoll, alle Module eines Anbieters in einem Verzeichnis zu gruppieren, sondern sie nach Zweck “einzupacken”.

Die eigentlichen Moduldateien, also die Erweiterungen für View- und Core-Klassen (sofern vorhanden) können direkt in das Modulverzeichnis – oder besser: in Unterverzeichnisse gelegt werden. Sie können diese Unterverzeichnisse gruppieren, zum Beispiel in /views, /core und sogar /cmp, wenn Sie Komponenten erweitern. Vergessen Sie nicht in der metadata.php, die Pfade ausgehend vom Verzeichnis /modules anzugeben.

Was Sie alles in der Datei metadata.php angeben können, erfahren Sie im Oxid-Wiki. Sie können – müssen aber nicht – Informationen zum Modulherausgeber, eine Kurzbeschreibung, ein Logo, Blöcke und sogar Templates angeben.

Templates in Modulen angeben

Die Datei metadata.php erlaubt das Angeben von Modulen, was meiner Meinung nach aber nur für Module des Shop-Admins sinnvoll ist. Diese Templates Ihres Shop-Themes lassen Sie am besten auch weiterhin im Theme-Verzeichnis liegen unter /out liegen. Die in der metadata.php angegebenen Pfade gelten nämlich immer vom Verzeichnis /modules ausgehend.

Da sich die Templatestruktur auch geändert hat, sind in den View-Klassen die Werte für Variablen wie $_template oder $_sThisTemplate anzupassen, die dann von der render()-Methode zurückgegeben werden. In einem anderen Modul, das neue Methoden für die Bezahlseite bereitstelle, würde

protected $_sThisTemplate = ‚acki_payment.tpl‘;

zu

protected $_sThisTemplate = ‚page/checkout/acki_payment.tpl‘;. Mehr hierzu im letzten Abschnitt dieses Beitrags.

Portierte Module aktivieren

Bis zu diesem Punkt mag die Modulportierung aufwendig wirken, aber bereits mit ein wenig Routine benötigen Sie für weitere Module nur wenige Minuten. Wenn Sie so weit sind, können Sie Ihre Module aus dem Abschnitt “Erweiterungen” => “Module” heraus aktivieren.

Damit wäre die Modulportierung abgeschlossen. Jetzt können Sie sich an die Templatearbeiten machen.

Ein paar Worte zur Templatestruktur

Oxid hat mit dem Umstieg auf die Version 4.5 die Verzeichnisstruktur der mitgelieferten Templates bereichsorientiert strukturiert. So befinden sich alle Templates, die aus View-Klassen beliefert werden, im Unterverzeichnis /page. Dieses Verzeichnis wurde wiederum gegliedert in solche Bereiche wie zum Beispiel (Auswahl!):

• shop – allgemeine Shop-Seiten, zum Beispiel das Startseiten-Template
• list – Kategorielisten
• details – Detailseite, ggf. Anhängsel wie morepics.tpl, wenn man möchte
• account – alle Templates für den Bereich “Mein Konto”
• checkout – alle Templates für den Bestellprozess

Einmal coden, mehrfach verwenden

Wer sein Template größtenteils neu bauen muss, hier noch ein Tipp: schreiben Sie mehrfach verwendete Code-Schnipsel einmal und binden Sie sie in anderen Templates ein. Wenn Sie beim Aufbau vom Template Basic ausgehen, können Sie zum Beispiel die Formularfelder für die Rechnungs- und Lieferadressen so aufbauen, dass Sie sie gleich an drei Stellen per [{include file=’…’}] einbinden können: auf der Registrierungsseite, im Bestellprozess im Abschnitt “Adressen” (cl=user) und im Bereich mein Konto (cl=account_user). In Standard ist das nicht der Fall. Auf diese Weise sparen Sie sich unnötiges Kopieren von Code und behalten übersichtliche Templates.