Viel neues mit OXID6

 

Oxid hat viel geändert mit der neuen Version. Zu erwähnen ist hier die Einführung von Namespaces, PHP 7.x Kompatibilität als auch der Einsatz von Composer. Wer sich nun die Verzeichnisstruktur einer sauberen 6er Community Edition im Vergleich zu der alten 4er ansieht, wird sicherlich staunen. OXID hat die Ordner Logik massiv angepasst. Der OXID Core, als auch Drittanbieter Funktionalitäten, findet sich nun im sogenannten „Vendor“ Ordner wieder. Template, Module dagegen finden sich im „Source“ Ordner.

 

Wozu ein Modulupdate? Die alte Version läuft doch!

 

Ja, das ist aktuell noch richtig. OXID hat hier noch eine Backward Kompatibilität integriert, die aber nicht auf dauer enthalten sein wird. Das heißt wenn der Shop in regelmäßigen Abständen upgedatet wird, kommt es sicherlich bald vor, das alte, bisher laufende, Module den Geist aufgeben und im schlechtesten Fall den ganzen Shop abschießen. Dies kann nur umgangen werden, wenn die Module upgedatet werden.

Wieso Updates generell wichtig sind kannst du in unserem Beitag „Warum ein Shopupdate so wichtig ist“ nachlesen

 

Okay klingt alles schön und gut aber…

 

„Ja das klingt alles gut, aber ich bin kein Tekki, könnt ihr das machen?“ Diese Frage können wir mit einem ganz klaren „JA“ beantworten. Einfach jetzt Kontakt mit uns aufnehmen!

Jetzt Kontakt aufnehmen

 

Das Update im einzelnen

 

Ein OXID Modul Update ist kein Hexenwerk, man muss es nur einmal verstanden haben. Wir versuchen hier einen kleinen Umriss, vereinfacht, darzustellen:

 

Die Metadata.php

Kern jeden Modules ist die metadata. Früher war diese in Version 1.0 angegeben. Wer hätte gedacht das nach all diesen Jahren sich hier noch etwas ändern wird? Die aktuelle Metadata Version ist nun 2.1.

 

Was hat sich hier geändert?

In Version 1.0/(2.0) wurde das Array mit den Einträgen mit „()“ definiert. Seit Version 2.1 muss nun „[]“ verwendet werden.
Beispiel:

Version 1.0:

