NAVI entwicklung

Was mache ich, wenn die Invoice PDF im Childtheme nicht funktioniert?

Es werden keine PDF Rechnungen und Lieferscheine ausgegeben, wenn ein Childtheme aktiviert ist. Es gibt keine Fehlermeldung im der EXCEPTION_LOG.txt.


Man schaue unter /out/name_childtheme/img, ob da eine Datei mit dem Namen pdf_logo.jpg vorhanden ist.

Diese ist wichtig sonst wird keine Rechnung erstellt.

 

Getested mit OXID eShop Version
CE 4.10.1

Apache Segmentation Fault Debugging

Beim Aufsetzten eines OXID (Backup) Shops mussten wir uns vor Kurzem mehrere Stunden mit einem Apache Segmentation Fault Error herumärgern.

[Sat Oct 17 23:57:45 2015] [notice] child pid 13850 exit signal Segmentation fault (11)

Die Details möchten wir euch an dieser Stelle erläutern, um auch evtl. anderen Problemsuchendenden eine Hilfestellung geben zu können.

Wie kam es dazu?

Nach der Installation eines neuen Backup-Servers mit einer Puppet-Konfiguration (identische Konfiguration wie der Live-Server) kam beim Aufruf des Shops eine weiße Seite. Also sind wir erst einmal die „üblichen Verdächtigen“ wie Datenbank-Verbindung, Verzeichnis-Schreibrechte, … durchgegangen, leider ohne Ergebnis. Auch in den „Ich erhalte im Shop eine weiße Seite, was nun?“ FAQ von D3 sind wir nich fündig geworden.

Wie debuggen?

Nachdem wir sicher waren, dass der Shop nicht das Problem sein kann, sind wir detailierter ins Debugging eingestiegen. Beim Deaktivieren einzelner Apache-Module hatten wir schliesslich Erfolg, sobald der IonCube-Loader inaktiv war. Jedoch hat uns das natürlich nichts genutzt, da dieser zum Betrieb des Shops (Drittanbietermodule) benötigt wird. Nach weiteren Tests und das Durchlesen vieler Forenbeiträge sind wir dann auf die Idee gekommen einen Stracktrace des Webserver-Aufrufes mitzuloggen.

mkdir /strace; ps auxw | grep apache2 | awk ‚{print“-p “ $2}‘ | xargs strace -o /strace/strace.log -ff -s4096 -r

Als Ergebis wurde ein LOG-File geschrieben (welches sehr schnell sehr groß werden kann), was uns jedoch den entscheidenden Hinweis lieferte (siehe Screenshot): es wurde mehrfach versucht, eine Datei „ac_module.php“ zu laden, welche jedoch physikalisch nicht verfügbar war. Nach vielfachen Versuchen hat der Apache Webserver „aufgegeben“ und einen Segmentation Fault im Apache-Errorlog dokumentiert.

Was war der Fehler?

Zum Debuggen eines Shop-Problems wurde das Modul oxid-module-internals im Live-Shop installiert, jedoch nicht ins GIT-Repository eingecheckt. Beim Einspielen des Shops auf dem Backup-Server wurde jedoch eine aktuelle Kopie der Live-Datenbank verwendet, in welchem das Modul aktiviert war. Durch das unvollständige Repository fehlten jedoch die eigentlichen Moduldateien.

Normalerweise hat OXID mit der oxModule-Klasse auch eine interne Logik, um fehlerhafte Module (wie z. B. in diesem Fall) automatisch zu deaktiveren. Nachdem das oben genannte Modul jedoch auch genau die gleiche Klasse oxModule erweitert, greift diese nicht und es kam zum oben genannten Fehler.


Exception und Error Log Viewer für OXID eShop

Wann immer etwas schief läuft, prüft man zuerst die Logs: logs/EXCEPTION_LOG.txt und webserver error log. Dafür verbindet man sich über SSH oder FTP mit dem Server, sucht die Dateien, lädt sie herunter und öffnet sie in einem Text-Editor.

Pro Log-Datei dauert es im Schnitt 15-30 Sekunden und benötigt 5 Mausklicks bis man den Log endlich sehen kann. Und das wiederholt sich einige Dutzend Male täglich…

Zeit ist Geld!

