Heute ist Saturday, der 15. December 2018

Realurl: Segment ... was not a keyword for a postVarSet as expected!

Nachdem der Fehler plötzlich reproduzierbar wieder aufgetreten ist, bin ich mal auf Ursachenforschung gegangen.

Diese Segmentfehler werden mit der Zeit ziemlich nervig. Da hat man brav die Rootseite festgelegt und auch in der Konfig eingetragen und hofft dann das Thema ist damit beendet. Doch plötzlich, wie aus dem nichts, werden einige Seiten nicht mehr gefunden. In meinem Falle allerdings nur, wenn man nicht gleichzeitig im Backend angemeldet ist!

Bevor ich nun wieder lange bei Google suche, bin ich der Fehlermeldung mal selbst auf den Grund gegangen. Da angemeldete BE-User nicht betroffen waren, vermutete ich ein Problem mit dem Cache von Realurl. Und so war es dann auch. Der Cache lieferte im Fehlerfall eine falsche Page-ID. Und zwar war es die ID der übergeordneten Seite. Dafür verantwortlich ist die Methode pagePathtoID der Klasse tx_realurl_advanced. In dieser findet man das folgende Stück Code:

    $copy_pathParts = $pathParts;

    while(1) {

    $result = $GLOBALS[\'TYPO3_DB\']->exec_SELECTquery(

    \'tx_realurl_pathcache.*\',

    \'tx_realurl_pathcache,pages\',

    \'tx_realurl_pathcache.page_id=pages.uid

    AND pages.deleted=0

    AND hash=\'.$GLOBALS[\'TYPO3_DB\']->fullQuoteStr(substr(md5(implode(\'/\',$copy_pathParts)),0,10), \'tx_realurl_pathcache\').\'

    AND rootpage_id=\'.intval($this->conf[\'rootpage_id\']).\'

    AND (expire=0 OR expire>\'.time().\')\', \'\', \'expire\', \'1\' );

    if ($row = $GLOBALS[\'TYPO3_DB\']->sql_fetch_assoc($result)) {

    break;

    } elseif ($this->conf[\'firstHitPathCache\']) {

    break;

    } else {

    // If no row was found, we simply pop off one element of the path and try again until there are no more elements in the array - which means we didn\'t find a match!

    array_pop($copy_pathParts);

    if (!count($copy_pathParts))

    break;

    }

    }

In dieser Schleife wird der Cache nach Informationen über die aktuelle Seite abgesucht. Dafür zerlegt Realurl den Pfad in seine Teile und fängt dann mit dem tiefsten Teil an. Das ist also meist seitenname.html. Wird nichts gefunden, dann geht es mit dem nächsten Stück weiter. Und genau hier liegt das Problem:

Sollte nämlich für die übergeordnete Seite schon etwas im Cache liegen, dann wird deren PageID zurückgegeben. Das ist natürlich Schwachsinn. Interessanterweise gibt es aber die Konfigurations-Variable firstHitPathCache. Ist diese aktiviert, tritt der Fehler nicht mehr auf. Die Suche im Cache wird dann sofort abgebrochen.

Eingestellt wird diese Variable in der Konfiguration von Realurl, also üblicherweise in der typo3conf/localconf.php.

    \'www.meinedomain.de\' => array(

    \'pagePath\' => array(

    \'type\' => \'user\',

    \'userFunc\' =>; \'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main\',

    \'spaceCharacter\' => \'-\',

    \'languageGetVar\' => \'L\',

    \'expireDays\' => 3,

    \'firstHitPathCache\' => 1,

    \'rootpage_id\' => \'1\',

    ), ...

 Und warum ist der Fehler nun so plötzlich aufgetreten? Nun der Realurl räumt den Cache von Zeit zu Zeit wieder frei. In der Konfig oben beispielsweise alle drei Tage. Wenn dies geschieht, hängt es davon ab, in welcher Reihenfolge die Seiten aufgerufen werden. Wird erst die Kindseite und danach die Elternseite angeklickt, funktioniert alles normal. Im umgekehrten Fall gibt es den Fehler.

Der Vollständigkeit halber sei noch die Version von RealUrl erwähnt: Es handelt sich um Version 1.1.4.

Kommentare

Roman, 09-07-07 16:09:
Hallo,
ich nutze auch seit kurzem Typo3 und spiele nun mit RealURL herum. Bei mir ist exakt derselbe Fehler aufgetreten, jedoch habe ich keinen Config-Eintrag in meiner Typo3Conf/Localconf.php?

Wie kann das sein? Muss ich dort einen Eintrag anlegen? Das interessante ist, dass RealURL schon lief, nun aber Probleme macht.

Gruß
Roman
Rene, 23-07-07 15:43:
Hallo Roman,

die Konfiguration von RealUrl hast du wahrscheinlich direkt in der Extension, in der Datei ext_localconf.php angegeben. Dort kannst du die Änderungen natürlich auch machen, allerdings hast du dann ein Problem, wenn du RealUrl mal aktualisierst. Der Extension-Manager wird dir die Datei nämlich ohne Nachfrage überschreiben!

Daher ist die Konfiguration in der typo3conf/localconf.php besser aufgehoben. Paß aber auf, ein Teil der Datei wird dynamisch verändert. Das ist aber entsprechend markiert.

Ich war übrigens auch der Meinung, daß RealUrl bei mir fertig eingerichtet ist, bis ich dann eines morgens den obigen Fehler hatte. Der ist halt ziemlich tückisch! Aber seither hatte ich keine Probleme mehr. :-)

Viele Grüße,
René
Sebastian, 28-11-07 12:02:
1000000000000000 mal DANKEEEE!!!! Du hast meine Nerven gerettet und mich vor einem sehr langweiligen Fehlersuch Tag bewahrt.

Gruss
Sebastian
Mario, 06-12-07 11:46:
Hey, super vielen Dank für die Lösung! Ich benutze RealURL 1.2.1 in Verbindung mit dem aeurltool. Auch dort tritt der Fehler noch auf! Warum wird das nicht gefixt? Ist es überhaupt ein Bug oder ein gewünschtes Verhalten? Ist ja ziemlich nervig (auch das mit dem \"ausloggen\" aus dem Backend kanns ja irgendwie auch nicht sein!)
robert, 14-12-07 16:55:
danke!
Sven, 26-03-08 11:03:
Auch mir hat deine Anleitung sehr geholfen :)
Danke
Willi, 06-08-09 17:47:
Ab der Version 1.5 wird der Variable keine Beachtung nicht mehr geschenkt! Der Fehler tritt dann erst recht immer wieder auf. Lösung: Variable setzen und auf 1.4 downgraden.

MfG, Willi
Alex, 12-04-10 14:21:
Ja, du must eine Config eintragen, siehe:
http://www.oliver-thiele.de/cms-typo3/tutorials/realurl-tutorial.html
Julian, 22-07-10 20:20:
Weiss jemand wie ich da wieder raus komme?
Wie kann ich diesen Realurl Cache manuell löschen, ich kann mich nämlich gar nicht mehr in mein Backend einloggen. Error! Reason: Segment \"typo3\" was not a keyword for a postVarSet as expected!

\'firstHitPathCache\' => 1,
habe ich gesetzt
René, 23-07-10 10:05:
Vermutlich sind deine URL-Rewrite Regeln in der .htaccess falsch. Wenn du sie erstmal komplett entfernst, solltest du auch wieder ins TYPO3 BE kommen.
Add comment
*









*

*

* - required field