Weiße Seite nach Bestellabschluß

Nun hat es mich erwischt. Es erscheint nur eine weiße Seite nach dem Bestellabschluß. Es wird index.php? übergeben. Erst nach dem neuladen wird die index.php?cl=thankyou& übergeben. Der fck-editor wurde deaktiviert, die oxorder.tpl neu eingespielt und auch die CMS Texte wurden überprüft. Das Thema wurde wohl schon mehrfach angesproch, ohne dass nun wirklich mal eine Lösung erkennbar ist.

Momentan weiß ich nun nicht mehr weiter.

Welche Shopversion?

[QUOTE=wthimm2000;25824]Nun hat es mich erwischt. Es erscheint nur eine weiße Seite nach dem Bestellabschluß. Es wird index.php? übergeben. Erst nach dem neuladen wird die index.php?cl=thankyou& übergeben. Der fck-editor wurde deaktiviert, die oxorder.tpl neu eingespielt und auch die CMS Texte wurden überprüft. Das Thema wurde wohl schon mehrfach angesproch, ohne dass nun wirklich mal eine Lösung erkennbar ist.

Momentan weiß ich nun nicht mehr weiter.[/QUOTE]
Nun, [B]eine [/B]Lösung dafür wird es auch nie geben können, da dafür die unterschiedlichsten Ursachen verantwortlich sein können.

Auch hier wieder meine (seit nunmehr 10 Monaten bestehende) Forderung an die OXID AG: bringt endlich das “Exception-Handling” auf Vordermann (genauer: die Kommunikation über die Ursache von Exceptions), so dass auch ein Shopbetreiber Hinweis darauf bekommt, [B]was[/B] die Ursache einer Exception ist.

Bei einem Fehler einfach kommentarlos die Arbeit einzustellen, ist [B]sicher [/B]keine akzeptable Strategie!

Mir fällt echt nichts mehr dazu ein, warum hier nicht [B]blitzartig [/B]nachgebessert wurde/wird…

Vor allem, weil das alles andere als schwierig ist.

Statt fruchtlose Diskussionen um das “Next generation Shop-Design”, “CSS Frameworks”, “Zend Framework ja oder nein” und andere esoterische Dinge zu führen, sollte man sich erst mal um die [B]wirklich [/B]wichtigen Dinge kümmern.

Und nicht Legionen von Shopbetreibern vor ihren weißen Seiten hängen zu lassen.

Aber das ist wohl zu mühsam und unspektakulär.

Es gibt genügend (auch eigentlich “Showstopper”-) Bugs, die der Erledigung harren, aber schon Software Generationen überdauert haben (laramarco hat dazu ja immerwieder etwas beizusteuern)…

[B]Meine Forderung daher: [/B]

[B]die Version 4.3 sollte nicht ausgeliefert werden, bevor hier nicht endlich sinnvoll nachgebessert wurde![/B]

(Was die Auslieferung aber höchstens um Stunden verzögern sollte…)

Mir ist das letztendlich egal, weil ich für mich (und andere für sich) schon die notwendige Abhilfe geschaffen (und im Forum auch mehrfach dokumentiert) habe(n).

Für die Shopbetreiber aber eben oft ein unüberwindliches Hindernis.

Aber um zum konkreten Problem zurück zu kehren:

Füge am Anfang der “[B]_header.tpl[/B]” folgenden Code ein, um das (deaktivierte) PHP Error-Reporting wieder zu aktivieren:

[{php}]
error_reporting(E_ALL ^ E_NOTICE);
[{/php}]

Dann bekommt man zumindest schon mal wieder PHP-Fehlermeldungen, die auch Folge von Template-Fehlern sein können…

Und in der “[B]config.inc.php[/B]” setze “[B]$this->iDebug = 3;[/B]”, um das Exception- und Fehler-Reporting zu aktivieren.

Mit etwas Glück bekommt man dann auch in “[B]log/EXCEPTION_LOG.txt[/B]” einen Hinweis auf Fehlerursachen.

Hallo avenger,

vielen Dank für Deine Hinweise. Auf diese Weise konnte ich das ipayment Modul als Verursacher ausfindig machen. Nach der deaktivierung läuft die Bestellung nun durch.

Da kann ich Avenger nur absolut beipflichten!

Das Error-Handling in seiner jetzigen Form ist eine absolute Katastrophe. Bei einem Fehler einfach den Dienst zu quittieren und überhaupt keinen Output zu liefern, hilft weder einem Besucher, noch dem Shop-Betreiber.

Hier wäre es schön wenn wenigstens eine Standard-Fehlermeldung kommen würde oder eine Weiterleitung auf die offline.html erfolgt, wie es ja bei Verbindungsproblemen mit der DB schon passiert. Ein zuschaltbares und zuverlässiger Fehler-Protokoll wäre toll. Ein Traum wäre natürlich eine automatische Benachrichtigung per E-Mail bei schwerwiegenden Fehlern.

Vielen Dank Avenger für den Hinweis mit dem Überschreiben des error_reportings! Habe beim Upload bewusst das tmp-dir weggelassen aber vergessen es auf dem Server anzulegen. Ohne Fehlermeldung hätte ich mir einen Ast gesucht, mit hats 5 Sek gedauert das Problem zu lösen. :slight_smile:

Kleiner Hinweis noch meiner Seits: Bei einigen Provider (z.B. Profihost) ist es u.U. noch notwendig die Ausgabe von Fehlermeldungen generell zu aktivieren. Dies passiert wie folgt:

ini_set('display_errors', 1);

[QUOTE=wthimm2000;25997]Hallo avenger,

vielen Dank für Deine Hinweise. Auf diese Weise konnte ich das ipayment Modul als Verursacher ausfindig machen. Nach der deaktivierung läuft die Bestellung nun durch.[/QUOTE]

Kleine Vermutung: Ist das iPayment Modul Verschlüsselt? Wenn ja muss es per FTP im Binären Modus übertragen werden. Sonst klappts nicht.