/application/admin/

Darin ist die Weiterleitung zum Backend des OXID eShop enthalten.

/application/components/

Das OXID-Framework sieht Klassen vor, die nach dem sogenannten Decorator-Entwurfsmuster aufgebaut sind. An dieser Stelle sind sie zu finden.

/application/controllers/

Die Controller der Applikation sind hier zu finden.

/application/models/

Alles was zum Thema Datenschicht – gemäß MVC-Modell – zu finden ist, ist in diesem Verzeichnis gekapselt.

/application/translations/

Übersetzungsdateien werden – unterteilt in die jeweiligen Sprachverzeichnisse – hier hinterlegt.

/application/views/

An dieser Stelle wird die View-Schicht in Form der Themes abgelegt (siehe Kapitel 1).

/bin/

OXID erlaubt es, gewisse wiederkehrende Aufgaben oder Preisänderungen (siehe Kapitel 3) zeitgesteuert über Cron-Jobs zu automatisieren. Bislang wird ein Cron-Job mitgeliefert. Diesen finden Sie hier.

/core/

Im Verzeichnis /core/ finden Sie alle Klassen, die zur grundsätzlichen Funktionalität des OXID-Frameworks benötigt werden.

/export/

Der OXID eShop kann out-of-the-box verschiedene Exporte anstoßen, beispielsweise von Kunden- und Bestelldaten. Das Exportverzeichnis ist der Ort auf dem Server, in den diese Dateien standardmäßig geschrieben werden.

/log/

In dieses Verzeichnis werden die Logdateien geschrieben, die die Applikation produziert. Es ist die erste Anlaufstelle, sollten Sie Probleme mit Ihrem System haben.

/modules/

Dieses Verzeichnis wird Ihnen im Verlauf der Lektüre dieses Buchs noch öfter begegnen. Wie der Name schon ahnen lässt, werden hier individuelle OXID-Module abgelegt.

/out/

Dieses Verzeichnis enthält die Dateien, die von außen – d. h. vom Browser – lesbar sind, und übernimmt damit die Rolle des /public/-Verzeichnisses etwa beim Zend Framework. Im OXID eShop sind hier Teile der Themes untergebracht, wie Stylesheets, Bilder und JS-Bibliotheken.

/setup/

Die Dateien des Installationsprozesses sind hier untergebracht. Aus Sicherheitsgründen wird das Verzeichnis nach erfolgreicher Installation automatisch geleert.

/tmp/

Hierbei handelt es sich um das Cacheverzeichnis der Applikation, in das beispielsweise kompilierte Smarty-Dateien gelegt werden.

Sie möchten ein vorhandenes Modul in OXID installieren.

Nutzen Sie das hier gezeigte Procedere, um Ihre Installation des OXID eShop durch neue Module zu erweitern.

Grundsätzlich lässt sich die Installation in drei Teile einteilen:

Es gibt verschiedene Möglichkeiten, wie man an ein externes Modul gelangen und die Grundfunktionalität des OXID-Systems erweitern kann. Auf der OXID-eigenen eXchange-Plattform[1] findet man diese Module wie auch auf GitHub[2] oder im Shop eines Modulentwicklers.

Das Grundprinzip der Modulinstallation kann man als »historisch gewachsen« bezeichnen: Die Dateien, die man für die Installation eines Moduls in den Shop kopieren muss, werden in einem Verzeichnis mit der Benennung /copy_this mitgeliefert. Wie der Name schon sagt, werden die Inhalte dabei eins zu eins in die Verzeichnisstruktur des Shops kopiert. Das gleiche Prinzip finden Sie auch beim Update des Systems wieder (siehe „2.8 OXID eShop durch Updates auf dem neuesten Stand halten“).

Klassischerweise werden bei OXID-Modulen .sql-Dateien mitgeliefert, und Sie müssen die Datenbankoperationen manuell ausführen. Dies können Sie entweder direkt in einer Oberfläche wie phpMyAdmin tun, alternativ jedoch auch im Backend unter Service ? Tools. Dort finden Sie auch den Button Views jetzt updaten (siehe Abbildung 2.1).

Im Gegensatz zu vielen anderen Anwendungen normalisiert OXID mehrsprachige Daten nicht über mehrere Tabellen, sondern legt die Spalte mit der zusätzlichen Sprach-ID direkt in derselben Tabelle an. So wird zum Beispiel aus OXTITLE für die Sprache mit der ID 1 OXTITLE_1. Dies spart aufwendige JOINS und macht das System performanter. Glücklicherweise muss man sich um die Auswahl der richtigen Felder nicht kümmern – dies übernimmt das Framework für uns. Wir müssen nur bei Datenstrukturänderungen die Views aktualisieren und die Tabelle über getViewName('WUNSCHTABELLE') ermitteln.

Sie möchten schnell und einfach den OXID-Cache aus dem Backend heraus leeren können.

Erstellen Sie ein Modul, mit dem sich im Backend auf Knopfdruck die diversen Caches leeren lassen.

Um nicht jedes Mal alle Berechnungen neu durchführen zu müssen und um aufwendige oder häufige Datenabfragen zu umgehen, cacht OXID einige dieser Daten. Diese Daten werden im Verzeichnis /tmp/ abgelegt. Durch dieses Caching des OXID-Frameworks wird das Entwickeln erschwert, weil statt der dynamisch erzeugten die bereits vorberechneten Inhalte verwendet werden. Zwar kann man den Cache via FTP löschen, indem man das /tmp/-Verzeichnis leert, dieser Schritt kostet jedoch oft mehr Zeit als nötig. Zudem sollen beim Ausrollen von Änderungen im Produktivsystem ja nicht alle Daten gelöscht werden.

Um ein Modul zu erstellen, das die Caches gezielt leert, benötigen wir eine Eingabemöglichkeit im Backend, einen Controller, der die gewünschte Aktion aufnimmt und weiterverarbeitet, und schließlich eine Klasse, die die interne Logik enthält.

Kümmern wir uns erst mal um das Backend. In unserer metadata.php definieren wir zunächst, dass wir eine weitere Eingabemöglichkeit benötigen. Wir haben uns in diesem Beispiel für den Header entschieden, um dort unser Cache-Interface unterzubringen. Da OXID dort von Haus aus keinen erweiterbaren Block zur Verfügung stellt, hilft nur ein komplettes Ersetzen der Template-Datei:

Wir gestalten das Interface so, dass ein Drop-down-Menü erscheint, über das man die verschiedenen Caching-Bereiche ansteuern kann. Wird ein Punkt ausgewählt,...