productRedirect und categoryRedirect

[Modulfux]

Eigentlich sind die beiden Dateien, was die Umleitung bei verschobenen Produkten oder Kategorien angeht goldwert. Doch leider liegt der Fehler wieder einmal im Detail.

Die Shopstat-URL laufen wunderbar mit UTF-8, doch sobald ein Produkt oder eine Kategorie einen Umlaut enthält und der Link auch sauber mit urlencode() dargestellt wird, läuft die Umleitung ins Leere.

Dieses Problem ist bekannt und wurde bisher immer mit Aussagen, wie

Kommentiere einfach die Zeile xxx aus

Für die Funktionalität im Shop mag es ja passen, aber somit werden keine richtigen Header mehr gesendet und die Idee, die hinter dieser Idee steckt wird ad absurdum geführt. Es wäre ja das gleiche, als wenn meine Tür klappert und mir der Handwerker sagt: "Dann nageln Sie die zu".

Hat denn jemand von den Cracks hier eine Idee, woran es liegen könnte? Ins Shopstat-Forum wollte ich nichts posten, weil man sich dort erst einmal durch die SPAM-Einträge kämpfen muss.

Gruß
Ronny



Linkback: https://www.modified-shop.org/forum/index.php?topic=13650.0

[h-h-h]

Hi Ronny,
es wäre besser gewesen, wenn Du dies im dazugehörigem Thread gepostet hättest.

Es gibt noch weitere Gründe dafür, dass diese Lösung mit productRedirect nicht absolut perfekt ist.

Gruß

h-h-h

[web28]

Also die

gunnart_productRedirect.inc.php

funktioniert ohne Probleme auch wenn das Produkt Umlaute enthält. Mit UTF-8 sollte das auch funktionieren.

[Tomcraft]

Hi Ronny,
es wäre besser gewesen, wenn Du dies im dazugehörigem Thread gepostet hättest.
[...]

Welches ist denn der dazugehörige Thread? Könntest du das bitte noch quer verlinken?

Grüße

Torsten

[Modulfux]

[...] Mit UTF-8 sollte das auch funktionieren.

Eben sollte. Ich gebe web28 in der Hinsicht recht, dass es funktionieren sollte. Sobald aber Umlaute drin sind und damit meine ich keine Ersetzung mit "oe" gerät der Redirect ins endlose.

Beispiel:
- die Kategorie heißt "SCHÖNER WOHNEN"
- der Link in der Statusleiste sieht auch aus so "/SCHÖNER-WOHNEN:::286_151.html"
- beim Link kopieren steht das "/SCH%C3%96NER-WOHNEN:::286_151.html" (also auch richtiges urlencode)

Bei genau solch einer Sache funktioniert dann das redirekt nicht mehr. Es hat definitiv etwas mit den Umlauten zu tun. Ich denke das war auch der Grund, wieso z.B. im E*C*B-Shop, der ja auch auf utf-8 lief, diese Datei rausgeflogen ist.

Gruß
Ronny

[web28]

Was steht denn in der Adresszeile des Browsers wenn die Katgorie aufgerufen wird?

/SCH%C3%96NER-WOHNEN:::286_151.html ?

Das macht der Browser aber selber, aber nicht jeder Browser. (Opera wandelt die URL nicht um, meine ich)

Aus diesem Grund sollte es auch bei UTF-8 kein Umlaute in den Links(URL) geben!

In der Gunnartdatei werden die 2 Links verglichen, einmal der Link in der URL und dann der Link, wie der Shop ihn erzeugt, also /SCHÖNER-WOHNEN:::286_151.html
Hier muss man also ansetzten und einen vom Browser codierten Link wieder zurückwandeln.

/SCH%C3%96NER-WOHNEN:::286_151.html müsste also vor dem Vergleich decoded werden oder /SCHÖNER-WOHNEN:::286_151.html encodet.

Dann sollte der Stringvergleich wieder übereinstimmen.

Gruss Web28

[Modulfux]

Prima, da sind wir doch schon mal einen Schritt weiter.
Im Browser sieht die URL in der Adressleiste so aus:
SCHÖNER-WOHNEN:::286_151.html

Du hast Recht, der Opera wandelt die Umlaute nicht um.
Dann kann es sich ja nur um folgende Passage handeln, oder?

Code: PHP  [Auswählen]

if($RedirectionLink) {
        // Gewünschter Link (OHNE http/https-Zeug, Session-ID und weitere $_GET-Parameter)
        $ProductLink = str_replace(array(HTTP_SERVER,HTTPS_SERVER),'',preg_replace("/([^\?]*)(\?.*)/","$1",$RedirectionLink));

        // Angefragte Adresse (OHNE Session-ID und weitere $_GET-Parameter)
        $CurrentLink = preg_replace("/([^\?]*)(\?.*)/","$1",$_SERVER['REQUEST_URI']);

        // 301er-Weiterleitung mit Unterscheidung SSL / kein SSL
        if(strpos($ProductLink, $CurrentLink) === false) {
          //BOF - web28 - 2010-08-16 - New SSL  handling  defined by $request_type
          //if ( (ENABLE_SSL == true) && (getenv('HTTPS') == 'on' || getenv('HTTPS') == '1') ) { // Bei aktivem SSL
          if ( (ENABLE_SSL == true) && ($request_type == 'SSL') ) { // We are loading an SSL page
            //EOF - web28 - 2010-08-16 - New SSL  handling  defined by $request_type
            if (substr($RedirectionLink, 0, strlen(HTTP_SERVER)) == HTTP_SERVER) {
              $RedirectionLink = HTTPS_SERVER . substr($RedirectionLink, strlen(HTTP_SERVER));
            }
          }
 

Gruß
Ronny

[web28]

$CurrentLink kann browserspezifisch unterschiedlich sein, das macht die Sache komplizierter.

Genau, lasse Dir $ProductLink und $CurrentLink ausgeben und vergleiche Sie, dann musst Du im Bedarfsfall $CurrentLink decoden.
Einen encodierten Link sollte man an dem % Zeichen erkennen können.
Probiere mal nach Zeile 7 mit:

Code: PHP  [Auswählen]

if(strpos($CurrentLink, '%') !== false) {
  $CurrentLink = urldecode($CurrentLink);
}

Gruss Web28

[Modulfux]

Bingo! Respekt und Danke. Das ist genau die Lösung. Vielleicht sollte man diesen Teil gleich in den Trunk einfügen.

[Pumpgun]

Bin gerade auf folgendes Modul gestossen: Duplicate Content vermeiden – categoryRedirect für xt-Commerce mit ShopStat

So wie ich das testen konnte scheint das ganze ohne Probleme mit der 1.05 zu laufen.

Was sagen denn die Experten dazu ?

Gruß
Pumpgun

[Tomcraft]

Sieht interessant aus, das schauen wir uns mal genauer an.

Grüße

Torsten

[Modulfux]

Bin gerade auf folgendes Modul gestossen: Duplicate Content vermeiden – categoryRedirect für xt-Commerce mit ShopStat
[...]

Aber mit ShopStat in Verbindung mit utf8 klappt es nicht.

Gruß
Ronny