Mit dem OXID eShop 6.2 wurde eine neue Modulverwaltung eingeführt. Bis jetzt wurden alle Einstellungen zu Modulen in der Datenbank, Tabelle oxconfig, gespeichert. Jetzt werden zusätzlich diese Informationen auch in YAML-Files, eine pro Shop-Id, gespeichert.
Grundsätzlich ist dies der richtige Weg und vereinfacht auch vieles, wie z. B. eine Modulentwicklung. Jedoch hätte so eine relevante Änderung unserer Meinung nach in einem Major-Release stattfinden müssen und nicht in einem Minor-Release.
Probleme mit OXID 6.2 und YAMLs
Nachdem wir bereits einige OXID 6.2 Projekte umgesetzt haben hier mal die größten Probleme:
a) Modulinformationen sind in der Datenbank und in den YAML-Files, manchmal kommt es hier zu Inkonsistenzen.
b) Die Komplexität rund um das Thema Modulkonfiguration und Deployment ist extrem gestiegen.
c) An der ein oder anderen Stelle, z. B. Speichern von Modulsettings über den Shop-Admin + Deployment/Repository, ist es nicht ganz durchdacht.
Installation und Deinstallation von Modulen
- Ein Modul wird mit composer require installiert. Die Anpassung in der Shop-YAML und Datenbank erfolgt automatisch.
- Auf die gleiche Weise kann mit composer remove ein Modul auch wieder deinstalliert werden.
- Wird ein Modul auf dem „alten Weg“ installiert, d. h. einfach in den modules-Ordner gelegt, wird dieses vom Shop nicht erkannt bis es manuell installiert wird (bis OXID Core 6.6.0, siehe unten, danach mit Befehl möglich).
- Beim manuellen Löschen eines Moduls müssen derzeit auch die Einträge in der Shop-YAML manuell entfernt und die Datenbank aktualisiert werden, siehe oe:module:apply-configuration.
- Bei Änderungen in der metadata.php eines bereits installierten Moduls (ohne neue Version über composer) muss dieses neu, manuell, installiert werden, siehe oe:module:install-configuration.
Commands für die OXID Console
- Neues Modul installieren (Parameter: Modulverzeichnis)
vendor/bin/oe-console oe:module:install-configuration source/modules/oxcom/ocbcleartmp - Modul deinstallieren (Parameter: Modul-ID) [erst ab OXID 6.2.3, bzw. OXID Core 6.6.0]
vendor/bin/oe-console oe:module:uninstall-configuration ocb_cleartmp - Modul aktivieren (Parameter: Modul-ID)
vendor/bin/oe-console oe:module:activate ocb_cleartmp - Modul deaktivieren (Parameter: Modul-ID)
vendor/bin/oe-console oe:module:deactivate ocb_cleartmp - Aktualisiert die Modulsettings in der Datenbank anhand der Shop-YAML
vendor/bin/oe-console oe:module:apply-configuration - weitere Commands sind außerdem über die Developer Tools Component verfügbar
Learnings mit OXID 6.2
- Nach dem Installieren eines Moduls mit composer muss dieses immer noch aktiviert werden.
- Sofern die Shop-YAML nicht mehr vorhanden ist kann diese mit composer update, vorausgesetzt die entsprechenden Verzeichnis sind vorhanden, „leer“ generiert werden.
- Werden Symlinks genutzt kann es zu Problemen mit var/generated/generated_services.yaml kommen, da hier relative Pfade verwendet werden.
- Werden bei einem Deployment die Shop-YAML nicht mit im Repo abgelegt, was nicht immer Sinn mach, müssen im Anschluss auf den Servern ggf. manuell Befehle ausgeführt werden.
- Bei oe:module:apply-configuration kann man mit dem dem Parameter –shop-id=2 auch nur einen speziellen Shop aktualisieren (nur in der EE).
- Beim automatischen Deployen von Moduländerungen sollte das Modul erst deaktiviert und erneut aktiviert werden, ggf. zur Modulkonfiguration aktualisieren.
- Vor allem bei einer Migration mit vielen Modulen (wir hatten den Spaß mit > 40) muss immer wie daran gedacht werden ggf. die manuell Shop-YAML zu aktualisieren.
- Je nachdem ob die Shop-YAMLs mit im Repository abgelegt werden kann es zum Problem kommen dass Änderungen aus dem Shop-Admin nicht ins Repo gelangen und somit beim nächsten Release überschrieben werden.
- Das Nutzen von Environment-YAML-Dateien inkl. „hin- und herkopieren“ ist sehr aufwendig.
- Für das de/aktivieren sowie die Sortierung von Modulen nutzen wir den OXID Console Moduleactivator.
Weiterführende Links zum Thema
- OXID Blogpost Teil 1: https://www.oxid-esales.com/blog/dependency-injection-fuer-projektentwickler-in-oxid/
- OXID Blogpost Teil 2: https://www.oxid-esales.com/blog/dependency-injection-innerhalb-von-oxid-modulen/
- OXID Blogpost Teil 3: https://www.oxid-esales.com/blog/erweiterung-des-oxid-eshops-mit-hilfe-des-symfony-di-containers/
- interessante Diskussion im OXID Slack-Channel: https://oxid-dev.slack.com/archives/CDP3UFJD9/p1606303811361500
