Testumgebung: Unerwünschter Redirect auf leere Seite

Hallo zusammen,
ich habe Dateien und Datenbank zweier laufender Shops jeweils in eine Testumgebung mit identischen Einstellungen kopiert (vHosts auf demselben Server).
Während die eine Website nach Anpassen der config.php problemlos läuft, macht die andere Schwierigkeiten. Statt auf

www.domain.de/

landet man immer auf

www.domain.de/index.php?cl=start&redirected=1

und bekommt eine leere Seite.

Wie hier im Forum beschrieben, habe ich im error_log nachgesehen: Nichts.
Ausserdem habe ich in der config.php per ini_set(‘display_errors’, 1); die php-Fehleranzeige angeschaltet, auch das bringt kein Ergebnis.
Das tmp-Verzeichnis ist gelöscht und vorsichtshalber von 775 auf 777 gesetzt.

Wieso wird überhaupt ein redirect durchgeführt? Die htaccess habe ich unverändert kopiert…

:confused:
floko

Ich hatte übersehen, dass es ausser dem error_log des Servers noch ein separates Exception Log von Oxid gibt. Hier rauschen tatsächlich Fehlermeldungen rein, mit denen ich aber noch nichts anfangen kann:

oxSystemComponentException-oxException (time: 2009-11-26 11:47:19): [0]: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND 
 Stack Trace: #0 /srv/www/domainname.de/html/core/oxfunctions.php(259): oxUtilsObject->oxNew('oxactions', NULL)
#1 /srv/www/domainname.de/html/core/oxarticlelist.php(231): oxNew('oxactions')
#2 /srv/www/domainname.de/html/views/oxubase.php(2577): oxArticleList->loadAktionArticles('OXBARGAIN')
#3 /srv/www/domainname.de/html/views/oxubase.php(2488): oxUBase->getBargainArticleList()
#4 /srv/www/domainname.de/html/views/start.php(141): oxUBase->_loadActions()
#5 /srv/www/domainname.de/html/modules/storefront/dotstart/dotstart.php(36): Start->render()
#6 /srv/www/domainname.de/html/views/oxshopcontrol.php(254): dotstart->render()
#7 /srv/www/domainname.de/html/views/oxshopcontrol.php(77): oxShopControl->_process('start', NULL)
#8 /srv/www/domainname.de/html/index.php(97): oxShopControl->start()
#9 {main}

 Faulty component --> oxactions
---------------------------------------------
oxSystemComponentException-oxException (time: 2009-11-26 11:47:20): [0]: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND 
 Stack Trace: #0 /srv/www/domainname.de/html/core/oxfunctions.php(259): oxUtilsObject->oxNew('oxactions', NULL)
#1 /srv/www/domainname.de/html/core/oxarticlelist.php(231): oxNew('oxactions')
#2 /srv/www/domainname.de/html/views/oxubase.php(2577): oxArticleList->loadAktionArticles('OXBARGAIN')
#3 /srv/www/domainname.de/html/views/oxubase.php(2488): oxUBase->getBargainArticleList()
#4 /srv/www/domainname.de/html/views/start.php(141): oxUBase->_loadActions()
#5 /srv/www/domainname.de/html/modules/storefront/dotstart/dotstart.php(36): Start->render()
#6 /srv/www/domainname.de/html/views/oxshopcontrol.php(254): dotstart->render()
#7 /srv/www/domainname.de/html/views/oxshopcontrol.php(77): oxShopControl->_process('start', NULL)
#8 /srv/www/domainname.de/html/index.php(97): oxShopControl->start()
#9 {main}

 Faulty component --> oxactions
---------------------------------------------

Weiss jemand, wo ich da ansetzen muss?

Danke!
floko

Da wird die Klasse “core/oxactions.php” vermisst…

Ist das OXID CE?

[QUOTE=avenger;19671]Da wird die Klasse “core/oxactions.php” vermisst…

Ist das OXID CE?[/QUOTE]

