URL vom Logo führt nicht auf Startseite

Hallo,

ich habe hier ein ziemlich seltsames Verhalten beobachtet. Wenn ich einen Link in dem Shop klicke und die Seite neu aufgebaut wurde, führt die URL vom Logo-Link nicht auf die Startseite, wie es wzu erwaten wäre, sondern auf die aktuell angezeigte Seite. Das kann eine Kategorie oder auch ein Artikel sein.

Das gleiche trifft auf den Startseiten-Eintrag im Menü zu.

Im Admin-Bereich wird bei einem Klick auf “Startseite des Shops” auch nicht der Shop / die Startseite angezeigt, sonder egal aus welchem Bereich der Link aufgerufen wird, dieser Link aufgerufen: https://meinedomain.shop/stage1/source/admin/index.php?editlanguage=0force_admin_sid=390b3e1c1ec0bd8d63a918cc4c275444&stoken=5FA8874C&&cl=navigation&item=header.tpl

Wie kann ich das abstellen?

wahrscheinlich liegt das an Deiner Server-Umgebung wo sich Dein Shop befindet. Unüblich ist auch, dass stage1/source sich im Link befindet.

Du müsstest Dir im Detail Dein verwendete Theme angucken warum der Link dort so hinterlegt wird.

Viele Grüße
Tim

Momentan ist der Shop noch in der Entwicklung, daher habe ich noch die Unterverzeichnisse im Link.

Allerdings habe ich eine 2. Testinstallation, bei der ebenfalls UNterverzeichnisse im Link sind, und dort funktioniert es einwandfrei.

In der .htaccess ist die folgende Zeile enthalten:

    RewriteBase /stage1/source/

Wo müsste ich da anfangen? Bin mit der Struktur noch nicht so recht vertraut, und für jeden Tip dankbar.

Für den Link um das Logo würdest Dir das entsprechende Template von Deinem Theme raussuchen und Dir angucken wie der Link um das Logo gesetzt wird. Dies wäre beim dem Flow-Theme z.B. die Datei header.tpl welche Du im Verzeichnis /source/Application/views/flow/tpl/layout/header.tpl findest.

Im unveränderten Standard Theme wäre es folgende Zeile

und dort siehst wie der Link über

href="[{$oViewConf->getHomeLink()}]"

gesetzt wird.

Seit kurzen gibt es im Wiki unter Erste Schritte für Anwender, Händler und Entwickler eine Liste von Links/Quellen wo Du weiterführende Infos findest.

Je nachdem ob Du mehr aus der Perspektive Händler * in oder Entwickler * in findest Du dort einen Überblick für Anlaufstellen wie z.B. Schulungsvideos etc.

Also da komme ich nicht weiter, da ich nicht weiß wo der Link abgerufen wird.

Habe jetzt zwischenzeitlich noch folgendes feststellen können, und hoffe es gibt einen Hinweis darauf, was hier so schief läuft:

