Sehe Startseite nicht mehr! 4.2. CE Edition

Hallo kann mir mal einer helfen?

Seid ein paar Tagen wird die Startseite vom Oxid Shop nicht mehr angezeigt.
Es hat niemand was dran gemacht oder dran gearbeitet und plötzlich war diese weg.
In den Admin Bereich kommt man ganz normal …nur die index wird nicht mehr angezeigt.
Was kann das sein??

www.junge-mode-shop.de

[QUOTE=sushihc;40677]Hallo kann mir mal einer helfen?

Seid ein paar Tagen wird die Startseite vom Oxid Shop nicht mehr angezeigt.
Es hat niemand was dran gemacht oder dran gearbeitet und plötzlich war diese weg.
In den Admin Bereich kommt man ganz normal …nur die index wird nicht mehr angezeigt.
Was kann das sein??

www.junge-mode-shop.de[/QUOTE]
Irgendwer hat was geändert, und wenn es der Provider am Server war…

Das ist die allseits beliebte weiße Seite, die erscheint, wenn ein Programmfehler auftritt (und die die OXID AG seit ca. 18 Monaten, trotz dauernder Ermahnung meinerseits, nicht für verbesserungswürdig erachtet…)

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.

Ok das werde ich nacher mal probieren…

Vielen Dank schon mal dafür… ich werd mich garantiert wieder melden hehe

danke für die schnelle Hilfe…

Die Seite gibt allerdings ein “500 Internal Server Error” aus, da kann Oxid nix mehr melden. Ich würde mal beim Provider nachfragen.

Hallo,

Das ist die allseits beliebte weiße Seite, die erscheint, wenn ein Programmfehler auftritt (und die die OXID AG seit ca. 18 Monaten, trotz dauernder Ermahnung meinerseits, nicht für verbesserungswürdig erachtet…)

Es kommt überhaupt nicht in die Tüte, dass Fehlermeldungen im Frontend ausgegeben werden, weil es sicherheitsrelevant sein kann.
Wenn eine weisse Seite erscheint, ist meist das display_errors beim Hosting Provider ausgeschaltet und das ist gut so. Den Fehler findet man (vorausgesetzt, das error reporting ist angeschaltet und verweist auf eine korrekt beschreibbare Datei) im error_log. Falls auch dort nichts erkennbar ist, ist - wie im Fall @leofonic beschrieben - von OXID-Seite gar keine Möglichkeit mehr gegeben, einen Fehler irgendwohin zu melden. Falls das doch möglich wäre, haben wir es mit einem Bug zu tun, der in den Bugtracker gehört.

Gruß

[QUOTE=Marco Steinhaeuser;40731]Hallo,

Es kommt überhaupt nicht in die Tüte, dass Fehlermeldungen im Frontend ausgegeben werden, weil es sicherheitsrelevant sein kann.
Wenn eine weisse Seite erscheint, ist meist das display_errors beim Hosting Provider ausgeschaltet und das ist gut so. Den Fehler findet man (vorausgesetzt, das error reporting ist angeschaltet und verweist auf eine korrekt beschreibbare Datei) im error_log. Falls auch dort nichts erkennbar ist, ist - wie im Fall @leofonic beschrieben - von OXID-Seite gar keine Möglichkeit mehr gegeben, einen Fehler irgendwohin zu melden. Falls das doch möglich wäre, haben wir es mit einem Bug zu tun, der in den Bugtracker gehört.

Gruß[/QUOTE]
Was, bitteschön, soll an einer PHP-Meldung, dass ein PHP-Syntax-Fehler vorliegt, sicherheitsrelevant sein?

Und die meisten Fehler dürften sein: ein fehlendes/fehlerhaftes Modul oder z.B. durch Template-Fehler eingeführte PHP-Fehler.

[B]Zum Fehler 500:[/B]

OXID generiert unter bestimmten Bedingungen, warum auch immer, [B]selbst [/B]einen Fehler 500:

einmal in “[B]core/oxconfig.php[/B]” beim Start der Session (was z.B. im konkreten Fall auch zutreffen könnte)

        try {
            //starting up the session
            $this->getSession()->start();

            $sShopID = $this->getShopId();

            // load now
            $this->_loadVarsFromDb( $sShopID );

        } catch ( oxConnectionException $oEx ) {
            $oEx->debugOut();
            if ( defined( 'OXID_PHP_UNIT' ) ) {
                return false;
            } elseif ( 0 != $this->iDebug ) {
                oxUtils::getInstance()->showMessageAndExit( $oEx->getString() );
            } else {
                header( "HTTP/1.1 500 Internal Server Error");
                header( "Location: offline.html");
                header( "Connection: close");
            }
        } catch ( oxCookieException $oEx ) {
            // redirect to start page and display the error
            oxUtilsView::getInstance()->addErrorToDisplay( $oEx );
            oxUtils::getInstance()->redirect( $this->getShopHomeURL() .'cl=start', true, 302 );
        }

