Archives » OXID



WBL Autoloader und OXID 4.6.0

Falsche Modulansicht

Falsche Modulansicht

Vor OXID 4.6.0 musste man sich seine Modulketten im Backend selbst zusammenstellen. Nun hilft einem das Backend dabei. Unser Autoloader durchkreuzte da ein bisschen die Pläne seitens OXID. Er funktionierte weiterhin wunderbar, aber die Aussage im Backend waren für den Benutzer nicht einleuchtend.

  • Module werden unter unserem Kürzel in der Liste gruppiert.
  • Warnmeldung im unteren Frame zur Deaktivierung.

Diese “Probleme” haben wir nun behoben:

  1. Wir haben die metadata.php für den WBL_Modules -Ordner angelegt.
  2. Das Modul WBL_Modules_ModuleList sorgt dafür, dass der Autoloader in der Liste als aktiv angezeigt wird und die “Entfernen”-Warnmeldung im unteren Frame nicht mehr erscheint. (Leider auf den ersten Blick n kleineren OXID-Bug gefunden.)
  3. Und die vendormetadata.php im WBL-Ordner sorgt dafür, dass der WBL-Ordner nicht mehr als direkter Modulordner verstanden wird. OXID schachtelt jetzt noch eine Ebene tiefer und versteht den WBL-Ordner nur noch als Hersteller-Ordner. Dies muss für alle “Hersteller”-Ordner gemacht werden, wobei die  vendormetadata.php dabei noch leer sein darf.
  4. Unittests sind auch aktualisiert worden. Unser Modul für die oxModuleList schließt natürlich auch mit 100% Codeabdeckung ab.
Moduldarstellung

Korrekte Moduldarstellung nach 4.6.0 Update

>> Unseren Autoloader downloaden

Datenbankverbindung beim Unittesting reloaded

Ich musste in meinem Posting Datenbankprobleme beim OXID-Unit-Testing ja bereits von kleinen Komplikationen mit meiner Testumgebung berichten. Bei OXID 4.6.0 ist es nach Tagen ohne Probleme hier plötzlich auch aufgetreten. Irgendwo verschluckt sich meine VMWare.

Mein alter oxDB::getDb() – Fix ist bei OXID 4.6.0 tot und führt zu einer Endlosschleife, daher sieht meine Empfehlung für OXID 4.6.0 diesmal so aus:

Beste Grüße
Björn

Facebook Shop Modul

Ich habe es in der Vorstellung angedroht, ab und zu kommt auch ein bißchen Werbung. Ich habe euch das Autoloader 4.6.0 Posting versprochen. Ja, der Autoloader wird gerade mit “oxModule” verknüpft und zwar im 4.6.0 Update unseres Facebook-Shop-Moduls, daher braucht das Posting noch ein bißchen.

Unser WBL Facebook Shop Modul ermöglicht euch die Implementierung eures Shops im Facebook-Kontext ohne weitere Schnittstelle. Das gleiche Backend, der gleiche Artikelbestand, die gleichen User-Daten und mit OXID 4.6.0 funktioniert hoffentlich der Facebook Connect auch wieder besser.

Unser OXID Autoloader

Jeder von uns Programmierern ist eigentlich bestrebt, wenig zu wiederholen und viel wiederzuverwenden. Wir überlegen uns meistens möglichst schöne Klassenstrukturen in denen wir unsere Logiken so kapseln, dass wir sie hoffentlich wiederverwenden können. In letzter Zeit springe ich zwischen einigen OXID Todos und stehe gefühlt jedes Mal vor dem Schritt bestehende Strukturen zu kombinieren oder Strukturen auf der grünen Wiese neu zu pflanzen. Und jedes Mal ist der OXID-Autoloader auch wieder ein Thema.

(mehr …)

Datenbankprobleme beim OXID-Unit-Testing

Mensch, eine Stunde verbraucht mit der Fehlersuche.

Ich stolpere grad über Datenbank-Probleme beim Unit-Testing einer aktuellen OXID-Version und bin auch mit einer ausgiebigen Google-Recherche und dem Wühlen in der OXID-Mailingliste nicht fündig geworden. Da die Testumgebung von OXID zur Modulzertifizierung leicht veraltet ist, teste ich meine Module gegen ein halbwegs aktuelles Debian 6 mit PHP 5.3 auf dem neuesten VMWare Player und irgendwann, wirklich irgendwann im Testlauf, ist plötzlich in der Connection-ID des Datenbankobjekts keine Resource mehr zu finden, sondern nur noch ein Integer-Wert. (mehr …)