Eigene Funktion als Modul verpacken

Hallo, bisher hab ich mich noch nicht an eigene module rangetraut aber möchte nun eine eigene funktion in ein modul verpacken.

Ich habe folgenden funktion:

public function box()
    {
     // Meine Funktion
    }

Diese funktion ist bisher in "vendor/oxid-esales/oxideshop-ce/source/Application/Controller/FrontendController.php" drin.

Nun möchte ich die funktion aus der FrontendController.php datei in ein modul verpacken.

Und so sieht mein modul-setup aus:

Ordnderstruktur:

im source/modules/gajel/box/ ordner liegen:

metadata.php
/Controller/FrontendController.php

Metadata.php:

$sMetadataVersion = '2.0';
$aModule = array(
    'id'          => 'box',
    'title'       => 'Box Funktion Modul',
    'description' => 'Ermöglicht zugriff auf Box Funktion',
    'thumbnail'   => 'out/pictures/logo.png',
    'version'     => '0.1',
    'author'      => '<strong style="font-size: 17px;color:#04B431;">Gajel</strong>',
    'url'         => 'xyz',
    'email'       => 'xyz',
    'extend'      => array(
		\OxidEsales\Eshop\Application\Controller\FrontendController::class       => gajel\box\Controller\FrontendController::class,
    ),
);

FrontendController.php:

namespace gajel\box\Controller;

class FrontendController extends FrontendController_parent
{

    public function box()
    {
     //Meine Funktion
    }

}

Soweit so gut. Das “modul” wird im backend erkannt aber sobald ich es aktiviere dann bekomme ich folgenden fehlermeldung:

Es wurden ungültige Module erkannt.

Möchten Sie alle registrierten Modulinformationen und gespeicherten Konfigurationseinstellungen löschen?

Module-ID: box 	Problematische Dateien: OxidEsales\Eshop\Application\Controller\FrontendController => jakob\box\Controller\FrontendController

Wo genau liegt hier mein fehler? Ich komme nicht mehr weiter.

Hallo @gajel,

gut wäre, wenn Du //Meine Funktion durch den eigentlichen Code ersetzen würdest: Ich halte es nicht für unwahrscheinlich, dass das Problem dort zu suchen ist :wink:

Wenn es rein um die metadata 2.0 geht: Aktuell steht ein Blogpost dazu in den Startlöchern, der ggf. morgen veröffentlicht werden kann. Hol Dir einfach mal diesen RSS-Feed ab:
https://oxidforge.org/en/feed

Hi,

in der metadata.php steht: gajel\box\, in der Fehlermeldung steht jakob\box\.
Das passt nicht zusammen.

Dann brauchst du eine composer.json und musst das Modul via Composer installieren.
Erst dann kann es im Shopadmin aktiviert werden.

Hier steht zB, wie man Module einfach als Zip-Archiv via Composer installieren kann.

Ich muss jetzt leider gleich zur einem IHK seminar aber danach melde ich mich. Danke schon mal für das feedback.

@marco.steinhaeuser Die eigentliche funktion bzw. der code funktioniert ja einwandfrei in der hardcoded variante …

public function box()
    {
        if ( $this->_sCatTitlebox === null ) {
            $this->_sCatTitlebox = false;	
			    
				// appending parent title
				if ( $oCategory = $this->getActCategory() ) {
						
					// adding cateogry title
					$this->_sCatTitlebox .= " {$oCategory->_oParent->oxcategories__oxtitle->value}";
					$this->_sCatTitlebox .= " {$oCategory->oxcategories__oxtitle->value}";
				}
			            
        }
        return $this->_sCatTitlebox;
}

@nickname Das ist alles in ordnung so. Ich hatte nur von jakob auf gajel fürs forum gewechselt.

Eine composer.json brauche ich doch nicht unbedingt?! Ich hab schon einige module “manuell” per FTP installiert, ganz ohne probleme. Die module werden auch u.a. so vom hersteller zu verfügung gestellt. Also daran sollte und darf es nicht liegen …

Doch, daran liegt es.

Du brauchst schon eine composer.json und musst das Modul via Composer installieren.
Lt. deinem obigen Codes handelt es sich um ein echtes OXID6-Modul mit Namespace und metadata v2.0.
Ohne Composer kommt die von dir gepostete Fehlermeldung, das ist ganz normal, da der Namespace nicht bekannt ist.

Viele Hersteller liefern “alte” OXID4-Module für OXID6 aus, da diese in vielen Fällen auch in OXID6 laufen.
Diese muss man dann nur hochladen und aktivieren.
Wenn du das auch so machen willst, musst du auch ein OXID4-Modul erstellen.

1 Like

Ok verstehe. Vielen dank für die erklärung. :slight_smile:

Wenn ich heute noch dazu komme, dann werde ich das mal mit dem composer testen.