Nein, das ist PE, sollte aber im Wesentlichen gleich sein, oder?

Vielen Dank für den Hinweis! Vielleicht ist beim Kopieren was schiefgelaufen, schaue ich mir gleich an.

Grüße
floko

Danke, avenger, das war’s:
Die oxactions.php hatte 0 byte Dateigröße, die muß es wohl beim Kopieren erwischt haben.
Jetzt läuft es rund!

habe fast das gleiche problem, wenn ich über die stichworte gehe.

sobald ich ein artikel aufmachen möchte, der über die stichworte gefunden wird, komme ich auf

http://www.meine-domain.de/index.php?&redirected=1

also wieder auf die startseite und nicht auf den artikel.

könnt ihr mir da weiterhelfen ?

Und was steht in EXCEPTION_LOG.txt?

oxConnectionException-oxException (time: 2010-08-12 03:02:07): [0]: EXCEPTION_CONNECTION_NODB
Stack Trace: #0 /www/htdocs/w00b22a8/core/oxconfig.php(479): oxDb::getDb()
#1 /www/htdocs/w00b22a8/core/oxconfig.php(406): oxConfig->_loadVarsFromDb(‘oxbaseshop’)
#2 /www/htdocs/w00b22a8/core/oxconfig.php(448): oxConfig->init()
#3 /www/htdocs/w00b22a8/core/oxsupercfg.php(115): oxConfig::getInstance()
#4 /www/htdocs/w00b22a8/core/oxutilsobject.php(207): oxSuperCfg->getConfig()
#5 /www/htdocs/w00b22a8/core/oxutilsobject.php(110): oxUtilsObject->getClassName(‘oxutilsobject’)
#6 /www/htdocs/w00b22a8/core/oxutilsobject.php(74): oxUtilsObject->oxNew(‘oxUtilsObject’)
#7 /www/htdocs/w00b22a8/core/oxfunctions.php(284): oxUtilsObject::getInstance()
#8 /www/htdocs/w00b22a8/core/oxutils.php(87): oxNew()
#9 /www/htdocs/w00b22a8/core/oxfunctions.php(448): oxUtils::getInstance(‘oxUtils’)
#10 /www/htdocs/w00b22a8/index.php(72): require_once(’/www/htdocs/w00…’)
#11 /www/htdocs/w00b22a8/oxseo.php(38): require(’/www/htdocs/w00…’)
#12 {main}

Connection Adress -->
Connection Error --> xxxxxx/www/htdocs/w00b22a8/Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)

oxShopException—!–NOT CAUGHT–!--oxException (time: 2010-08-12 03:02:07): [0]: EXCEPTION_SHOP_NOTACTIVE
Stack Trace: #0 /www/htdocs/w00b22a8/core/oxfunctions.php(284): oxUtilsObject->oxNew(‘oxShopException’, NULL)
#1 /www/htdocs/w00b22a8/views/oxcmp_shop.php(59): oxNew()
#2 /www/htdocs/w00b22a8/views/oxubase.php(2208): oxcmp_shop->render(‘oxShopException’)
#3 /www/htdocs/w00b22a8/views/start.php(176): oxUBase->render()
#4 /www/htdocs/w00b22a8/views/oxshopcontrol.php(299): Start->render()
#5 /www/htdocs/w00b22a8/views/oxshopcontrol.php(99): oxShopControl->_process()
#6 /www/htdocs/w00b22a8/index.php(102): oxShopControl->start(‘start’, NULL)
#7 /www/htdocs/w00b22a8/oxseo.php(38): require(’/www/htdocs/w00…’)
#8 {main}


oxSystemComponentException-oxException (time: 2010-08-18 10:43:20): [0]: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND
Stack Trace: #0 /www/htdocs/w00b22a8/core/oxfunctions.php(284): oxUtilsObject->oxNew(‘sea’, NULL)
#1 /www/htdocs/w00b22a8/views/oxshopcontrol.php(271): oxNew()
#2 /www/htdocs/w00b22a8/views/oxshopcontrol.php(99): oxShopControl->_process(‘sea’)
#3 /www/htdocs/w00b22a8/index.php(102): oxShopControl->start(‘sea’, NULL)
#4 {main}

