Schnell und effizient in PHP entwickeln mit OXID eShop und Xdebug
Schnell und effizient in PHP entwickeln mit OXID eShop und Xdebug
Die OXID Plattform ist ein skalierbares und modulares E-Commerce System, welches an unterschiedliche Geschäftsmodelle angepasst werden kann. Durch den modularen Aufbau eröffnen sich dem Betreiber beinahe unbegrenzte Möglichkeiten die Funktionalität individuell zu erweitern und zu modifizieren. Für effizientes Entwickeln von eigenen Modulen, vor allem in komplexen Systemlandschaften ist der Gebrauch von professionellen Entwickler-Tools empfehlenswert.
Im folgenden Beitrag soll die Verwendung von Xdebug im OXID eShop erläutert werden. Eine allgemeine Beschreibung zur Installation und Konfiguration der beiden PHP-Entwicklungsumgebungen Eclipse und PhpStorm finden Sie hier. Bei Xdebug handelt es sich um eine Erweiterung von PHP, die eine Möglichkeit zum Debuggen (Fehleranalyse) bereitstellt. Aber nicht nur zum Analysieren von Fehlern ist Xdebug interessant. Da sich mit dem Tool die Funktionsweise einer Web-Applikation wie OXID eShop einfacher nachvollziehen lässt, ist es ein wertvolles Werkzeug für jeden PHP-Entwickler.
Der nachfolgende Abschnitt beschreibt den Prozess des Debugging anhand eines konkreten Beispiels im OXID eShop. Der Aufruf des OXID-Frameworks findet in der Regel folgendermaßen statt: In der oxseo.php wird die URL decodiert und die index.php geladen. Diese bindet über die bootstrap.php u.a. die Konfiguration ein und gibt anschließend über die oxid.php an oxshopcontrol.php weiter. Erst in oxshopcontrol.php wird dann der benötigte Controller geladen. Bis hierher ist der Ablauf immer gleich. Deshalb kann man den Anfang auslassen und sollte möglichst den Breakpoint an der Stelle setzen, die man mit dem Tool untersuchen möchte. Als möglichst früher Breakpoint, der aber die Initialisierung auslässt, bietet sich der Anfang der Funktion oxShopControl::_process an.
Ein mögliches Vorgehen zum Finden eines Fehlers soll am Beispiel der Umsatzsteuer ID-Prüfung gezeigt werden. Nehmen wir als Beispiel eine fehlgeschlagene ID-Prüfung, die mit Xdebug untersucht werden soll. Normalerweise wird die Umsatzsteuer-ID abgelehnt, wenn der Benutzer eine ungültige ID eingibt. Es wird mit Hilfe eines Online-Services überprüft, ob die eingegebene ID korrekt ist. Wenn jedoch häufig auf den ersten Blick korrekte IDs abgelehnt werden, muss das genauer untersucht werden. Da die Prüfung unter anderem während des Bestellvorgangs bei der Adresseingabe stattfindet, wird durch einen Blick in den Quelltext der Seite ersichtlich, dass der Button zum Absenden der Adresse die Funktion oxcmp_user::createUser() aufruft.
Nachdem ein Breakpoint in die erste Zeile gesetzt wurde, kann es losgehen. Wird ein Artikel in den Warenkorb gelegt und die Adresse in Bestellschritt 2 abgesendet, geht die Kontrolle an den Debugger. Zunächst wird untersucht, was bei einer völlig falschen ID passiert (z.B. „keine USt-ID!“ als USt-ID). Mit der Funktion Step Over ist die in Abbildung 1 gezeigte Stelle schnell erreicht.
Da die Funktion checkValues() offensichtlich die Prüfung startet, wird hier mit Step Into hineingesprungen. Irgendwann ist mit dieser Strategie (unintessantes Überspringen, bei interessantem Step Into) die Funktion oxCompanyVatInValidator::validate() erreicht. In dieser Funktion werden verschiedene Überprüfungen aufgerufen.
Um die Umsatzsteuer-ID-Prüfung zu untersuchen, werden mehrere Durchgänge durchgeführt. Da diese Funktion Ausgangspunkt für mehrere Überprüfungsmethoden der Umsatzsteuer-ID ist, bietet es sich an den Breakpoint an einer neuen Stelle zu setzen (siehe Abb. 2, Zeile 130) und den vorherigen zu löschen. In der darauffolgenden Schleife werden mehrere Validators (jeder Validator prüft einen bestimmten Aspekt der ID) aufgerufen, die sich im Array $aValidators befinden. Ein Blick auf die derzeitige Belegung der Variablen (Abb. 3) zeigt, dass es dort zwei Einträge gibt. Mit Step Into lassen sich die jeweiligen validate()-Funktionen überprüfen. Im Fall der völlig falschen USt-ID gibt schon der erste Validator (oxCompanyVatInCountryChecker) ein ungültiges Ergebnis zurück. Eine Onlineprüfung wird also gar nicht durchgeführt.
Die (falsche) USt-ID DE 0815 wird bei einem neuen Versuch im nächsten Anlauf diese erste Hürde nehmen. Hier wird letztendlich der oxOnlineVatIdCheck fehlschlagen. In dessen validate()-Funktion lässt sich der Call zum Onlinedienst nachvollziehen. In der Variablenübersicht stehen alle Belegungen, also sind auch alle Parameter erkennbar. Außerdem steht nach dem Call dort auch das Ergebnis (Abb. 4). Zu erkennen ist hier, dass der countryCode und die vatNumber wie eingegeben richtig übernommen wurden. Der Onlineservice hat dann aber festgestellt, dass die USt-ID falsch ist.
Mit dem Beobachten der Variablen vor und nach dem Onlineabruf sollte also herauszufinden sein, warum eine USt-ID nicht angenommen wurde. Oder womöglich war die Struktur der eingegebenen USt-ID falsch, sodass es gar nicht erst zu der Onlineprüfung gekommen ist. Am Beispiel der Onlineprüfung der USt-ID wurde also gezeigt, wie der Debugger helfen kann, Licht ins Dunkel einer unbekannten Funktion zu bringen.
Häufig ist der Weg über den Debugger schneller, als in Foren oder anderen Informationskanälen zu suchen, wo der Fehler liegen könnte. Denn das Problem kann auch in einem speziellen Verhalten der eigenen Systemumgebung liegen, die kein anderer kennt. Der Debugger zeigt aber Stück für Stück, wie sich die Software verhält, so dass so gut wie jedes Problem zu finden sein sollte. Wir setzen diese hilfreichen Tools im OXID Support täglich ein, um komplexe technische Probleme, die im Zusammenhang mit Kundenanfragen stehen, zu analysieren.
Weitere Informationen zur Installation und Konfiguration von Xdebug, auf dem Server und in den beiden oben genannten Entwicklungsumgebungen finden Sie hier.
Autor
Hendrik Freytag hat während seines Informatikstudiums an der Technischen Universität Carolo-Wilhelmina zu Braunschweig, das er mit einem Masterabschluss (M.Sc.) 2014 erfolgreich beendete, ein umfassendes Wissen in der Informationstechnik aufgebaut. Er verfügt über umfangreiche Kenntnisse in OOP, PHP, Java, Unix und Datenbanken. Seit 2014 ist er als Support Account Manager für die technische Betreuung von Großkunden im internationalen Umfeld tätig.