OXID eShop Modulentwicklung Teil 2: Best Practices & Beispiele

Die Entwicklung von Modulen für den OXID eShop ist eine essenzielle Disziplin, wenn es darum geht, individuelle Anforderungen professionell abzubilden und Erweiterungen sauber sowie updatefähig zu integrieren. Nachdem im ersten Teil unserer Serie die Grundlagen sowie das grundlegende Modulgerüst behandelt wurden, widmen wir uns nun den Best Practices und konkreten Beispielen für eine stabile, nachhaltige Modulentwicklung innerhalb des OXID Shopsystems.

Saubere Strukturierung und klare Verzeichnisse

Ein typischer Fehler vieler Entwickler ist die unstrukturierte Ablage von Dateien innerhalb des Moduls. Für OXID empfiehlt es sich, das empfohlene Modulverzeichnis wie folgt zu nutzen:

/Controller/ – Hier befinden sich Controller-Klassen, die Frontend- oder Backend-Funktionalitäten beinhalten.
/Model/ – Für Entity-Klassen und Datenbankmodellierung.
/Core/ – Hier werden systemnahe Logiken oder branchenübergreifende Helferklassen abgelegt.
/Extension/ – Für Klassen, die bestehende OXID-Kernklassen erweitern oder überschreiben.
/metadata.php – Diese Datei beschreibt das Modul gegenüber dem OXID System.

Eine klare Verzeichnisstruktur stellt sicher, dass Teams effizient arbeiten können und zukünftige Entwickler schnell nachvollziehen, wie das Modul intern aufgebaut ist. Dies ist gerade in der Teamarbeit oder bei langfristiger Wartung entscheidend.

Verwendung von OXID-Modul-Funktionalitäten

Der OXID eShop verfügt über ein robustes Modulsystem, das u.a. das Überschreiben und Erweitern von Core-Klassen ermöglicht. Eine professionelle OXID Modulentwicklung setzt auf den Extension-Mechanismus über die extend-Anweisung in der Metadata-Datei. Hier ein Beispiel:

'extend' => [
    \OxidEsales\Eshop\Application\Controller\ArticleDetailsController::class => \Vendor\MyModule\Controller\ArticleDetailsController::class,
]

Statt Kernklassen direkt zu modifizieren, ist dies der empfohlene und updatesichere Weg, um bestehende Funktionalität sinnvoll zu erweitern.

Autoload und Namespaces nutzen

Spätestens mit der Einführung von Composer in OXID 6 ist die Nutzung von namespaced Klassen und einem sinnvollen Autoloading-Mechanismus Standard. In der composer.json Ihres Moduls sollte folgender Namespace korrekt angegeben sein:

"autoload": {
    "psr-4": {
        "Vendor\\MyModule\\": "src/"
    }
}

Dadurch ist eine saubere Trennung und automatische Integration in den OXID eShop gewährleistet, ohne unnötig auf alte Modul-Fallbacks zurückgreifen zu müssen.

Verwendung von Services und Dependency Injection

Mit OXID Version 6 wurde Symfony-basiertes Dependency Injection eingeführt. Für die professionelle Entwicklung und langfristige Wartung von OXID Modulen empfiehlt es sich, eigene Services zu definieren und via DI Container bereitzustellen. Eine services.yaml im Modul hilft, diese Services zu registrieren:

Vendor\MyModule\Service\MyService:
    arguments:
        $logger: '@monolog.logger'

So erhöhen Sie die Wiederverwendbarkeit und Testbarkeit Ihrer Module stetig, anstatt Logik in Controller zu pressen.

Datenbankmigrationen effizient verwalten

Gerade bei der Entwicklung größerer eCommerce-Projekte mit OXID ist es essenziell, Änderungen an der Datenbank gut dokumentiert und versioniert durchzuführen. Nutzen Sie dafür die in OXID integrierte Unterstützung für Doctrine Migrations. Diese lassen sich wie folgt einbinden:

vendor/bin/oe-eshop-doctrine-migration migrations:generate

Damit stellen Sie sicher, dass Ihre eigene Modullogik mit den benötigten Datenstrukturen korrekt ausgeliefert und später auch wieder migriert bzw. zurückgerollt werden kann.

Best Practices für Templating und Übersetzungen

