OXID eShop Modulentwicklung Teil 3: Best Practices & Beispiele

OXID eShop Modulentwicklung Teil 3: Best Practices & Beispiele für nachhaltige Erweiterungen

Die Entwicklung von Modulen im OXID eShop bietet eine leistungsstarke Möglichkeit, individuelle Anforderungen innerhalb einer stabilen Shoparchitektur umzusetzen. Nachdem wir uns im ersten Teil unserer Serie den Grundlagen und im zweiten Teil der technischen Umsetzung gewidmet haben, konzentrieren wir uns nun auf Best Practices und praktische Beispiele, um nachhaltige und wartbare Module für OXID zu entwickeln.

Struktur und Lesbarkeit sind entscheidend

Ein essenzieller Aspekt professioneller Module ist eine saubere und nachvollziehbare Projektstruktur. Dies beginnt bei einer klaren Dateistruktur im Modulverzeichnis – getrennt nach Models, Controllern, Services und Templates. Entwickler sollten sich strikt an die Namenskonventionen von OXID halten und phpPSR-konforme Klassen einsetzen.

Dokumentation, sowohl im Code als auch als README im Modulverzeichnis, erhöht die Wartbarkeit und erleichtert zukünftige Erweiterungen. Verwenden Sie verständliche Kommentare und erläutern Sie komplexe Prozesse, wie z. B. spezielle Hooks oder Eventlistener, die angesprochen werden.

Verwendung von Services und Dependency Injection

Ein moderner Ansatz in der OXID Modulentwicklung ist der Einsatz von Dependency Injection (DI). Dies ermöglicht eine bessere Testbarkeit und verhindert enge Kopplungen innerhalb der Geschäftslogik. Logiklastige Prozesse sollten vom Controller getrennt und in eigene Services ausgelagert werden. Der DI-Container von OXID (seit v6.x) unterstützt PHP-DI, wodurch Services automatisch injiziert werden können.

Modulmetadata intelligent verwenden

Die Datei metadata.php ist das Herzstück eines Moduls. Neben der Standardkonfiguration für Templates, Blöcke, Einstellungen und Erweiterungen kann sie verwenden werden, um Events wie onActivate oder onDeactivate korrekt zu definieren. Vermeiden Sie dabei direkte Datenbankoperationen und setzen Sie stattdessen auf Repository-Klassen oder Migrationen.

Beispiel:

'events' => [
    'onActivate' => '\Vendor\MyModule\Core\ModuleInstaller::onActivate',
    'onDeactivate' => '\Vendor\MyModule\Core\ModuleInstaller::onDeactivate'
]

Diese Trennung erlaubt ein elegantes Handling von Aktivierungen und Deaktivierungen, etwa für das Anlegen von Konfigurationswerten oder der Initialisierung von benötigten Ressourcen.

Refactoring und technisches Schuldenmanagement

Im Alltag vieler Agenturen entstehen zunächst funktionsfähige, aber nicht immer optimal strukturierte Erweiterungen. Um technische Schulden zu vermeiden, sollten sich Entwickler mit Refactoring-Strategien auskennen. Besonders hilfreich ist der Einsatz automatisierter Test-Tools wie PHPUnit in Kombination mit OXID Testing Library.

Verwenden Sie bei der Erweiterung von Core-Klassen modulare Überladungen statt direkter Änderungen im Core. So bleibt Ihr Shop updatefähig. Nutzen Sie dafür die extend-Direktive in der metadata.php und vermeiden Sie überschneidende Modifikationen mit anderen Modulen durch gezieltes Event-Hooking oder Service Templating.

Datenbankzugriffe kapseln

Ein häufiger Fehler in selbst entwickelten OXID-Modulen ist der direkte Zugriff auf die Datenbank via Raw SQL oder Nutzung von oxDb::getDb(). Empfehlenswerter ist der Aufbau eigener Repository-Klassen, die auf der \OxidEsales\Eshop\Core\Model\BaseModel Struktur basieren.

Vorteile:

• Wartbarkeit durch zentrale Datenzugriffslogik
• Bessere Unit-Testbarkeit
• Einfachere Anpassung auf zukünftige Datenbankänderungen

Beispiel für eine Repository-Klasse

namespace Vendor\MyModule\Repository;

use OxidEsales\Eshop\Core\Model\ListModel;

class CustomArticleList extends ListModel
{
    protected $_sObjectsInListName = \OxidEsales\Eshop\Application\Model\Article::class;

    public function loadCustomArticles()
    {
        $sSelect = 'SELECT oxid FROM oxarticles WHERE oxstock > 0 AND oxactive = 1';
        $this->selectString($sSelect);
        return $this;
    }
}

Modultests und Qualitätssicherung

Qualitativ hochwertige Module sollten stets getestet sein. Das Ziel sind automatisierte Tests auf Unit- und Integrationsebene. Die OXID Testing Library ermöglicht ein sauberes Setup für PHPUnit-basierte Tests. Zusätzlich empfiehlt sich statisches Code-Analyzing mit Tools wie PHPStan oder Psalm.

Praxisbeispiel: Wunschzettel-Funktion als Modul

Ein häufig nachgefragtes Feature im E-Commerce ist die Wunschzettel-Funktion. Als OXID-Modul kann sie elegant über ein eigenes Template, einen Controller und ein erweitertes User-Model integriert werden. Die Logik für das Speichern und Auslesen der Wunschprodukte wird über ein separates Modell gehandhabt. Die Ausgabe erfolgt über ein Template-Block, das nahtlos in den Warenkorb integriert ist.

Dabei sollte auf Performance geachtet werden: statt komplexer JOINs empfehlen sich entsprechende Relations und ggf. eigene Tabellen mit schlanker Index-Struktur.

Versionierung und Deployment von Modulen

Ein weiterer Aspekt wartbarer Modularchitektur ist die Versionierung. Nutzen Sie für Ihre Projekte immer Git mit semantischer Versionierung – beispielsweise v1.0.0 für initiale Releases. Für den produktiven Einsatz ist ein Deployment über Composer und ein eigenes Repository wie packagist.org oder private Artefaktserver best practice.

Composer bietet außerdem das Mapping der Modulverzeichnisse via oxid-esales/oxideshop-metapackage-ce, sodass Module bequem mit dem Shopsystem gekoppelt werden können:

"require": {
    "vendor/mymodule": "^1.0"
}

Support für verschiedene OXID-Versionen

Viele Module sollen über mehrere Shopversionen hinweg funktionieren. Deshalb ist es wichtig, Kompatibilitäten regelmäßig zu prüfen, z. B. durch Test-Shops für die jeweiligen Versionen von OXID eShop 6.1 bis 6.5+. Nutzen Sie beim Codieren abstrahierte Helferklassen, Versionserkennungen (z.B. via Registry::getConfig()->getVersion()) und strukturierte Release-Notes.

Sie planen, ein OXID eShop Modul zu entwickeln oder ein bestehendes Modul zu optimieren? Gerne unterstützen wir Sie bei Themen wie modulare Shoparchitekturen, Composer-basierte Deployment-Strategien, Performance-Tuning oder Testautomatisierung für Ihre OXID-Projekte. Unser Entwicklerteam verfügt über langjährige Erfahrung in der Entwicklung komplexer Erweiterungen innerhalb des OXID-Ökosystems. Kontaktieren Sie uns – wir beraten Sie gerne individuell und auf Expertenniveau.