Moin,
ich habe ein Modul erstellt welches leider nicht funktioniert, wenn ich es versuche zu aktivieren sagt Oxid mir:
The method \Test\ModulBase\Core\ModulBase::onActivate is not callable.
Interessanterweise wird bei diesem Schritt auch der Path in der 1.yaml
von:
path: test/modul_base
zu:
path: ../../../../current/source/modul/test/modul_base
ausgetauscht.
Kann mir hier jemand auf die Sprünge helfen woran es liegen könnte…
ist onActivate auch public static?
Wie ist die target-directory in dfer composer.json?
Das Target Dir sieht wiefolgt aus:
"target-directory": "test/modul_base"
und ja die Klassen sind public static, wenn ich das Event entferne lässt sich das Modul auch aktivieren/deaktivieren.
Die beiden Events sind empty.
Moin,
der Fehler lag an meiner test_config.yml
Auf meinem Server waren die Paths nicht korrekt eingestellt.
Nachdem ich dies behoben habe funktioniert es.
MfG
Hallo @s1de und @vanilla_thunder
@s1de Könntest Du bitte genauer beschreiben wie du das Problem behoben hast? Ich habe nämlich das exakte Problem auf meiner Vagrant Box (Ubuntu 18.04). Alle Module welche bei der OXID 6.2 Installation vorinstalliert sind lassen sich aktivieren/deaktivieren, nur meins nicht, ich erhalte permanent:
The method \STINA\TestModule\Core\Setup::onActivate is not callable
Die Klasse gibt es. Die Methode ist “public static” und derzeit leer. Mein composer.json hat in “target-directory” den Wert “stina/testmodule”. Das modul befindet sich in /source/modules/stina/testmodule und wurde mit dem folgenden Kommando installiert:
vendor/bin/oe-console oe:module:install-configuration "./source/modules/stina/testmodule/"
In der metadata.php unter “events” steht folgendes:
'events' => [
'onActivate' => '\STINA\TestModule\Core\Setup::onActivate',
'onDeactivate' => '\STINA\TestModule\Core\Setup::onDeactivate'
],
Bitte um Hilfe 
Hattest schon oe:module:apply-configuration ausgeführt?
Update: Anscheinend schlägt folgende Prüfung bei Dir fehl in der EventsValidator Klasse.
private function checkIfMethodIsCallable(string $method)
{
$this->isNamespacedClass($method);
if (!is_callable($method) && $this->isNamespacedClass($method)) {
throw new ModuleSettingNotValidException('The method ' . $method . ' is not callable.');
}
}
Das heißt OXID eShop Framework kennt Deine Methode noch nicht bzw. Dein definierter Namespace ist noch unbekannt.
Definierst auch den Namespace in Deiner Klasse zu Beginn im Kopf der PHP Datei?
Hallo @indianer3c
Danke für die schnelle Antwort.
Ja, das Namespace ist drinnen. Ich habe jedoch eine Lösung gefunden, weiß nicht ob das so richtig ist. Es handelt es sich hier um ein OXID Modul welches wir neu entwickeln, deshalb habe ich das Namespace in die composer.json Datei unter “autoload-dev” hinzugefügt, und “composer install” durchgeführt. Jetzt geht es. Also so sieht der Spaß in der composer.json aus:
"autoload-dev": {
"psr-4": {
"OxidEsales\\EshopCommunity\\Tests\\": "./vendor/oxid-esales/oxideshop-ce/tests",
"STINA\\TestModule\\": "./source/modules/stina/testmodule"
}
}
So weiß OXID über mein Modul überhaupt Bescheid. Ist das so gedacht für neue Module oder mache ich was falsch?
ich folge immer der offiziellen “best practice” Anleitung in der Doku:
Prinzipiell muss dein Modul ein Namespace haben und dieses Namespace muss in der composer.json des Moduls hinterlegt sein.
Nehmen wir mal eines meiner Module als Beispiel:
Wenn du dein Namespace direkt in der root composer.json so hinterlegst, musst du composer dump-autoload ausführen, damit das Namespace in die Classmap aufgenommen wird. Ob das empfehlenswert ist, weiß ich allerdings nicht. Während der Entwicklung des Moduls scheint es durchaus zu funktionieren, aber in einem produktiven Shop würde ich mich doch lieber an die offizielle Vorgehensweise halten, für den Fall, ass nach der Composer Installation noch irgendwas wichtiges gemacht wird.
Ich kenne sogar einen Shopbetreiber, der alle Module Namespaces ebenfals im autoload einträgt, aber das macht er nur für Deployment in den Live Shop und im Dev Shop werden Module ganz regulär über composer require installiert.
Moin,
ich hatte die Pfade in meiner config.yaml angepasst auf die root Pfade meines deployment roots.
Jedoch habe ich die Probleme weiterhin wenn ich die Module mit dem VT Utils Modul resete und restarte, da ich dass aber nur machen muss wenn ich Klassen hinzufüge und ich aktuell nur im Demobetrieb am entwickeln bin korrigiere ich danach den Path händisch.
Es ist bei mir bei allen Modulen so, ob von.mir hinzugefügt oder Oxif Standard wie z.B. VCMS oder ERP
Lg
S1de
"
> "stina\\testmodule\\": "../../../source/modules/stina/testmodule"
Ich würde es so versuchen und die Schreibweise (groß/klein) der/des Ordner/s beachten.