Hallo zusammen,
kennt jemand eine gute Schritt-für-Schritt Anleitung, wie man unter Oxid 6 ein Modul erstellt? Wirklich nur die Basics und für Blöde wie mich?
Es mangelt nicht an Tutorials oder Dokumentationen, allerdings sind die scheinbar für hauptberufliche Programmierer gedacht.
(Z.B. fängt das Tutorial unter https://www.rent-a-hero.de/wp/2017/10/09/module-erstellen-fuer-oxid-6/ direkt damit an, dass man in der json-Datei sein “Modul-Repository” als Zip-Datei oder über github laden soll. Was für Dateien sollen denn in dem Zip sein? Wie sieht die Ordner-Struktur aus?..)
Als Parade-Beispiel zum Nachbauen wird ausgerechnet das PayPal-Modul genannt, dessen Metadata-Datei bereits mit seiner Komplexität erschlägt - zumindest Unbedarfte wie mich. Von der Ordnerstruktur will ich gar nicht erst anfangen. Zumal es offenbar sowohl unter source/modules Dateien gibt als auch unter vendor/oxid-esales.
Vermutlich sollte ich den vielen Querverlinkungen folgen und erst sämtliche verfügbare Dokumentation zum Handling von Github, Composer, Metadata Version 2, “PSR-4 compliant” namespaces, etc.pp. folgen, bevor ich meine alten selbstgebauten Module portiert bekomme (was ja angeblich ganz einfach ist.)
Aber vielleicht hat ja jemand schon die Ochsentour hinter sich und hat ein etwas übersichtlicheres Beispiel, das durch seinen Minimalismus nachvollziehbar bleibt (z.B. ein zusätzliches Feld im Backend anzeigt oder irgendeine einzelne Kleinigkeit im Frontend ändert).
Würde mich sehr freuen
Falls das für andere genausowenig selbstverständlich ist wie für mich: So habe ich das Beispiel-Modul installiert:
Über die Kommandozeile (Shell/Putty) in das Verzeichnis gewechselt, in dem die Ordner “source” und “vendor” liegen (und “composer.json”, aber die Datei gibt es auch noch in anderen Verzeichnissen)
Dann ausgeführt:
“composer require linslin/oxid6-example-module:dev-master --update-no-dev”
Ich musste in meinem Fall “sudo” voranstellen, obwohl davon abgeraten wird.
“–update-no-dev” habe ich angehängt, um die überflüssige (?) Entwicklungsumgebung nicht zu installieren
Dann alle Schritte bestätigen und die Fehlermeldung am Ende ignorieren
(“Class Incenteev\ParameterHandler\ScriptHandler is not autoloadable, can not call post-update-cmd script”)
In “/source/modules” gibt es jetzt einen neuen Ordner “linslin”, ebenso in “/vendor” (warum auch immer)
Jetzt im Backend einloggen; Unter “Extensions > Modules” das “OXID6 example module” aktivieren (Reiter “Overview”)
In der linken Menüleiste gibt es jetzt unterhalb von “Module” (drittletzter Punkt) einen neuen Eintrag “Example Module”.
Einmal anlicken, jetzt erscheint im Hauptframe das “Hallo Welt” aus der Datei “views/admin/main.tpl”
Ich versuche jetzt, auf Basis dieses einfachen Moduls und Elementen aus dem PayPal-Modul eine Funktion aus der User-Class zu überschreiben (/vendor/oxid-esales/oxideshop-ce/source/Application/Model/User.php)
In der Metadata (2.0) habe ich unter “extend” angegeben (analog zu PayPal):
\OxidEsales\Eshop\Application\Model\User::class => \floko\fkcustom6\Model\User::class,
Im Ordner “/source/modules/floko/fkcustom6/Model” liegt dazu eine Datei User.php, in dieser steht (ebenfalls analog zu PayPal):
namespace floko\fkcustom6\Model;
class User extends User_parent
{
usw.
Aktivieren des Moduls im Backend schlägt fehl mit folgender Fehlermeldung unter log/oxideshop.log:
“Module class floko\fkcustom6\Model\User not found.”
Composer kopiert erstmal in das vendor-directory, von da aus kopiert das OXID-Composer-Plugin Teile in das source-Verzeichnis, unter anderem Module.
Der Composer-Autoloader muss den Namespace des Moduls kennen, dazu braucht er eine Zuordnung Namespace zu Modulpfad (psr-4). Bei der Installation über Github/Packagist holt er sich das automatisch aus der composer.json des Moduls. Weil diese dann im Verzeichnis /vendor/vendor_name/module_name liegt, schaut der Pfad dort so aus:
"../../../source/modules/vendor_name/module_name"
Also rauf bis zum root und dann in source/modules etc.
Während der Entwicklung liegt das Modul ja noch in keinem Repository sondern nur unter /source/modules. Dann kann man den Pfad manuell in der composer.json des Projekts, also der im root des Shops eintragen, und “composer dump-autoload” ausführen: https://docs.oxid-esales.com/developer/en/6.1/modules/good_practices/module_setup.html
Weil diese composer.json im Rootverzeichnis liegt, schaut der Pfad so aus:
"./source/modules/vendor_name/module_name"
Nach “composer dump-autoload” kennt der Autoloader das Modul und findet die Klassen in den Unterordnern automatisch.
Wow, vielen Dank für die geduldigen Antworten und hilfreichen Tipps!
Ich hänge noch am Eintrag in composer.json. Was wäre denn in meinem Fall der “Namespace”?
Der Pfad auf der rechten Seite ist soweit klar, aber ich weiß nicht, worauf der “Namespace” verweisen soll.
In meiner Datei User.php ist der “Namespace” (analog zum PayPal-Modul):
“namespace floko\fkcustom6\Model;”
Muss das auch hier stehen, nur mit doppeltem Backslash?
Du hast das jetzt in autoload-dev, das gilt nur wenn dev installiert wird, ansonsten kannst du einen Eintrag autoload anlegen wie im Link beschrieben, den gibt es standardmäßig in der composer.json noch nicht.
Ich kenne jetzt den grundlegenden Aufbau für Module, die Installation, bekomme es aktiviert und korrekt eingebunden.
Fantastisch!
Vielen Dank noch mal für die Unterstützung!
ich fange gerade an mich mit OXID 6.1 zu beschäftigen bzw. möchte einen 4.10 updaten. Was ich nicht ganz verstehe ist warum Module überhaupt vom vendor Verzeichnis ins source Verzeichnis kopiert werden und der Code nicht nur im vendor Verzeichnis verbleibt. Aus Kompatibilitätsgründen für ältere Module?
Wie verhält es sich, wenn man tpl und src Dateien des Moduls an die Optik eines eigenen Themes anpassen muß. Wie würde man da wohl am sinnvollsten vorgehen?
Vendor: von composer verwaltet, Source: selbst verwaltet (prinzipiell editierbar). In einem Modul können außerdem auch Frontend-Dateien wie css, js oder Bilder sein und der Vendor-Ordner liegt ja außerhalb des Docroot. Wenn ein Modul verändert wurde kann man das Modul bei einem composer update überspringen, es gibt bei jedem Modul eine Rückfrage ob es überschrieben werden soll oder nicht. Wenn man eine neue Version des Moduls installiert werden die Änderungen natürlich überschrieben und müssen erneut gemacht werden.
Hallo. Ich bin gerade auch dabei, unseren Shop auf 6 umzustellen, bevor er überhaupt online geht. Ich habe 2 Module für 4108 selbst erstellt und habe bisher nicht herausgefunden, wohin ich diese Module in 6 kopieren muss und wie ich sie aktivieren kann.
Es muss doch möglich sein, ein Modul ohne GIT oder ZIP hinzuzufügen, zu laden und zu aktivieren
Kann mir das mal jemand “für noch Dovere ” erklären? Danke euch.
Da ich auch Datenbankabrufe habe, die nicht mehr gehen sollen, versuche ich gerade, die Module zu portieren. Jetzt habe ich die composer.json hinzugefügt und alle Dateien bearbeitet und weiß nicht weiter.
Wenn ich das Module direkt in den Modulordner lade, erscheint das Modul zum Aktivieren im Backend genau wie in 4108. Nur werden die Dateien aus Extend nicht gefunden.
Vorher kommt sicher die composer.json zum Anmelden ins Spiel. Nur wie ohne GIT und ZIP?
Also ich fang erst mal kurz mit den Begriffen an. Git und Zip haben eher nichts damit zu tun.
Mit Git versionierst du deine Entwicklung und kannst mit Commits und Tags deine Entwicklung grob Dokumentieren. Anschließen kannst du die Anpassungen in ein externes Repository speichern wie Github, Gitlab, Bitbucket…
Zip speichert deine Dateien in ein extrahierbares Paket.
Was du fragen musst: Wie installiere ich Module mit/oder ohne Composer.
Die zweite Möglichkeit ist, du nutzt Composer wie es vorgesehen ist. Du speicherst dein Modul öffentlich oder privat ab und sagst Composer mit der “composer.json” wo das Modul liegt und dann kannst du es mit “composer require dein/modul” installieren.
Composer kann Pakete aus dem Netz, oder auch aus lokalen Verzeichnissen heraus installieren.
Jetzt müsstest du dich nur entscheiden wo dein Modul gespeichert werden soll:
Lokal: Bedeutet z.B. /privateSrc direkt neben dem /source Verzeichnis
Privat: Als Git auf Gitlab, oder kostenpflichtig auf packagist.com
Danke sehr für die tollen Infos. Ich möchte es schon wie vorgesehen machen. Dann rufe ich also composer mit putty im root verzeichnis auf und sage über composer require /privateSrc/gerome/basketedi, dass das Modul basketedi im Ordner /privateSrc/gerome/ hinzugfügt werden soll?
” erklären? Danke euch.