„dev-logs“ aus meiner vt-devutils Sammlung erweitert das OXID Admin Panel mit einem Log Viewer für OXID’s Exceptions und Webserver Errors!

Funktionsumfang:

  1. Logs anschauen ohne das Backend zu verlassen

  2. Such- und Filter-Funktion für Log-Einträge

  3. Log-Eintrag in die Zwischenablage kopieren

    Einträge aus exception_log.txt inklusive der Shop-Version können in die Zwischenablage kopiert werden.

Das Modul gibts hier:

http://marat.ws/vt-devutils/
Nach der Aktivierung der Module muss der Pfad zum webserver error log in den Moduleinstellungen eingetragen werden.
Aktuell funktioniert das Modul nicht gut mit dem erweiterten Logging von x-debug!


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.

Einstiegspunkt der Überprüfung

Abbildung 1: Einstiegspunkt der Überprüfung

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.

Ausgangspunkt für weitere Prüfungen

Abbildung 2: Ausgangspunkt für weitere Prüfungen

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.

Array aller Validators

Abbildung 3: Array aller Validators

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.

Ergebnis der Onlineabfrage

Abbildung 4: Ergebnis der Onlineabfrage

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 FreytagHendrik 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.


OXID Whitepages verhindern

Es kommt manchmal vor, dass die OXID-Datenbank Verweise auf Module enthält, die sich nicht im Dateisystem befinden. In diesen Fällen kann OXID die entsprechenden PHP-Klassen nicht laden und zeigt die Meldung „Shop offline!“ an.

Dieser Snippet registriert eine neue, zweite Autoloader-Methode, die nur aufgerufen wird wenn oxAutoload nichts findet. Wenn die angeforderte Klasse mit _parent endet, wird eine Dummy-Klasse erstellt damit die OXID-Modulverkettung nicht fehlschlägt.

Resultat: Shop läuft noch (zumindest wirft er keine Whitepages).


Kategoriebaum (nested sets) geht verloren

Wie in jedem Shop ist es auch im OXID eShop möglich, einen beliebigen Kategoriebaum zu erstellen.

Dies bedeutet es gibt Haupt- und Unterkategorien, welche auch wieder Unterkategorien enthalten können. Diese Funktion („nested sets„) wird in der OXID-Tabelle oxcategories mit den Feldern oxleft und oxright abgebildet. Detaillierte Informationen gibt´s im imva-Blog.

Leider berichten unterschiedliche Leute immer wieder von Problemen, dass genau diese Zuordnung verloren geht. Auch wir mussten deswegen gestern einige Zeit in das Debuggen investieren, was zu letztendlich folgendem Eintrag im OXID Bugtracker gehführt hat:

0004864: Updating of the Category-Tree fails if AdminChangeLog is enabled

Kurz beschrieben: Aktiviert man das Admin-Log (alle Aktionen im Shop-Admin werden in der Tabelle oxadminlog festgehalten) verlieren alle Kategorien bei der nächsten Bearbeitung (z. B. neue Kategorie anlegen) Ihre Zuordnungen und die gesamte Navigation ist defekt.

Nutzt man nun weiterführende Module für die Navigation, z. B. Umschreibung von SEO-URLs oder modulbasierte Navigation mit SOLR entstehen lauter unkontrollierbare SEO-URLs, welche den Shop nicht mehr navigierbar machen.

Leider ist der Bug, aufgrund der Verwendung von ADODBlite nicht so einfach lösbar. OXID hat zumindest im Bugtracker einen Hotfix zur Verfügung gestellt.


psErrorLog – kostenloses Modul für PHP-Fehler

pserrorlog_screenshot

Wer kennt sie nicht, die weiße Seite im OXID-Shop?

Jeder der sich schon ausgiebig mit der Shop-Entwicklung befasst hat sieht oft mal nur weiß. Dies liegt meistens daran, dass ein Fehler auftritt und keine (PHP)-Fehlermeldungen ausgegeben werden. Was tun? Erst einmal in die EXCEPTION.log sehen ob hier evtl. ein Eintrag zu finden ist.