$aModule = array(
    'id'           => 'mxajaxsearch',
    'title'       => (
        'en' => '[<span style="color:blue;">mae</span><span style="font-weight:bold;">X</span><span style="color:blue;">ware</span>] Ajax Suche',
        'de' => '[<span style="color:blue;">mae</span><span style="font-weight:bold;">X</span><span style="color:blue;">ware</span>) Ajax search',
    ),

Version 2.1:

$aModule = [
    'id'           => 'mxajaxsearch',
    'title'       => [
        'en' => '[<span style="color:blue;">mae</span><span style="font-weight:bold;">X</span><span style="color:blue;">ware</span>] Ajax Suche',
        'de' => '[<span style="color:blue;">mae</span><span style="font-weight:bold;">X</span><span style="color:blue;">ware</span>] Ajax search',
    ],

 

Die Pfade

Statt wie früher einfach nur das zu extendende File von OXID anzugeben ist hier der namespace anzugeben:

Beispiel alte OXID Versionen:

'search' => 'mx/bootstrapcms/Extensions/Application/Controller/mx_search.php'

Beispiel OXID 6.x:

\OxidEsales\Eshop\Application\Controller\SearchController::class            => \maexware\bootstrapcms\Extensions\Application\Controller\mx_btstcms_utils::class,

 

Die meisten Klassennamen

 

Im großen und ganzen haben sich eigentlich alle Klassennamen bei OXID geändert. Nun warum funktionieren dann aber noch eigentlich nicht auf OXID6 upgedatete Module? Das liegt daran das OXID hier eine praktische Rückwärtskompatibilität geschaffen hat. Welche klassen nun wie heißen zeigt euch entweder eure IDE oder aber ein Blick in entsprechendes File: htdocs/vendor/oxid-esales/oxideshop-ce/source/Core/Autoload/BackwardsCompatibilityClassMap.php

Ein kleiner Ausschnitt der gut zeigt wie hilfreich das File sein kann:

return [
    'oxcmp_basket'                        => 'OxidEsales\\Eshop\\Application\\Component\\BasketComponent',
    'oxcmp_categories'                    => 'OxidEsales\\Eshop\\Application\\Component\\CategoriesComponent',
    'oxcmp_cur'                           => 'OxidEsales\\Eshop\\Application\\Component\\CurrencyComponent',
    'oxcmp_lang'                          => 'OxidEsales\\Eshop\\Application\\Component\\LanguageComponent',

Namespaces und Use

 

Einer der wohl größten Änderungen sind die jetzt verwendeten Namespaces. Viele Aufrufe müssen mittlerweile vorher mit einem use OXIDFILENAME; vorher ermöglicht werden. Beispielsweise wurde früher ein oxconfigparam Wert wie folgt ausgelesen:

oxregistry::getConfig()->getConfigParam('myname');

Seit OXID6 geht es nun wie folgt:

<?php namespace ... use OxidEsales\Eshop\Core\Registry; ... public function fncName() { // Your stuff and functionality Registry::getConfig()->getConfigParam('myname');
}

Features die in eigene Module ausgelagert wurden

 

Code oder Funktionen werden nicht nur entfernt weil diese „Deprecated“ sind sondern auch weil diese einfach Ausgelagert wurden. Gutes Beispiel Captchas, dieses ehemalige Kernfeature ist nun Bestandteil von OXID Projects und wird separat gepflegt. Ebenso die Tags, PDF Invoice oder das Gästebuch.

Wer also Module im Einsatz hat, die auf diesen Features aufbauen, wird beim Update der Module erstmal verwundert sein.

Datenbank

 

Hier hat sich vom Gefühl her das meiste getan. Durch die Umstellung auf PDO muss fast jedes Statement bzw, jeder Code Block der sich mit DB Operationen beschäftigt angepasst werden.

oxDb wird zu DatabaseProvider

oxDb::getDb()

wird zu

\OxidEsales\Eshop\Core\DatabaseProvider::getDb()

Unterscheidung zwischen select und execute

Es ist nun essenziell die richtige Funktion für sein SQL Statement zu verwenden. „SELECT“ Statements die mit einem execute(*) abgesetzt werden laufen in einen Fehler. Lesende Statements mit select(*) und Schreibende mit execute(*)

Verarbeitung von SQL Ergebnissen

Einige Funktionen wurden ersetzt  bzw, ersatzlos entfernt.

$rs->recordCount() wird zu $rs->count()

$rs->moveNext() wird zu $rs->fetchRow()

move(), moveNext(), moveFirst(), moveLast(), _seek() und EOF() wurden entfernt

Gesamt Beispiel:

OXID 5

$rs = oxDb::getDb()->select($sQuery);
if ($rs != false && $rs->recordCount() > 0) {
    while (!$rs->EOF) {
        //do something
        $rs->moveNext();
    }
}

OXID 6

$rs = \OxidEsales\Eshop\Core\DatabaseProvider::getDb()->select($query);
 if ($rs != false && $rs->count() > 0) {
     while (!$rs->EOF) {
         $row = $rs->getFields();
         //do something
         $rs->fetchRow();
     }
 }

PHP MySQL Funktionen

Funktionen wie „mysql_real_escape_string()“ sind durch den Einsatz von PHP 7 und PDO ersatzlos gestrichen worden.
Um seinen Code und seine DB gegen SQL Injections zu schützen sollten nun Prepared Statements verwendet werden.

$db = \OxidEsales\Eshop\Core\DatabaseProvider::getDb();

$sql = "INSERT INTO MyTable(FIELD1, FIELD2) values(?,?)";
$db->execute($sql, array($FIELD1Value, $FIELD2Value));

Alternativ kann auch ein \OxidEsales\Eshop\Core\DatabaseProvider::getDb()->quote() verwendet werden, aber das ist nicht die beste Lösung.

 

Und wahrscheinlich vieles noch nicht erwähntes

 

Updates eines OXID Moduls ist wirklich kein Hexenwerk. Eher Arbeit, die unbedingt gemacht werden sollte!

Haben wir nicht alle Punkte abgedeckt und es gibt noch fragen? Beispielsweise zu Modulintegration mit Composer? Ein Modul selber schreiben und über Composer verfügbar machen? Dann einfach uns anschreiben und fragen!

Jetzt Kontakt aufnehmen

 

Wieso erst jetzt ein Beitrag zu dem Thema?

 

Es stimmt viele haben sich bereits diesem Thema angenommen, auch wir haben auch diese Beiträge gelesen. Jedesmal haben wir jedoch eine Information vermisst oder haben im Laufe von Modul und Shopupdates neue Erkenntnisse gesammelt die wir mit euch teilen möchten.

Weiterführende Infos