Jan 25

Im aktuellsten OXID eShop 4.7 (PE/CE) bzw. 5.0 (EE) gibt es einige Erneuerungen, u. A. auch die Widgets.

Als wir uns die letzten Wochen in die neuen Versionen eingearbeitet haben, entstand auch ein kleines Widget namens smxActions. Hiermit ist es möglich eine beliebige Shop-Aktion, an einer beliebigen Stelle im Shop-Frontend anzuzeigen.

Die Installation ist sehr einfach:

  1. Modul herunterladen
  2. Moduldateien aus copy_this in das Shop-root laden
  3. Modul aktivieren
  4. FERTIG

Eine Aktion im Template kann dann wie folgt eingebunden werden:

[{ oxid_include_widget cl="smxActions_widget" action="oxtop5" }]

Benötigt wird hierzu die OXID der Aktion, in diesem Fall “oxtop5″.

 

Dez 27

Hin und wieder kommt man an einen Punkt, an welchem es praktisch wäre, eine mühsam im OXID eShop Administrationsbereich eingebaute Funktionalität auch von außen, z.B. automatisiert per CRON-Job aufrufen zu können. Als Beispiel sei ein im Admin-Bereich realisierter Artikel-Import genannt (z.B. per CSV). Hier macht einem dann spätestens die Tatsache Probleme, dass der komplette Admin-Bereich per Passwortschutz abgeriegelt ist und man die gewünschte Klasse nicht einfach so aufrufen kann – stattdessen wird man beim Versuch zum Admin-Login weitergeleitet.

Nun könnte man die gewünschte Funktionalität z.B. in einen Frontend-View und ggf. zusätzliche, gemeinsam mit dem Backend genutzte Core- bzw- Helper-Klassen einbauen, um das Problem zu umgehen. Oder man überschreibt einfach die “problematische” Stelle im gewünschten Admin-Modul :) Das wollen wir uns mal näher ansehen. Weiterlesen »

Sep 24

Da hat man nun ein neues OXID Modul Package mittels neuem Modul-Installer im OXID eShop 4.6.+ installiert, die shop-erweiternden Klassen schön in seine metadata.php eingetragen und stellt plötzlich fest, dass man eine Modul-Klasse eigentlich gar nicht benötigt oder gerne umbenennen möchte… ok, denkt man sich, ändere ich halt die metadata.php nochmal, flugs hochgeladen auf den Shop-Server, Modul deaktivieren und nochmal neu aktivieren und alles passt. Oder? Denkste – OXID vergisst leider das “alte” Modul nicht, sondern lässt es brav in der Datenbank eingetragen, obwohl es in der metadata.php nicht mehr oder nun mit anderem Namen drinsteht :(

Keine Chance, es über die Metadata Datei wieder herauszubekommen – aber es gibt zwei Workarounds:

  1. Modul deaktivieren, die zugehörigen Moduleinträge per SQL aus der Datenbank löschen, Modul neu aktivieren, das ist allerdings unschön und fehleranfällig und man muss ggf. alle Module im Shop neu installieren
  2. einfacher und effektiver: die nicht mehr gewünschte Modul-Klasse auf dem Shopserver löschen oder zumindest umbenennen – dann merkt OXID, dass die Datei nicht mehr vorhanden ist und fragt nach, ob man den zugehörigen Moduleintrag gerne löschen möchte… “ja, ich will!” :)

Happy coding! :)