OxidKernel

Liste der Module die den Kernel verwenden

• Oxid Module Installer (In Entwicklung)
• Sioweb/OxidApi (Demomodul)

Installation

Falls nicht schon gesehen, installiere Composer auf deinen Rechner. Öffne die Konsole im Root von Oxid und führe folgenden Befehl aus:

composer require oxid-community/symfony-kernel

Modul aktivieren

Aktiviere das Modul Symfony Kernel im Backend unter Erweiterungen > Module.

Modul Reihenfolge

Damit Kernel funktioniert musst die Ladereihenfolge korrekt eingerichtet sein. Öffne den Tap Installierte Shop-Module unter Erweiterungen > Module und suche den Eintrag OxidCommunity\SymfonyKernel\Legacy\Core\ShopControl. Sollten noch weitere \ShopControl Einträge vorhanden sein, verschiebe OxidCommunity\SymfonyKernel\Legacy\Core\ShopControl an das Ende der ShopControl-Liste.

Tip: Mit STRG + F (CMD + F für Mac) kann ShopControl besser gesucht werden.

Mögliche Probleme

Falsch benannte Klassennamen. Es kann durchaus passieren, dass Module die Klasse ShopControl klein schreiben, oder gänzlich unterschiedlich benannt haben. Auch diese Klassen müssen in der Ladereihenfolge vor dem Kernel positioniert werden.

Nach installation eines Modules läuft Oxid Kernel nicht mehr. Denn dass neue Modul nutzt vermutlich auch die Klasse ShopControl und die Ladereihenfolge muss angepasst werden.

Hinweis: Eine automatische Ladereihenfolge steht auf der Todo-Liste.

Was kannst du damit tun?

Alles was Symfony bietet, oder zumindest alles, was die Symfony-Version von Oxid bietet. Die meisten Symfony 3 Komponenten sollten funktionieren, versuche aber bitte nicht, die Oxid-Tabellen mit Entities zu nutzen. Das Oxid-Framework sollte weitgehends verwendet werden, um Daten zu verarbeiten oder zu formatieren. Die machen das schon ganz gut. OxidKernel hat erst dann einen Vorteil, wenn es um Komminikation mit anderen Systemen etc. geht, oder du mit Komposer bestehende Bundles hinzufügen möchtest.

Module und Assets als Symlink verlinken

Dieses Modul kann ebenfalls als Ersatz für den Oxid-Composer verwendet werden. Module die oxidkernel-module als type besitzen, werden nicht mehr kopiert, sondern als Symlink angelegt. Alle Dateien, die unter /source/modules/ verfügbar sein sollen, müssen im Modul unter /src/Resources/oxid gespeichert werden.

Für tools wie Webpack etc. können Assets wie JS- und CSS-Dateien im Modul unter /src/Resources/public gespeichert werden. Diese werden dann als Symlink unter /source/out/assets/module/packagename/ verlinkt.

Beispiel

Das Modul sioweb/oxid-api basiert auf diesem OxidKernel und fügt eine REST-API hinzu, mit der Daten aus Oxid abgegriffen werden können. OxidKernel wird automatisch installiert, wenn composer req sioweb/oxid-api ausgeführt wird.

Symfony-Bundles & Routen in Oxid

Um Bundles automatisch für Oxid zu registrieren, muss folgende Extra-Eigenschaft in der composer.json des Bundles hinterlegt werden. Damit müssen Benutzer das Bundle nicht erst von Hand in eine Datei schreiben. Es ist unbedingt notwendig, der Bundle-Klasse einen uniquen Namen zu geben, daher bitte wie folgt ausschreiben. Das API-Bundle nutzt beispielsweise SiowebOxidApiBundle.php.

"extra": {
    "oxid-kernel-plugin": "Your\\Namespace\\PluginName\\YourNamespacePluginNameBundle"
}

Bitte Your\\Namespace durch den eigenen Namespace ersetzen. Die Verzeichnis-Struktur sollte wie folgt aussehen:

• ROOT/
  • src/
    • Resources/
      • config*
        • [routing|listener|services].yml
      • oxid
        • Module Article.php
        • views/
        • metadata.php
    • YourNamespacePluginNameBundle.php
  • composer.json
  • README.md