Zum anderen in “core/exeception/oxexceptionhandler.php”

    protected function _safeShopRedirectAndExit($sUrl)
    {
        // No redirects in unit testing .. as redirection ends also unit testing script..
        if ( defined('OXID_PHP_UNIT')) {
            return ;
        }

        //make the redirect directly to be independetn from other objects
        header("HTTP/1.1 500 Internal Server Error");
        header("Location: ".$sUrl);
        header("Connection: close");

    }

Diese Routine wird aufgerufen, von

protected function _uncaughtException( oxException $oEx )
protected function _dealWithNoOxException( Exception $oEx )

im selben Modul, also genau dann, wenn das Programm, kommentarlos, im Nirvana verschwindet.

Diese von OXID selbst generierten Fehler 500 Meldungen machen die Verwirrung endgültig komplett, da man nun erst mal gar nicht weiß, ob das ein “echter” Server-Fehler 500 ist, oder einer, den sich OXID anlässlich der oben beschriebenen Situationen selbst ausgedacht hat.

Statt sich in einen nichtssagenden Fehler 500 zu retten, muss hier ein verständliches Fehlerreporting stattfinden.

Ich bleibe dabei: das OXID Exception handling und reporting ist völlig unbrauchbar für Leute die sich da nicht so auskennen, und außer einer .leeren Seite keine anderen Informationen über Fehlerursachen haben,

Hi,

Ich bleibe dabei: das OXID Exception handling und reporting ist völlig unbrauchbar für Leute die sich da nicht so auskennen, und außer einer .leeren Seite keine anderen Informationen über Fehlerursachen haben,

Das ist gar keine Frage, ein vernünftiges exception handling ist ein Muss. Aber: Per sé sollten keine Fehler im Frontend auftauchen sondern in irgendeinen log geschrieben werden. Eine pauschale Aussage “macht das exception handling besser” bringt uns hier nicht weiter. Es sollte immer dann als Bug aufgenommen und behandelt werden, wenn es auffällt. Ein Bug kann dann als Bug bearbeitet werden, wenn er im Bugtracker gelandet ist.

Gruß

Hmm also hab jetzt mal wie beschrieben die Codes eingefügt. Aber im error_log steht bisher nur ein Eintrag vom 6.9. da ging der Shop noch.

Also viel verändert hat sich jetzt nicht :frowning:

hab auch den Provider angeschrieben.

Ein Error Log einstellen??Wie macht man das??ist das nicht automatisch an bei Oxid?
Ich verstehe auch nit warum im Backend wirklich ALLES geht nur die Index nicht angezeigt wird. Alle “unterseiten” gehen quasi…

Ich würde mal abwarten was der Provider sagt.

Der Provider sagt das i8st ein Vserver und dazu gibts keinen Support. Und da die bei vServern keinen Zugriff haben haben die garantiert auch nichts gemacht und ich muss selber gucken.

Jetzt kommt sogar nix mehr…die dateien liegen aber alle auf dem Server.Hab die Vorschläge von Avenger erstmal rückgängig gemacht.
Soll ich mal Error Log hier posten? Hab da nit ganz soviel Ahnung von leider. Bisher hat immer nen Bekannter den Server gemanaged aber der ist mit Studium so ausgelastet , dass der sich nie zurück meldet. Mist!

Ich hab n Server BackUp vom 5.9. kann ich nicht einfach ein Dump der aktuellen Datenbank machen,Das Backup einspielen und dann den DB Dump einspielen?Dann sollte doch auch alles auf Stand sein oder?

Sollte gehen, ja. Neue Bilder etc. nicht vergessen.

Was meinst mit neue Bilder nicht vergessen?

Wenn du seit dem letzten Serverbackup neue Artikel hochgeladen hast dann sind die Bilder davon ja weg wenn du den alten Serverstand wiederherstellst, weil die Bilder ja nicht in der DB liegen, sondern im Ordner out/pictures, das musst du also in dem Fall auch wiederherstellen (Ich würde sowieso alle Shopdateien sichern, nicht um sie wieder einzuspielen, nur als Sicherheit). Außerdem nach dem Einspielen des Dumps unbedingt alle Dateien im tmp Verzeichnis löschen.

Wenn das ein V-Server ist: hast du schonmal ins error Log des Apache geschaut?