Hallo zusammen,
hatte jemand eine Idee wie ich mir im Admin-Bereich von Oxid eSales Fehler ausgeben lassen? Bekomme momentan wieder mal nur “weiße” Seiten!
Was das Error-Reporting von Oxid angeht, da könnte ich mal wieder total durchdrehen. Den Fehler zu finden mit Fehlermeldung, dauert wenige Minuten. Ohne Fehlermeldung kann es Tage dauern.
Warum macht Oxid so ein Mist mit den Exceptions? Ein sonst so professionelles System versagt an so elementarer Stelle aufs allergröbste!
[QUOTE=smonkey;35499]Warum macht Oxid so ein Mist mit den Exceptions? Ein sonst so professionelles System versagt an so elementarer Stelle aufs allergröbste![/QUOTE]
So isses!
Und stören tut das bei der OXID AG auch niemand…
Seit 15 Monaten moniere ich das, und mit wenigen Änderungen lässt sich das drastisch verbessern.
Dafür ist anscheinend keine Zeit, dafür kommt dann so ein Facebook-Müll dazu.
Hi,
Und stören tut das bei der OXID AG auch niemand…
Stimmt ja gar nicht.
Ihr habt mit Sicherheit in der Zwischenzeit einige Stellen gefunden, wo das exception handling nicht so berauschend ist. Können wir diese Stellen irgendwie sammeln? Von mir aus hier im Thread oder - mir noch lieber - irgendwo in der Wiki?
Danke und Gruß
Also so ein entgegendenkommendes Angebot will ich wirklich nicht offen stehen lassen.
Ich bin jetzt technisch nicht so vertieft wie andere User hier, aber ich verweise einfach mal auf folgendes Thema:
http://www.oxid-esales.com/forum/showthread.php?t=4416
Und dabei ins besondere auf:
QUOTE=avenger;25858 Nun, [B]eine [/B]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!(…)[/QUOTE]
Und um mich selbst zu zitieren: 
QUOTE=smonkey;25998Hier 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.(…)[/QUOTE]
Also der Punkt ist einfach, dass i.d.R. ein auftretender Fehler, die Ausführung des Skriptes beendet und jeglichen Output verhindert.
Was letzlich im Falle eines Fehlers den Kunden äußerst iritiert und vergrault! Schöner wäre eine Meldung wie “Ein Fehler ist aufgetreten, bitte versuchen Sie es erneut”, oder “Huch das hätte nicht passieren dürfen, der Administrator wurde informiert”.
Viel wichtiger ist aber der Part für den Shop-Administrator. Die Fehlersuche ohne Fehler gleicht der sprichwörtlichen Suche nach der Nadel im Heuhaufen. Während hingegen ein Fehler mit Meldung oft nur wenige Minuten zum korrigieren benötigt.
Leider lässt sich imho diese Fehlerausgabe bisher nirgends aktivieren, weder für den Shop- noch für den Admin-Bereich. Es gibt zwar eine Exception-Log, welche aber leider nur in seltenen Fällen auch wirklich beschrieben wird.
Ein sehr wünscheswertes Feature wäre es noch, sich über kritische Fehler als Administrator per E-Mail informieren lassen zu können. Das klingt dann aber wohl schon eher nach Zukunftsmusik.
[QUOTE=smonkey;35879]Ein sehr wünscheswertes Feature wäre es noch, sich über kritische Fehler als Administrator per E-Mail informieren lassen zu können. Das klingt dann aber wohl schon eher nach Zukunftsmusik. :)[/QUOTE]
So utopisch ist das gar nicht…
Da die Fehler ja an schon an einer zentralen Stelle im Exception-Handler auflaufen, kann man das durchaus schnell realisieren.
Das Verrückte ist ja: OXID hat alle Informationen über Fehler an dieser einen Stelle vorliegen, diese wird halt nur vornehm verschwiegen…
Das Exception-Handling von OXID lässt sich mit einem Aufwand <= 1 Stunde um 95% verbessern. (Genau genommen muss man nur 2 Code-Zeilen ändern.)
Für mich habe ich das natürlich schon gemacht, und vor ca. 1 Jahr die Änderungen hier auch beschrieben.
Und wenn man dann noch das PHP-“errorreporting” standardmäßig einschalten würde (noch eine Code-Zeile mehr zu ändern), dann nähern wir uns IMO schon 98% vom Idealzustand.
Das ist ja das, was ich nicht absolut nicht mehr verstehe: mit quasi null Aufwand ließe sich die Exception-Handling-Situation drastisch verbessern, die notwendigen Änderungen sind dokumentiert, und trotzdem lässt man den Anwender weiterhin im Nebel stochern.
Kannst du mir bei der Gelegenheit bitte noch mal genau sagen wo und was du geändert hast? Bzw. wo ich die Änderungen entnehmen kann?
Ich habe grade mal wieder den konkreten Fall das ich im Admin-Bereich bei einem Drittanbieter-Modul die bekannte leere Seite bekomme. Habe zwar schon an allen erdenklichen Stellen error_reporting hochgeschraubt und display_errors aktiviert, aber bisher leider ohne Erfolg.
[QUOTE=smonkey;35922]Kannst du mir bei der Gelegenheit bitte noch mal genau sagen wo und was du geändert hast? Bzw. wo ich die Änderungen entnehmen kann?[/QUOTE]
In den folgenden Routinen in “[B]core\exception\oxexceptionhandler.php[/B]”
if ( 0 != $this->_iDebug )
ersetzen mit
if ( true)
Damit werden alle Exceptions gelogged, was schon mal ein guter Start ist.
Und an den Stellen könnte man auch eine eMail an den Admin senden lassen.
protected function _uncaughtException( oxException $oEx )
{
// exception occured in function processing
$oEx->setNotCaught();
// general log entry for all exceptions here
$oEx->debugOut($this->_iDebug);
if ( defined( 'OXID_PHP_UNIT' ) ) {
return $oEx->getString();
//} elseif ( 0 != $this->_iDebug ) {
} else {
$f = fopen( $this->_sFileName, 'a' );
$sOut = date( 'Y-m-d H:i:s' ) . $oEx . "
---------------------------------------------
";
fputs( $f, $sOut );
fclose( $f );
exit( $oEx->getString() );
}
//simple safe redirect in productive mode
$this->_safeShopRedirectAndExit( "offline.html" );
//should not be reached
return ;
}
/**
* No oxid exception, just write log file.
* IMPOARTANT: uses _safeShopRedirectAndExit(), see description
*
* @param Exception $oEx exception object
*
* @return null
*/
protected function _dealWithNoOxException( Exception $oEx )
{
/*if ( 0 != $this->_iDebug ) {*/
if (true) {
$f = fopen( $this->_sFileName, 'a' );
$sOut = date( 'Y-m-d H:i:s' ) . $oEx . "
---------------------------------------------
";
fputs( $f, $sOut );
fclose( $f );
if ( defined( 'OXID_PHP_UNIT' ) ) {
return;
//} elseif ( 0 != $this->_iDebug ) {
} else {
exit( $oEx->getString() );
}
}
$this->_safeShopRedirectAndExit( 'offline.html' );
}
Danke. Geweiterleitet.
Gruß
Danke avenger und Danke Marco, da bin ich jetzt schon auf die nächste Version gespannt.
[QUOTE=avenger;35928]In den folgenden Routinen in “[B]core\exception\oxexceptionhandler.php[/B]”
if ( 0 != $this->_iDebug )
ersetzen mit
if ( true)
Damit werden alle Exceptions gelogged, was schon mal ein guter Start ist.
[/QUOTE]
Sehe ich das richtig, die Änderung entspricht nur einem Config-Wert der Variable iDebug größer 0?
Mein Problem ist das auch dann Exceptions weder protokolliert noch ausgegeben werden!
Ich schätze, dass der exceptionhandler eben oft gar nix mehr zu handeln bekommt, weil das Skript vorher schon abgeschmiert ist.
Ein Blick ins PHP-Errorlog ergibt da manchmal noch was.
Wurde dazu schon eine Lösung gefunden?
bei mir kommt
EXCEPTION_SYSTEMCOMPONENT_FUNCTIONNOTFOUND
und danach ein redirect im unteren Frame ins Shopfenster …
kein exeption.log nix …
LG
Du könntest versuchen herauszufinden welche Funktion da fehlt: oxview.php Zeile 511 so ergänzen:
$oEx->setMessage( 'EXCEPTION_SYSTEMCOMPONENT_FUNCTIONNOTFOUND '.$this->getClassName().'::'.$sFunction );