Wenn nicht dann das PHP-ErrorLog und/oder Webserver-Log ansehen. Hierzu muss man sich jedoch erstmal per FTP auf den Server verbinden um die Dateien lesen zu können. Mit unserem Modul psErrorLog haben Sie die Möglichkeit die PHP-Fehler direkt im Shop-Admin einzusehen.

Die kostenlose Erweiterung kann auf github heruntergeladen werden:

http://proudcommerce.github.io/psErrorLog/

Weitere Informationen zum Thema haben auch die Kollegen von D3 im Blog zusammen gefasst.


"Module kann nicht aktiviert werden" in Oxid eShop beheben — Modulkonfiguration zurücksetzen und Fehler aufspüren

Wer Module für den Oxid eShop entwickelt und dabei laufend Informationen zur metadata.php hinzufügt, verändert und möglicherweise auch Speicherort oder ID des Moduls verändert, kann unter Umständen die Meldung „Module kann nicht aktiviert werden“ erhalten. Abhilfe schafft hier entweder die aufwendige Neuregistrierung des Moduls unter einer neuen ID oder das Zurücksetzen der Modulkonfiguration im Shop-System.

Da hierfür ab Werk kein Hilfsmittel bereitsteht, muss man selber in die Datenbank greifen. In einem Verwaltungswerkzeug wie phpMyAdmin oder auf der Konsole können Sie einmal alle Zeilen der Tabelle oxconfig ausgeben lassen, die das Wort „module“ enthalten. Darin sind nämlich die Konfigurationseinstellungen für die Shop-Erweiterungen gespeichert.

Die Ausgabe müsste so aussehen (hier eine Oxid CE 4.7.2):

image

Die Zeilen mit sUtilModule und aModuleEvents sind an dieser Stelle nicht relevant. Falls Sie eine ältere Version des Oxid eShops einsetzen, kann es sein, dass Zeilen gar nicht vorhanden sind – nehmen Sie diese von der Löschung einfach aus. Legen Sie eine Kopie der Tabelle oxconfig an, bevor Sie fortfahren!

Um die komplette Konfiguration zu löschen, können Sie den folgenden Befehl ausführen:

Sie können diesen Befehl in Ihrem Verwaltungswerkzeug oder auch im Shop-Admin unter “Service”—>”Tools” ausführen. Erstere Option ist vor allem dann praktisch, wenn der Shop wegen eines defekten Moduls gar nicht mehr funktioniert.

Gehen Sie nun im Oxid-Admin zu “Erweiterungen”—>”Module” und aktivieren Sie nacheinander die Module, die benötigt werden.

Fehler in der Modulkonfiguration (metadata.php) finden

Bei der Fehlersuche ist das Oxid-Modul Module Internals von Alfonsas Cirtautas sehr hilfreich. Es erweitert die Modulverwaltung im zusätzliche Registerkarte, worüber die Angaben in der metadata.php ausgewertet werden können.

image

Befinden sich in der metadata.php angegebene Dateien nicht am erwarteten Platz, so wird das farblich angezeigt. Nach der Behebung des Problems (Abändern der Datei oder Korrektur der Pfade) wird die Korrektur mit Klick auf die Schaltfläche „Fix“ angewandt. Wenn jetzt alles stimmt, werden die Pfade in grüner Farbe angezeigt und das Modul sollte funktionieren.

 


fehlende Browser-Titel ab Version 4.5.x

Den Meisten ist es anscheinend noch gar nicht aufgefallen, nachdem es bis jetzt keinen Support-Thread oder Bug-Eintrag dazu gab.

Seit der OXID eShop Version 4.5.x werden bei Klassen wie basketordercontact, … keine vollständigen Browser-Title () mehr angezeigt. Wo früher einmal „Warenkorb“ stand ist aktuell gähnende Leere 😉

Eine Möglichkeit diesen Fehler zu beheben geht wie folgt: Titel im Template (z. B. basket.tpl) definieren

[ { assign var=“template_title“ value=“Warenkorb“ } ]

und Abfrage in layout.tpl erweitern

[ {assign var=“_sMetaTitle“ value=$oView->getTitle() } ]
[ { if $_sMetaTitle == „“ } ]
[ {assign var=“_sMetaTitle“ value=$template_title } ]
[ { /if } ]