So ich hab jetzt endlich mal zeit dafür gefunden und mich dran versucht. Leider will es nicht funktionieren. Sobald ich den installationsbefehl composer require jakob/var_art_suche per ssh ausführe, dann bekomme ich folgende fehlermeldung:

[InvalidArgumentException]
Could not find a matching version of package jakob/var_art_suche. Check the package spelling, your version constraint and that the package is available in a stability which matches your minimum-stability (stable).

mit der ich nicht soviel anfangen kann. Ich hab als vorlage das HDI-Report modul, welches in dem verlinkten guide von nickname erwähnt wird, genommen und mein modul angepasst.

Nicht wundern, dass das modul nun ein anderes ist als (es soll ja ums prinzip gehen). Das aktuelle modul erlaubt die variantensuche per art.nr. Dieses gab es schon mal hier im forum für oxid 4.x meine ich. Ich wollte die “funktion” nun in ein oxid 6 modul verpacken.

Ich hab das ganze mal auf github hochgeladen (auch mein erstes mal), also wenn da irgend was falsch eingestellt ist, bitte bescheid geben. Hätte das auch gerne bei den anderen oxid-modulen reingepackt, wussste aber nicht wie.

Naja lage rede kurzer sinn. Kann sich mal jemand anschauen wo ich ein fehler in dem modul habe und wieso ich das nicht über den composer installieren kann? Bei dem HDI-Report Modul, an dem ich mich orientiert habe, funzt es wunderbar.

Hier nun das modul:

Grüße

Hi,
da momentan keine Version verfügbar ist, kann er auch keine finden: https://github.com/Gajel/Oxid-variant-art-nr-search/releases

Wenn du es so von GitHub installieren willst, muss du entweder ein Version-Tag setzen oder :dev-master anhängen, damit er den Master-Branch verwendet:

composer require jakob/var_art_suche:dev-master

Weiter wäre es evtl. besser, den Ordner “jakob” weg zu lassen, damit die composer.json auf oberster Ebene ist, wie beim hdi-Report.
Composer erstellt den Vendor-Order bei der Installation ggf. selbst.
Ob Composer die Unterordner durchsucht, habe ich so noch nicht ausprobiert.

Eigentlich wollte ich es nicht von github installieren, sondern wie im guide beschrieben per zip datei. Hab entsprechend ein “zip” ordner im “vendor” ordner erstellt und dort mein gepacktes modul reinkopiert.

Dann composer config repo.meinzip artifact ./vendor/zip ausgeführt, damit composer bescheid weiß und dann wollte ich wie oben beschrieben per composer require jakob/var_art_suche mein modul installieren, was dann zu dieser composer fehlermeldung führt. Sollte doch auch komplett ohne github möglich sein oder?

Normal tuhe ich mich nicht so schwer mit neuen sachen aber hier finde ich irgend wie nicht richtig rein … :confused:

Ist denn in der Shop - composer.json der Eintrag vorhanden:

"repositories": {
    "meinzip ": {
        "type": "artifact",
        "url": "./vendor/zip"
    }
}

Jap, der eintrag ist vorhanden, den hdi-report modul konnte ich auch so installieren -:wink:
Ich verstehe nicht wo mein fehler ist …

Wie die zip datei heißt spielt keine rolle oder?

Ich glaube ich passe erstmal die struktur, wie von dir oben erwähnt an.

Und was hat das mit dem eintrag aufsich? Der erste pfad OxidCommunity\\hdiReport\\, ist der freiwählbar?

"autoload": {
        "psr-4": {
          "OxidCommunity\\hdiReport\\": "../../../source/modules/oxcom/hdiReport"
        }
 }

Hi,

  • auf GitHub liegt deine composer.json immer noch nicht in erster Ebene. Mach es doch einfach so wie im hdi-Report, die Moduldateien liegen direkt auf erster Ebene im Repo. Composer installiert diese dann automatisch in “source/modules” in dem Verzeichnis, welches in der composer.json unter “target-directory” angegeben wurde.
  • in deiner composer.json gibt es keine Versionsnr., die wird aber bei der Installation aus der Zip vorausgesetzt.
  • Der Namespace kann schon frei gewählt werden, der in deiner composer.json sieht aber recht ungewöhnlich aus. Lege dich mal auf EINEN fest, auch auf immer gleiche Groß-/Kleinschreibung. Beispiel: Jakob/VarArtSuche
  • Nimm am besten das Modul als Muster, das ist deinem ähnlicher: AlwaysVat

Besten dank dir nickname. Ich hab mich strikt an die “vorgaben” von deinem modul gehalten und nun funktioniert es :slight_smile:

Was mich allerdings noch etwas irritiert sind die “vielen” unterschiedlichen schreibarten bei den pfaden, namespaces usw … Mal alles klein, mal alles mit dem erstbuchstaben groß und mal gemischt.

Nichtsdestotrotz, vielen dank für deine hilfe.