Modul erstellen unter Oxid 6 für Dummies

module
oxid6

#1

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 :slight_smile:


#2

@linslin hat so ein Beispiel-Modul erstellt: https://github.com/linslin/oxid6-example-module

Alternativ kann man auf Namespaces verzichten und die Metadata Version 1.x verwenden: https://docs.oxid-esales.com/developer/en/6.0/modules/skeleton/metadataphp/version_compatibility.html


#3

Wunderbar, das sieht perfekt aus: “simple and basic” sind die Stichworte, auf die ich gehofft hatte :smiley:
Danke!!!


#4

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”


#5

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.”

Was mache ich falsch?


#6

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.


Migration von Modul von v4 zu v6
#7

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”?

“autoload-dev”: {
“psr-4”: {
“OxidEsales\EshopCommunity\Tests\”: “./vendor/oxid-esales/oxideshop-ce/tests”,
“<namespace???>”: “./source/modules/floko/fkcustom6”,
}
},

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?


#8
"floko\\fkcustom6\\"

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.


#9

Ich kenne jetzt den grundlegenden Aufbau für Module, die Installation, bekomme es aktiviert und korrekt eingebunden.
Fantastisch! :smiley:
Vielen Dank noch mal für die Unterstützung!


#10

Der Vollständigkeit halber möchte ich auch nochmal auf den Skelleton Generator verweisen:


#11

Hier gibts auch noch ein paar Infos: https://www.proudcommerce.com/OXID-Blog/OXID-6-Tipps-Tricks.html


#12

Hey ein Skeleton Generator ist unter https://github.com/CodeCommerce/ModulSkeleton/ zu finden.

Ansonsten gab es von mir auch 2 Beiträge im PHPMagazin dazu. Bzw. In einem Heft ein Tutorial.

Lg


#13

Hallo leofonic,

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?

Vielen Dank und viele Grüße,
Frank


#14

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.


#15

Danke für Deine Hilfe! Guter Punkt wegen den Frontend Dateien und dann habe ich das verstanden!