Faulty component --> sea

2010-08-18 ist ja alt. Lösche alles raus, ruf deinen Shop auf und schau ob neue Einträge drin sind.

oki, ich machs mal …

der fehler besteht aber schon länger, hatte nur noch nicht die zeit mich da intensiver drum zu kümmern. habe zur zeit die 4.3.1 version, wollte auch nicht mehr updaten in nächster zeit. komischerweise funktionieren die alten stichworte dich ich bei den artikeln in der 4.2 version eingestellt habe, bei den artikeln die ich in der 4.3.1 version eingespielt habe, komme ich auf die redirect

kannst ja mal selber schauen www.nettis-mode.de

theme kannste anklicken und dann eine schabracke , da gehts sind alte artikel, bei tenson gehts nicht bis auf 2 sind alles neue artikel.

so hab den ordner mal rausgeworfen und shop neugestartet, kein neuer EXCEPTION_LOG.txt. hab aber nen ordner da drinne der sich oxdebugdb_skipped sql nennt. keine ahnung wo der herkommt.

hab gerade noch mal den EXCEPTION_LOG.txt von ner sicherung leergemacht und eingespielt, rechte hochgesetzt, der bleibt aber leer

[QUOTE=ninja;40821]hab gerade noch mal den EXCEPTION_LOG.txt von ner sicherung leergemacht und eingespielt, rechte hochgesetzt, der bleibt aber leer[/QUOTE]
Das ist wieder einer der Fälle, in denen OXID sich vornehm über seine Probleme ausschweigt…

=> http://www.oxid-esales.com/forum/showthread.php?p=40756#post40682

Ja die Frage ist warum hier eine Weiterleitung stattfindet. Ich vermute dass etwas in den SEO-Tabellen nicht stimmt aber ohne Fehlermeldung ist das schwer zu sagen.

also könnt ihr mir da nicht wirklich weiterhelfen … und updaten und zu hoffen das alles wieder geht ist auch nicht die beste lösung

habe schon versucht über einen testshop mit der 4.2 version meine aktuellen artikel etc über die datenbank einzuspielen, aber da hab ich auch probleme …

Kennst du dich mit PHPmyadmin aus? Suche doch mal in der Tabelle oxseo nach einem der Links, z.B.:

tag/jacke/Waefo-Damen-und-Herren-Skijacke.html

in der Spalte OXSEOURL. Wird was gefunden? Was steht dort bei OXSTDURL?

ups… okay bin zwar nicht so ganz firm aber denke das werd ich noch hinbekommen

sooo habe was gefunden:

bei oxstdurl steht: index.php?cl=tag&searchtag=elvi
oxseourl : [BLOB - 9Bytes]


oxkeywords und oxdescription sind fast immer leer…auch bei oxparams ist nicht überall was eingetragen

bei über 1100 seiten nicht einfach was genaues zu finden

hm, oxseourl ist normal kein blob. Trag mal folgendes in der config.inc.php von PHPMYADMIN ein um den Inhalt der Spalte oxseourl zu sehen:

$cfg['ProtectBinary'] = FALSE;

Dann suche nochmal:

  • Links auf Tabelle “oxseo” klicken dann oben Registerkarte “suchen”
  • die Url bei oxstdurl eintragen: tag/jacke/Waefo-Damen-und-Herren-Skijacke.html
  • OK

[QUOTE=leofonic;41032]hm, oxseourl ist normal kein blob. Trag mal folgendes in der config.inc.php von PHPMYADMIN ein um den Inhalt der Spalte oxseourl zu sehen:

$cfg['ProtectBinary'] = FALSE;

Dann suche nochmal:

  • Links auf Tabelle “oxseo” klicken dann oben Registerkarte “suchen”
  • die Url bei oxstdurl eintragen: tag/jacke/Waefo-Damen-und-Herren-Skijacke.html
  • OK[/QUOTE]

