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.

This entry was posted on 03.07.07 and is filed under TYPO3. You can leave a response, or trackback from your own site.