ihr habt mir ja in den vergangenen Tagen schon viel geholfen. Nun habe ich aber nochmal ein anderes Problem.
Der Shop läuft generell. Die Startseite geht, Artikel sind da und werden korrekt angezeigt. Ich kann auch auf andere Seiten springen (Mehr Information bei Artikeln, Kategorieseiten, Impressum). Manche Seiten funktionieren aber nicht. Ich vermute es sind die Seiten, die an einen AJAX-Aufruf gekoppelt sind. Problematisch sind folgende Seite: Mein Konto, Warenkorb, Wunschzettel oder Artikelvergleich. Außerdem geht auch der Login ins Backend nicht.
Interessanterweise kann ich mich als User einloggen (hierfür wird ja kein Seitenwechsel durchgeführt). Dann sehe ich auch alte Artikel im Warenkorb. Aber ich kann nicht die Warenkorbseite aufrufen. Außerdem wird der Login sofort vergessen. Heißt, wenn ich die Startseite nochmal aufrufe, bin ich wieder ausgeloggt.
Ich habe einen Symlink nach diesem Tutorial eingerichtet. Ich bin mir nicht sicher, ob hier ein Weiterleitungsproblem besteht.
Es gibt einige “header already sent”-Warnungen (bspw. aus der bootstrap.php), die sind laut meiner Recherche aber “normal”.
Lösungsversuche
Ich habe die Views in der DB gelöscht und $this->blSkipViewUsage = true; in der config.inc.php eingestellt.
Außerdem habe ich mir die HTTP-Aufrufe mal angesehen. Die werden alle mit 200 beantwortet, liefern allerdings ein leeres Ergebnis. Bzgl. der Weiterleitung oben habe ich extra geprüft, dass hier jetzt auch domain.de/shop/index.php aufgerufen wird. Wenn ich die leere Seite refreshe (URL steht noch auf index.php?) komme ich auch wieder auf den Shop. Nur über die Formulare scheint es nicht zu funktionieren. In der Konsole wird auch kein JS-Fehler angezeigt.
Hat jemand eine Idee was ich da noch prüfen könnte? Wenn ihr noch mehr Infos braucht, gebt einfach Bescheid. Ich wollte auch nicht zuviel schreiben im ersten Post.
prüf Deine Formulare ob dort das Unterverzeichnis auch angegeben. Ein Formular erkennst an HTML-Tag <form ...> und dort gibt es das action="..." Attribute. In diesem Attribute sollte die korrekte Adresse mit Unterverzeichnis stehen z.B. domain.de/shop/index.php?
Bei den AJAX-Request bleibt Dir nichts anderes übrig zu debuggen wo diese hin gehen und auch dort musst Du sicherstellen, dass dein Unterverzeichnis im Request mit auftaucht sonst führen diese wie bereits vermutet ins Leere.
Das sieht für mich eigentlich schlüssig aus. Kann ich irgendwo einsehen wohin die Anfrage intern weitergeleitet wird? Da steckt ja irgendein Controller dahinter. Dann könnte ich dort mal eine Ausgabe reinmachen.
Ja, Du müsstest wie richtig erkennst die Anfrage debuggen. Optimal wäre es wenn Du eine Testumgebung hast, dann schalte am besten das SEO Handling aus. Dies ist möglich mit der Variable $this->blSeoMode = false; indem Sie in der config.inc.php setzt oder bei den Formularen hast die hidden Input Felder und über name="cl" kannst sehen in welchen Controller Du landen solltest und kannst dort debuggen warum 200er zurück kommt. Am besten mit exit(); falls wirklich ein Redirect von OXID stattfindet, dann kannst in der Utils \OxidEsales\Eshop\Core\Registry::getUtils()->redirect(....) Dir Redirect deguggen wo dieser her kommt mit debug_backtrace()
Danke, die Hinweise waren sehr hilfreich. Ich konnte damit nachvollziehen, dass dies ein Redirect ist, der vom Shopsystem ausgeht und nicht wie ich erst vermutet hatte durch eine Fehlkonfiguration zu standek kommt. Nun habe ich zwei Stellen, die ich nicht verstehe.
Zum einen habe ich mit debug_backtrace mir das Redirect näher angeschaut. Allerdings ist das ein Riesenarray und ich weiß nicht wonach ich dort suchen soll?
Zum anderen sollte in der Utils->_simpleRedirect() glaube ich eine Weiterleitung über den Header durchgeführt werden. Da fiel mir ein, dass es eine Warnung zum Absetzen des Headers gab. Jetzt wäre meine Frage, ob das eine Warnung ist die jeder hat oder ob mich das dem Problem ein Stück näher bringen kann?
Warning : session_id(): Cannot change session id when session is active in /homepages/5/d547360266/htdocs/shop6/vendor/oxid-esales/oxideshop-ce/source/Core/Session.php on line 964
Warning : Cannot modify header information - headers already sent by (output started at /homepages/5/d547360266/htdocs/shop6/vendor/oxid-esales/oxideshop-ce/source/Core/Session.php:964) in /homepages/5/d547360266/htdocs/shop6/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsServer.php on line 64
Warning : Cannot modify header information - headers already sent by (output started at /homepages/5/d547360266/htdocs/shop6/vendor/oxid-esales/oxideshop-ce/source/Core/Session.php:964) in /homepages/5/d547360266/htdocs/shop6/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsServer.php on line 64
Warning : Cannot modify header information - headers already sent by (output started at /homepages/5/d547360266/htdocs/shop6/vendor/oxid-esales/oxideshop-ce/source/Core/Session.php:964) in /homepages/5/d547360266/htdocs/shop6/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsServer.php on line 64
Ich habe die toBasket Methode zum Debuggen verwendet. Die läuft normal durch und am Ende gibt es die Stelle mit dem Redirect. Diese führt dann letztlich in die Methode Core/Utils->showMessageAndExit().
Nochmal vielen Dank für die Hilfe, alleine wäre ich da nicht weitergekommen.
Die Fehlermeldungen oben kommen aufgrund Deiner Debug Ausgaben. Die sind nicht die Ursache.
Den Befehl debug_backtrace() kannst begrenzen, dazu am besten php.net in die Beispiele der Kommentare gucken.
Das Du in der Methode landest wo Artikel zum Warenkorb hinzugefügt werden und anschließend auf die Startseite landest könnte daran liegen, dass der Artikel aktuell nicht kaufbar. Zusätzlich kannst die Shop Konfiguration im Admin checken. Dinge wie Lagerhaltung oder Theme Einstellungen was passieren soll wenn Artikel in Warenkorb landet.
Die Fehlermeldungen oben kommen aufgrund Deiner Debug Ausgaben. Die sind nicht die Ursache.
Die Warnungen erscheinen aber auch ohne meine Ausgabe, also im “Original-shop” so zu sagen. Das machte mich stutzig.
Den Befehl debug_backtrace() kannst begrenzen, dazu am besten php.net in die Beispiele der Kommentare gucken.
Danke habe ich gemacht. Damit konnte ich den Log auf folgenden Backtrag eingrenzen. Ich habe mir auch den ausführlicheren mal ein wenig angeschaut. Ich kann hier aber nichts ungewöhnliches erkennen.
Das Du in der Methode landest wo Artikel zum Warenkorb hinzugefügt werden und anschließend auf die Startseite landest könnte daran liegen, dass der Artikel aktuell nicht kaufbar. Zusätzlich kannst die Shop Konfiguration im Admin checken. Dinge wie Lagerhaltung oder Theme Einstellungen was passieren soll wenn Artikel in Warenkorb landet.
Ich komme auch nicht mehr ins ACP. Daher kann ich die Settings nicht einsehen. In meiner lokalen Entwicklungsumgebung läuft der Shop aber ohne Probleme. Dann können es auch eher nicht die Shop-Einstellungen sein oder?
Ich habe jetzt mal den Rückgabewert von BasketComponent->_getRedirectUrl() hart auf “index.php” geändert. Dann komme ich wenigstens im Redirect auf der Startseite wieder raus. Aber mit der Meldung
Wenn ich andere Werte wie “start” oder “basket” eintrage (die standen in der Funktion mit vorgegeben) komme ich immer auf die weiße Seite. Es sieht fast so aus als stünden dem Shop einige Seiten nicht zur Verfügung?!
dies liest sich insgesamt so, dass Deine oxseo Tabelle zerschossen sein könnte. Das Du auch nicht mehr in Admin kommst lässt auf fehlerhafte View Tabellen schließen…
Um dies zu beheben wäre es ein Versuch Wert die View Tabellen neuzugenerieren über den Admin Button.
Um wieder in den Admin zu kommen gibt es in der config.inc.php die Einstellung
// Enable temporarily in case you can't access the backend due to broken views
$this->blSkipViewUsage = false;
Diese Einstellung setzt Du auf true und probierst anschließend in den Admin zu kommen. Dann gehst → Service → Tools und klickst auf Button VIEWS jetzt updaten. Anschließend prüfst Du ob Deine SEO URLs im Frontend wieder funktionieren. Evtl. leerst auch noch Dein Tmp Verzeichnis.
Ich hatte das mit dem Views erzeugen schon selbst versucht. Allerdings hatte ich offenbar das “Views löschen” missverstanden. Ich hatte in der DB die Views gelöscht. Das hat dann aber beim Zugriff aufs ACP (trotz $this->blSkipViewUssagE=true;) zu einem Fehler geführt weshalb ich nicht ins ACP gekommen bin.
Ich hatte jetzt die Einstellung in der config.inc.php so wie von dir beschrieben eingestellt. Dann ein DB-Backup von der lokalen Umgebung gezogen und eingespielt. Dann kam ich wieder ins ACP und habe die Views neu generiert. Dann lief es wieder.