Ein wichtiger Aspekt bei der Entwicklung eines Moduls ist die saubere Integration von Templates. Vermeiden Sie es, Templates zu überschreiben – erweitern Sie diese lieber durch modulare block-Elemente, wie sie OXID von Haus aus unterstützt:

[{$smarty.block.parent}]
<div class="my-custom-block">Extra Inhalt</div>

Auch Mehrsprachigkeit sollte bei der Entwicklung stets berücksichtigt werden. Leiten Sie alle Texte über eigene Sprachdateien z.B. de/lang.php und verwenden Sie Übersetzungsschlüssel statt harter Texteingaben. So bleiben Erweiterungen flexibel und leicht wartbar.

Unit-Tests und Qualitätssicherung

Gerade bei komplexer Logik ist es unerlässlich, automatisierte Tests zu schreiben. OXID setzt auf PHPUnit als Testframework. Die Entwicklung wiederverwendbarer Tests für Datenverarbeitung, Serviceklassen und komplexe Controllerlogik ist ein Kernelement nachhaltiger Entwicklung.

Ein Sample-Test für einen Service könnte wie folgt aussehen:

public function testCalculatePrice() {
    $service = new MyService();
    $result = $service->calculatePrice(100);
    $this->assertEquals(119, $result);
}

Setzen Sie darüber hinaus Tools wie PHPStan sowie einen CI/CD-Workflow ein, um die Qualität Ihrer OXID Module dauerhaft auf hohem Niveau zu halten.

Praxisbeispiel: Erweiterung der Versandkostenlogik

Ein typisches Praxisbeispiel aus laufenden Projekte ist die Erweiterung der OXID-Versandkostenlogik. Dies kann etwa beinhalten, dass bestimmte Produkte andere Versandarten erhalten oder Sperrgutzuschläge beim Checkout automatisch hinzugefügt werden.

Hier ist ein typisches Vorgehen:

Erweiterung der Klasse oxDeliverySet über die Extension-Schnittstelle
Nutzung von Hooks in getDeliveryPrice(), um Logik abhängig vom Warenkorb-Inhalt einzufügen
Optional: Registrierung eines eigenen Moduls im Adminbereich zur Konfiguration

Diese Art von erweiterter Logik sollte immer so gestaltet werden, dass sie Bestandteile des Moduls bleibt und keine Core-Systemmodifikationen nötig sind. So bleibt der Shop langfristig wartbar und updatesicher.

Regelmäßige Wartung und Update-Kompatibilität sichern

Ein Modul ist kein starres Gebilde. Es lebt weiter – und das bedeutet: regelmäßige Überprüfung auf Kompatibilität mit neuen OXID-Versionen sowie Pflege von Abhängigkeiten. Behalten Sie die offiziellen OXID Release Notes im Auge und testen Sie Updates frühzeitig in Ihrer Entwicklungsumgebung.

Mittels composer update und gezieltem Versioning Ihrer Module können Sie sicherstellen, dass alles reibungslos funktioniert.

Jetzt Ihre OXID eShop Module zukunftssicher entwickeln

Sie entwickeln regelmäßig OXID-Module oder planen individuelle Erweiterungen für Ihren OXID eShop? Profitieren Sie von unserer langjährigen Erfahrung aus zahlreichen eCommerce-Projekten. Wir unterstützen Sie gerne bei Themen wie Modularchitektur, Refactoring bestehender Erweiterungen, Performanceoptimierung oder Integration von Schnittstellen (z.B. ERP, PIM, Zahlungsanbieter). Auch bei der Migration von OXID 4/5 auf OXID 6 helfen wir mit bewährtem Know-how.

Kontaktieren Sie uns jetzt unverbindlich – für professionelle OXID Modulberatung mit Weitblick.

Matthias Eggert

Matthias Eggert ist seit über 12 Jahren im Online Marketing tätig und seit 4 Jahren Head of Online Marketing bei DIXENO . DIXENO ist an den Standorten Arnsberg, Paderborn, Hamburg und Berlin vertreten und verfügt über mehr als 50 Mitarbeiter.
Neben seiner Tätigkeit als Head of Online Marketing ist Matthias Gründer von onlinemarketingberatung.de – Cruising Media.
Sein Fokus liegt auf allen SEO relevanten Themen und er unterstützt Kunden von der Konzeption der richtigen Strategie, über die technische Umsetzung, bis zur detaillierten Analyse.

OXID eShop Modulentwicklung Teil 2: Best Practices & Beispiele