In der composer.json kann dann angegeben werden, dass die Daten unter src/Resources/oxid/ in das Module-Verzeichnis von Oxid installiert werden soll. Alle Namespaces die in den Module-Ordner kopiert werden, sollten als Namespace-Zusatz Legacy erhalten. Im API-Bundle lautet der Namespace beispielsweise Sioweb\Oxid\Api\Legacy\, gefolgt von der Ordnerstruktur nach PSR-4.

"extra": {
    "oxideshop": {
        "source-directory": "./src/Resources/oxid",
        "target-directory": "VENDOR NAME/PLUGIN NAME"
    },
    "oxid-kernel-plugin": "Your\\Namespace\\PluginName\\YourNamespacePluginNameBundle"
},
"autoload": {
    "psr-4": {
        "Your\\Namespace\\PluginName\\Legacy\\": "../../../source/modules/VENDOR NAME/PLUGIN NAME/",
        "Your\\Namespace\\PluginName\\": "src/"
    },
    "exclude-from-classmap": [
        "src/Resources/oxid"
    ]
}

In der Datei Plugin.php können Routen und Konfigurationen geladen werden.

Ein Modul benötigt weitere Bundles

Dazu müssen alle Bundles im Requirement-Block geladen werden. Anschließend müssen mehrere oxid-kernel-plugin hinterlegt werden. Hier ein Beispiel mit Twig:

"extra": {
    "oxideshop": {
        "source-directory": "./src/Resources/oxid",
        "target-directory": "VENDOR NAME/PLUGIN NAME"
    },
    "oxid-kernel-plugin": {
        "eigener/paketname": "Your\\Namespace\\PluginName\\YourNamespacePluginNameBundle",
        "twig": "Symfony\\Bundle\\TwigBundle\\TwigBundle"
    }
}

Wichtig ist, dass die Werte "eigener/paketname" und "twig" eindeutig bzw. unique sind. Pakate die später geladen werden, können die Einstellungen überschreiben und eigene Klassen an dieser Stelle laden.

Stand-Alone ohne Oxid

Der Kernel ist auch gänzlich ohne Oxid nutzbar. Sollte ein Modul den Kernel, aber nicht zwingend Oxid benötigen, kann das Modul mit composer create-project vendor/modul installiert werden. Das Modulö benötigt den Parameter oxid-kernel-plugin und folgende Scripts:

"scripts": {
    "post-install-cmd": [
      "OxidCommunity\\SymfonyKernel\\Composer\\Plugin::registrateRootPlugin"
    ],
    "post-update-cmd": [
      "OxidCommunity\\SymfonyKernel\\Composer\\Plugin::registrateRootPlugin"
    ]
}

Configuration

Die Config wird weitgehends automatisch eingerichtet. Nach der Installation wird im Root des Shops das Verzeichnis /kernel/ angelegt. Hier können dann die Symfony-Typischen Configs etc. verwendet werden.

parameters.yml & Datenbank?!

Die Datei parameters.yml wird automatisch unter /kernel/config/parameters.yml eingerichtet. Sämtliche Einstellungen aus /source/config.inc.php werden in lowercase übernommen und gespeichert.

Datenbank-Parameter werden automatisch in Symfonykonforme Namen umgewandelt.

Eigene Configs?

Unter /kernel/config/ kann die Datei config_prod.yml angelegt werden. OxidKernel lädt diese dann nach. Später wird vermutlich auch eine config_dev.yml möglich sein. Bis auf weiteres, gibt es allerdings nur die 'prod'-Environment.

Aber was ist mit den Oxid-Routen?

OxidKernel wird den regulären Betrieb nicht stören. Ein Eventlistener prüft zunächst, ob eine Route überhaupt in einer YAML-Datei hinterlegt wurde und ob diese geladen werden kann. Sollte die Route nicht gefunden werden, wird Oxid alles weitere Überlassen. Daher würde ich vorschlagen, dass die Routen sich besser nicht mit den Kategorien in Oxid überschneiden.