Ab sofort wird der vollständige Titel wieder dargestellt. Ein Eintrag im OXID-Bugtracker ist übrigens eröffnet …
UPDATE 04.12.12: OXID hat den Bug bestätigt und behoben. Mehr dazu im Bugeintrag.


Bugfix für fehlgeschlagene Kreditkartenbestellungen mit der Payone-Schnittstelle für OXID im IE8

Alle OXID-Formulare werden mit der “oxinputvalidator”-JS Bibliothek validiert. PayOne erweitert die Validierung um z.B. die Länge der Kreditkartennummer zu überprüfen. Die entsprechenden Erweiterungen befinden sich in den Dateien: /modules/fcPayOnce/out/blocks/fcpo_payment_override.tpl und in fcPayOne.js. Die Validierungsskripte liefern immer WAHR oder NICHT WAHR zurück. WAHR = Formular abschicken. NICHT WAHR = Fehlermeldung anzeigen.

Firefox & Webkit-Browser führen den Code wie folgt aus:

Payone-Validierung => OXID-Validierung.
d.h. Die KK-Länge & Prüfziffer werden als erstes geprüft. Falls irgendwas nicht stimmt, wird eine Fehlermeldung angezeigt.

IE führt wiederum die Validierung umgekehrt aus:
OXID-Validerung => Payone-Validierung

d.h. die OXID-Validierung prüft alles, stellt fest, dass alles in Ordnung ist und liefert WAHR zurück. Die Payone-Fehlermeldung wird angezeigt, allerdings schickt IE trotzdem das Bestellformular ab, da TRUE schon zurückgeliefert wurde.
Um den Fehler zu beheben, muss einfach die OXID-Validierung deaktiviert werden in dem man die Klasse “js-oxValidate” vom Bestellformular entfernt:

fcpo_payment_override.tpl:

ersetzen durch

 


OXID Module Debug-Modul

oxidmoduldebug

Wie der Posttitel schon verrät gibt es ein Modul mit welchem man die Modul-Einträge ab der Shop-Version 4.6.x debuggen kan. Bis dato ist hier noch ein Bug vorhanden, auf welchen die Kollegen von shoptimax bereits hingewiesen haben.

Download

Einfach die ZIP-Datei entpacken und das Verzeichnis moduledebug in das /modules-Verzeichnis eures Shops kopieren.

Das Modul wurde zwar von OXID eSales veröffentlicht, jedoch ist folgendes zu beachten:

[…] Das Modul […] ist eigentlich noch nicht freigegeben. Wir wissen, dass noch ein paar Fehler drin sind und wollten das noch nicht rausgeben. […] Dennoch: keine Gewährleistung (is eh GPL), kein Support […]

UPDATE: Einer der OXID-Core-Entwickler hat ein weiteres Modul zum Debuggen zur Verfügung gestellt.


Fehlerhaftes Apache mod_rewrite Modul im Oxid Shop

Es tritt folgendes Problem bei einem sonst stabil laufenden Oxid-Shop auf:

Nach dem Einloggen im Backend erhalten Sie eine Warnmeldung aufgrund fehlerhafter Systemgesundheit. Das Apache mod_rewrite Modul steht nun auf rot, ihr seid euch sicher, dass das Modul auf on ist und ihr habt grad keinen Plan, wie man das beheben kann. Die Hauptseite des Shop wird mit etwas Glück noch angezeigt. Mit etwas weniger Glück passiert im Frontend vielleicht sogar gar nichts mehr.

Ein Lösungsansatz könnte sein:

Bitte überprüft, ob im eurem Shophauptverzeichnis die .htaccess Datei vorhanden ist (via ftp).  Sollte sie nicht da sein (weil diese irrtümlich gelöscht wurde oder aus irgendeinem anderen Grund abhanden gekommen ist), habt ihr den Fehler schon gefunden.

Hierfür gibt es leichte Abhilfe:

Ladet euch einfach z.B. eure Oxid CE Version (http://www.oxid-esales.com/en/community/download-oxid-eshop.html) hier herunter, entpackt die Dateien und ladet die dort vorhandene .htaccess Datei in das root Verzeichnes eures Shops.

Wenn ihr nun im Backend die Systemgesundheit überprüft, sollte das Apache mod_rewrite Modul nun auf grün stehen.

So geschehen und gelöst bei mir…