In der conifg.inc.php habe ich noch die Zeile $this->blSeoMode = false; drin stehen. Die hatte ich wohl mal für Testzwecke eingefügt und dann nicht mehr entfernt.
Wenn ich diese Zeile auskommentiere, oder lösche passiert folgendes:
Beim klick auf eine Kategorie, wird diese aufgrufen z. B. (https://meinedomain.shop/stage1/source/Holzpflegeprodukte/)
Wenn ich nun eine 2. Kategorie auswähle wird diese nur drangehängt (https://meinedomain.shop/stage1/source/Holzpflegeprodukte/Steinpflegeprodukte/)
Da es dieses Ziel so nicht gibt erscheint logischerweise eine Fehlerseite. Sowas habe ich vorher noch nicht gesehen.

Hat jemand eine Idee wodurch dieses abnormale Verhalten verursacht wird?

Hallo, warum macht man sich das so schwer?
Einfach den Startpunkt der Webseite beim Hoster setzen.
https://meinedomain.shop zeigt dort auf stage1/source, der vendor Ordner und die composer.json liegt unter stage1
Damit sind keine Änderungen an .htaccess und config.inc.php notwendig. Man installiert OXID einfach in den Ordner stage1.

Im Prinzip richtig, aber da an dem Shop noch gearbeitet wird, soll er nicht unter meinedomain.de direkt erreichbar sein. Dort ist eine “in Arbeit”-Seite abgelegt.
Bis jetzt hat das ja auch wunderbar funktioniert, nur das nach einmaligem aktivieren der Zeile $this->blSeoMode = false; dieses seltsame Verhalten auftritt. Meine Bedenken bestehen hinsichtlich dem bevorstehenden Live-Gang des Shops, das dies noch zum Problem wird.

TMP leeren und SEOs neu generieren.

Das hatte ich zwischenzeitlich auch schon gemacht, aber auch dies brachte keinen Erfolg.

@windes
Ich habe jetzt auch mal den Startpunkt der Seite verändert auf dev.meinedomain.de. Danach composer install ausgeführt, Cache geleert, Apache neu gestartet, $this->blSeoMode = false; auskommentiert, Browsercache geleert - und es werden weiterhin falsche Links angezeigt. Sobald ich $this->blSeoMode = false; wieder aktiviere, werden zwar keine SEO-freundlichen Links angezeigt, aber bis auf die Startseiten- und die Logo-Verlinkung funktioniert es erstmal.
Da ich jedoch nächste Woche online gehen möchte, hätte ich diesen fehler lieber vorher noch ausgemerzt.

Dies wird hier keiner beantworten können, entweder Du startest wieder beim Punkt Null und installierst Dir frische Shop-Instanz oder lässt Dir helfen, wenn Du selber nicht weiter kommst.

OK, natürlich möchte ich mir helfen lassen um eine Neuinstallation zu vermeiden. Also woran könnte es denn noch liegen? Gibt es noch weitere Lösungsansätze um dieses Verhalten des Shop´s zu unterbinden? Kann es vielleicht auch an der Server-Konfiguration liegen? Ich bin gerne bereit Informationen bereitzustellen.

Für die Selbst-Hilfe ist der Ansatz oben unter URL vom Logo führt nicht auf Startseite - #4 by indianer3c schon da, indem Dir über Debugging anschaust warum der Link so ist wie er ist? Warum er einmal so und einmal so?

Worauf ich hinaus wollte ist professionelle Hilfe gegen Entgelt in Anspruch zu nehmen, weil an dieser Stelle ein Punkt erreicht wo Du selbst anscheinend nicht so einfach zu einem Ergebnis kommst.

Daher wäre für die Selbst-Hilfe hier angebracht Du beginnst von Vorne bei einer Neuinstallation. Nebeneffekt ist, Du schaffst Dir Wissen an um zukünftig solche Einstiegsprobleme wie richtiger Pfad zu vermeiden. Nachteil daran ist, dass es Dich Zeit kosten wird.

Wenn Du für Dein selbst erschaffenes Problem eine Lösung benötigst, wäre dies ein Punkt wo Dir über Auftragsarbeit mehr geholfen wäre. Weil sich jemand der mit der Lösung Deines Problemes betraut wird sich dies im Detail angucken sobald er Zugang zum Server hat etc.

Das würde bedeuten, es guckt sich jemand Dein Problem an, welcher vom Wissen her in der Lage ist das oben angedeutete Debugging durchzuführen - wo Dir anscheinend das Wissen noch zu fehlt.

Zum Punkt Selbst-Hilfe wenn Dir Dein fehlendes Wissen zum grundsätzlichen Thema PHP Debugging aneignen möchtest könntest z.B. über diverse Quellen an Deinem Grundlagen-Wissen bezüglich Programmierung mit PHP und Debugging fortbilden A Detailed Guide to PHP Debugging

Nachteil wäre wieder der hohe Zeitaufwand den Du investieren müsstest um das so erworbene Grundlagen Wissen auf Dein Detail Problem mit dem OXID eShop anzuwenden.

Danke, das sind schon mal hilfreiche Hinweise für mich. Den Zeitaufwand scheue ich nicht um zukünftig kleinere Probleme dieser Art angehen zu können.

Ich habe jetzt auch mal eine frische Installation auf demselben Server vorgenommen und konnte dasselbe Verhalten bereits nach dem aufspielen der Demodaten beobachten. Also komplett ohne eigene Dateien(-anpassungen) und Module, ohne $this->blSeoMode = false;.

Auch cloudflare hatte ich einen kurzen Moment in Verdacht. Jedoch habe ich die Lösung eher durch Zufall bei der Vervollständigung der Shopeinstellungen ausfindig machen können.

Es waren keine URL´s bei der verwendeten Sprache eingetragen. Also tat ich dies, und jeder Link auf der Seite wurde mit folgender Erweiterung ergänzt: /?force_sid=90dd985cbaea617f0ba0834b5f01312a

Da dies ja auch nicht besonders Suchmaschinenfreundlich aussieht habe ich nur ein Leerzeichen anstatt der URL für die Sprache eingetragen. Und schon sieht alles perfekt aus.
Ich weiß natürlich, dass damit das eigentliche Problem (Bug?) nicht gelöst ist, aber vielleicht hat ja noch jemand dieses Verhalten in seinem Shop beobachtet.

Ansonsten werde ich mich vorsorglich neuer Ungereimtheiten mal mit dem debugging etwas mehr beschäftigen.

Danke für eure Unterstützung. :grinning:

Moin :slight_smile:

aus meiner Sicht ist dies kein Bug, sondern Deine Konfiguration des Shops ist nicht so wie Sie sein sollte. Aber dies aus der Ferne schwer zu beurteilen.

Normalerweise würde man auch eine Subdomain wie z.B. https://stage.meinedomain.shop für eine Staging Testumgebung anlegen. Die Subdomain würde man das Document-Root auf /source/ Verzeichnis des Shop Frameworks setzen wie nach Anleitung und Anwendungszweck vorgesehen.

Du hast anscheinend einfach Dein Vorgehen wiederholt, so wird es kein Stück besser.

Dies nicht notwendig. Die Sprach-URLs verwendest Du Bitte erst wenn Du für eine Sprache eine eigene Domain hast. Beispiel

https://meinedomain.shop
https://meinedomain.co.uk
https://meinedomain.fr

Der force_sid Parameter wird beim Sprachwechsel bei Domain Wechsel benötigt, damit die Benutzer Session mitgegeben wird, ansonsten würde diese verloren gehen.

Was machst Du da? :see_no_evil:

Hab ich gemacht, ist bei mir https://dev.meinedomain.shop

Die Sprach-URL´s waren bisher nicht gesetzt.

Ich habe jetzt auch nochmal eine Docker-instanz von oxid aufgesetzt und habe mal die Apache-Konfiguration verglichen. Bis auf PHP-FCGI ist das alles identisch

Das ist erstmal eine schnelle und schmutzige Lösung bis ich mich mit dem Debugging näher beschäftigt habe.

Kannst dir das ja gerne einmal ansehen.

Prüf Bitte zuerst ob in Deiner config.inc.php auch die Variable

$this->sSSLShopURL = null;

mit

$this->sSSLShopURL = 'https://dev.meinedomain.shop';

gesetzt ist. Dies eine häufige Fehlerquelle https://bisweb.me/oxid-eshop/onepage-seo/force-sid-url-parameter-verhindern-durch-https-umstellung.html

Zusätzlich lass Dir mal im Admin unter

  • Stammdaten
  • Grundeinstellungen
  • SEO-Tab

die Statische URL für die Startseite anzeigen:

Mehr Infos https://bisweb.me/oxid-eshop/onepage-seo/seo-optimierung-url-struktur-fuer-oxid-eshop.html

Weil wahrscheinlich hast unbewusst eins der zwei Dinge nicht berücksichtigt.

Oder Dein Theme ist rund ums Logo angepasst. Noch eine weitere Möglichkeit ein Modul ändert bei Dir die Links.

Klassiker wäre, dass mod_rewrite Modul von Apache nicht aktiviert. Sag bitte nicht, dass bei einem billig Hoster wie IONOS (früher 1&1) bist.

Ist gesetzt.

Diese ist unverändert:

Das Theme (Flow) wurde lediglich beim CSS und der Footer.tpl über ein Child-Theme angepasst.

Das mod_rewrite Modul arbeitet offensichtlich, denn die URL´s werden bei entsprechender (Fehl-)konfiguration verändert(umgeschrieben - nur halt nicht immer so wie gewünscht.
Der Server ist ein root-Server bei Vautron.

und wie sieht in Deinem Eltern Flow Theme die Datei /source/Application/views/flow/tpl/layout/header.tpl beim Block layout_header_logo aus?

Beispiel: https://github.com/OXID-eSales/flow_theme/blob/master/tpl/layout/header.tpl#L15

wie wird Dir die Systemgesundheit im Admin bezüglich mod_rewrite angezeigt?

Das Template ist noch in der Originaldatei:

mod_rewrite läuft:

Hmm…

Also ich kann Dein beschriebenes Verhalten nachstellen in einer CE 6.4.1, wenn das OXID eShop Framework aus der Methode getHomeLink() mit einem null Wert zurück kommt.

Update Dies habe ich erreicht indem ich bei mir die Code-Stellen auskommentiert.

Normaler Durchlauf wäre oxideshop_ce/ViewConfig.php at v6.10.1 · OXID-eSales/oxideshop_ce · GitHub und die Variable $sValue müsste mit Deiner Startseite gesetzt werden.

Dann gibt es extra ein Fallback, falls die statische Startseite nicht gefunden, indem er normale Startseite über oxideshop_ce/ViewConfig.php at v6.10.1 · OXID-eSales/oxideshop_ce · GitHub in die Variable $sValue ohne der SEO-URL start/ in Deinem Fall schreibt.

Da beide Stellen anscheinend fehlschlagen funktioniert bei Dir auf dem root-Server bei Vautron die Stelle getStr()-> nicht wie erwartet.

Ich würde an dieser Stelle vermuten bei Dir fehlt unter /source/oxfunctions.php Datei bzw. der Namespace über Composer nicht korrekt gesetzt.

Oder Du müsstest dort Debuggen und Deine php.ini erweitern.