puhhh das finde ich jetzt nun nicht… muss ich auf den ftp server gehen ?

[QUOTE=avenger;40844]Das ist wieder einer der Fälle, in denen OXID sich vornehm über seine Probleme ausschweigt…

=> http://www.oxid-esales.com/forum/showthread.php?p=40756#post40682[/QUOTE]
Nur mal so als Anregung für die OXID eShop AG:

http://www.shopware.de/wiki/Preview-3.5.0_detail_497.html#Exception_Handler

So muss ein [B]Exception-Handling [/B]aussehen, ist einfach informativer als 'ne leere weiße Seite…

Und da man sich diese Information auch per eMail zusenden lassen kann, hat man auch eine prima Möglichkeit, das Error-Reporting immer mitlaufen zu lassen, um auch [B]sporadische [/B]Fehler zu erkennen, ohne dass diese Information immer und nach außen sichtbar wird.

Und auch das Debuggen eines Shops mit [B]FirePHP [/B]ist auf Servern ohne direkten PHP-Debugger-Zugriff eine sehr große Hilfe.

http://www.shopware.de/wiki/Debuggen-mit-FirePHP-in-Shopware-3.0.5_detail_433.html

Es bleibt zu hoffen, dass auch hier jetzt Konkurrenz endlich das Geschäft belebt, und die OXID eShop AG ein paar “[B]must haves[/B]” nachrüstet, die ich schon seit vielen Monaten anmahne.

Und dafür nicht erst wieder Bugreports oder gar Feature-Requests haben will…

Ich muss schon sagen:

wenn Shopware auch nur die Hälfte von dem liefert, was in http://www.shopware.de/wiki/Preview-3.5.0_detail_497.html beschrieben ist (und das Zend Framework nicht so unsäglich schlecht implementiert hat, wie Magento), dann wird das ein echter Knaller.

Der Vorstandsvorsitzende von shopware zumindest “gibt sein Wort”, dass da sogar noch viel mehr drinsteckt…

http://www.shopware-community.de/viewtopic.php?f=24&t=57#p746

Das sieht in der Tat beeindruckend aus. Zum Errorhandling: Oxid protokolliert ja auch ein Stacktrace im Fehlerfall, allerdings sind im Code auch direkte Redirects. Ninja hat mir die oxseo-Tabelle zugesandt, ich habe mir das angesehen und auf folgendes gestoßen:

  • Die Einträge in der oxseo sind falsch
  • Wenn das Produkt nicht gefunden wird, leitet details.php kommentarlos auf die Startseite

In der Datei details.php befindet sich der Code ab Zeile 768:

            // object is not yet loaded
            $this->_oProduct = oxNew( 'oxarticle' );
            //$this->_oProduct->setSkipAbPrice( true );

            if ( !$this->_oProduct->load( $sOxid ) ) {
                $myUtils->redirect( $myConfig->getShopHomeURL() );
                $myUtils->showMessageAndExit( '' );
            }

In dem Fall gehört auf jeden Fall ein Eintrag in ein Logfile IMHO.

@ninja
Die “falschen” SEO-Urls beinhalten keine Artikelnummer. Jetzt müsste man herausfinden, warum die URLs falsch generiert werden.

[QUOTE=leofonic;41201]Das sieht in der Tat beeindruckend aus.[/QUOTE]
Gell?

[QUOTE=leofonic;41201]Zum Errorhandling: Oxid protokolliert ja auch ein Stacktrace im Fehlerfall[/QUOTE]
In den meisten Fällen aber nur dann, wenn iDebug>0 ist…

Und wenn man iDebug>0 setzt, den hat man immer das andere Debug-Zeugs mit auf der Seite.

Das hab ich ja schon zig-Mal vorgeschlagen, dass das speichern des Fehlers immer gemacht wird, wenn einer auftritt.

Dann hätte man 90% der jetzigen Probleme schon mal gelöst.