Zur Machart Studios Website
Back to top

RealURL-Fehler: Reason: Segment „“ was not a keyword for a postVarSet as expected!

Bei der Neuinstallation der Typo3-Extension RealURL läuft in den seltensten Fällen alles glatt. Oft sind es Kleinigkeiten oder nicht nachvollziehbare Fehlermeldungen. Viele Fehlermeldungen sind selbsterklärend und reproduzierbar. In manchen Fällen auch diese Fehlermeldung:

Segment „“ was not a keyword for a postVarSet as expected!

Diese Fehlermeldung kann an simplen Fehlern liegen und entweder bei allen Seiten erscheinen, unregelmäßig auftauchen oder nur im Browser auftreten mit dem man auch im Backend eingeloggt ist.

Hier eine Checkliste um den Fehler zu beseitigen:

1. Root-Page in der Real-URL Konfiguration setzen:

$TYPO3_CONF_VARS['EXTCONF']['realurl'] = array(
...
'rootpage_id' => 7,
'firstHitPathCache' => 1,
...
);
Die Konfigurationsdatei kann entweder in „/typoconf/realurlconf.php“ oder direkt in der „/typoconf/localconf.php“ editiert werden. Alternativ erleichtert die Extension: „danp_realurlconfigurator“ die Arbeit, da dadurch die Konfigurationsdatei direkt im Backend editierbar wird. Im diesem Zuge kann neben der korrekten Seiten-ID des Seitenausgangspunktes auch die Einstellung „FirstHitPathCache“ ausprobiert werden.

2. Haken setzen bei „Ist Start der Website“:

Um RealURL über Flexform zu informieren welche Seite die Startseite ist, muss ein Haken gesetzt werden unter: Web > Seite > „Startseite im Seitenbaum“ > Seiteneigenschaften > Optionen > (ggf. Zweite Optionspalette anzeigen) > Ist Anfang der Website. Zudem kann es sein, dass ein weiteres eingebundenes Template einen „Ist Anfang der Website“ zuviel hat.

3. Real URL ID-to-path mapping leeren:

Um ggf. falsche Caches zu leeren, sollte nicht nur der Typo3-Cache geleert werden, sondern auch das RealURL Mapping. Dieser Schritt ist hilfreich wenn der Fehler nur teilweise auftaucht. Dann ist es sinnvoll wenn „/seite/unterseite“ nicht funktioniert auch die gespeicherten Informationen bzgl. „/seite/“ zu löschen.
Die Option ist zu finden unter: Web > Info > RealURL-Verwaltung > ID-to-path mapping > Löschen

4. Datenbanktabellen leeren:

Erst wenn der Punkt 3 ausprobiert wurde, sollte der Datenbankinhalt der RealURL Tabellen geleert werden. Die Datenbank darf jedoch nicht gelöscht werden. Hilfreich ist hierbei die Extension „phpmyadmin„. So können Sie die Tabellen die mit „tx_realurl_*“ beginnen einfach leeren.

5. Admin Panel deaktivieren:

Wenn das Problem im Zusammenhang mit dem genutzten Browser steht, also das Problem nur in dem Browser vorkommt, in dem man auch eingeloggt ist, sollte es helfen das Admin-Panel zu deaktivieren.
Das Admin-Panel wird per TypoScript aktiviert und kann so auch deaktiviert werden:
Template > „Templatedatei im Seitenbaum wählen“ >Setup >“config.admPanel = 0″.
Den Fehler konnte ich so nie nachvollziehen. Ggf. ist das Deaktivieren des Browsercaches durch den WebDeveloper nützlich, um dieses Verhalten direkt auszuschließen. Auch das Besuchen der neuen Unterseite mit einem anderen Browser (ggf. auch erstmalig) kann hierbei helfen.

6. Konfigurationsdatei:

Wer garnicht weiterkommt kann, wirklich nur als Verzweiflungstat, versuchen im Web umhergestreute Konfigurationsdateien von RealURL auszuprobieren und das Verhalten zu reproduzieren. Dabei sollte ein Backup der alten Konfigurationsdatei gemacht werden (über den Zwischenspeicher hinaus). Wer noch Zeit mitbringt, sollte die ausführliche Dokumentation der Extension im Typo3 Repository durcharbeiten, um den Fehler Konfigurationsdatei ausschließen zu können und gleichzeitig umfassendes Wissen anzuhäufen.
Abschließend würde ich mich freuen zu erfahren, ob es mehr Möglichkeiten oder Symptome dieses Fehlers gibt und wem welche Lösung geholfen hat.

6.1. RealURL „Hack“:

Laut Alex von einpraegsam.net kann der Fehler bei bestimmten Serverkonfigurationen beseitigt werden, indem man die Methode „decodeSpURL($params)“ (Zeile 905) in der Datei „class.tx_realurl.php“ mit folgenden Code erweitert: $this->pObj->siteScript = substr($_SERVER['SCRIPT_URL'], 1); Danke Alex.

7. Sichtbarkeit im Menu:

Es kann auch vorkommen, dass RealURL den URL-Namen nicht erfassen kann, da die neue Seite als „nicht im Menu anzeigen“ markiert ist. Ein Umschalten und Aufrufen im Frontend löst das Problem, auch wenn die Seite daraufhin erneut als „nicht im Menu anzeigen“ markiert wird.

8. tt_news Datensatzstruktur:

Scheinbar kann es in Verbindung mit der beliebten News-Extension tt_news dazu kommen, dass RealURL sich verschluckt wenn Sysordner (Datensatz „Aufbewahrer“) und die Contentseite mit der Listenansicht auf der gleichenHierarchieebene liegen und gleich benannt sind. Ich könnte mir sehr gut vorstellen, dass der Sysordner sich auch mit der Latest und Singleansicht beißt. Danke an lentizz.

Von Eduard Weber

Ein Machart-Macher mit ungestilltem Tatendrang, dazu voll Herz, Tiefe, Mut und Laune. Als gelernter Mediengestalter und Vollblutwerber im positiven Sinn, arbeitet er effizient und kundenorientiert. Kundenzufriedenheit ist eben das A und O für ihn. Eduard Weber ist zuständig für die strategische und kreative Kundenberatung, der seine Fäden im ganzen WorldWideWeb spinnt. Eduard Weber bei Google+

28 Kommentare

  1. 24. November 2010 Alex Antworten

    Klasse Artikel, danke!

  2. 20. Dezember 2010 Alex Antworten

    Wenn Startseite Shortcut ist, dann entweder „Weiterleiten auf erste Unterseite“ oder auf eine bestimmte PID.

  3. 20. Dezember 2010 Alex Antworten

    Auf einem bestimmten Server einer unserer Kunden muss man diese Zeile in den Code einfügen (ich kann mir aktuell leider nicht erklären, was an der Serverkonfiguration nicht stimmt) – Zeile 905 in class.tx_realurl.php innerhalb der Methode decodeSpURL($params):
    $this->pObj->siteScript = substr($_SERVER[‚SCRIPT_URL‘], 1);

    Erst damit tritt die Meldung nicht mehr auf

  4. 20. Dezember 2010 Eduard Weber Antworten

    Danke!
    Ich habe den Artikel editiert.

  5. 12. Januar 2011 goooguy Antworten

    danke, ich war schon am verzweifeln.
    jemand hatte dieses dämlichen haken „ist start der webseite“ an der falschen stelle gesetzt.

  6. 27. Januar 2011 redkadett Antworten

    Vielen Dank! Das ist ein super Artikel !

  7. 19. April 2011 lentizz Antworten

    Es kann auch daran liegen, dass der Ordner mit den Newsartikeln den gleichen Namen hat wie die Seite mit der Listview und auf gleicher Ebene liegt.

    • 19. April 2011 machart Antworten

      Das müsstest du genauer erläutern, damit ich das in den Artikel aufnehmen kann. Mit Ordner meinst du einen Sysordner? Also geht es hier um tt_news? Bisher ja noch nicht…

      • 12. Juni 2013 JBrooks

        Zunächst einmal vielen Dank für diesen super ausführlichen Artikel!

        lentizz hat mich in meinem Fall auf den Fehler gebracht. Und zwar hatte ich den RealURL Fehler genau bei einer Seite „/veranstaltungen/detailansicht/“.

        Mein Seitenbaum sah bisher so aus:

        – Sonstige Seiten (Seite)
        –Veranstaltungen (Seite)
        —Detailansicht (Seite versteckt im Menü))
        – Veranstaltungen (SysFolder)

        Erst als ich beim SysFolder in den Seiteneigenschaften den Haken bei „Nicht in sprechende URL aufnehmen“ gesetzt habe, hat der Aufruf der Detailansicht auf einmal funktioniert. Keine Ahnung warum ein SysFolder überhaupt bei der Generierung einer URL eine Rolle spielt, aber das war tatsächlich der Fehler.

  8. 27. April 2011 lentizz Antworten

    Sry für meine Ungenauheit. Ja, ging um tt_news. Hatte das Problem mal, weil eben der News Sysordner gleich hieß wie die Seite mit der Listview. Dadurch provoziert man genau den gleichen Fehler.

  9. 12. Juni 2011 Tom Studer Antworten

    — Auf einem bestimmten Server einer unserer Kunden muss
    — man diese Zeile in den Code einfügen (ich kann mir
    — aktuell leider nicht erklären, was an der
    — Serverkonfiguration nicht stimmt) – Zeile 905 in
    — class.tx_realurl.php innerhalb der Methode
    — decodeSpURL($params):
    — $this->pObj->siteScript = substr($_SERVER[‚SCRIPT_URL‘], 1);

    Vielen vielen Dank!! Nach stundenlangem Suchen hat erst dies bei mir geholfen. Als ich realurl installierte ging ich eigentlich nicht davon aus, dass ich es patchen muss.

  10. 6. September 2011 Keeev Antworten

    Das Problem tritt auch auf wenn man ein zusätzliches Template (z.B. für Direct Mail) angelegt hat und vergisst den Haken bei „is Root“ zu entfernen.

  11. 7. Oktober 2011 Didi Antworten

    Danke, hat mir sehr geholfen!

  12. 19. Februar 2012 Eddy Antworten

    Habe alles ausprobiert!
    Problem besteht leider immer noch 🙁

  13. 17. September 2012 Kai Antworten

    Hallo,

    hatte gerade bei einem 1&1 Paket das Problem. Der Tipp von Alex (decodeSpURL($params)) hat geholfen.

  14. 10. Januar 2013 Manuel Antworten

    Danke Alex! Hat geklappt!
    Anbieter: one.com

  15. 27. Februar 2013 Ingo Antworten

    Punkt 8 kann ich definitiv bestätigen.

  16. 12. März 2013 Harry.de Antworten

    Was für ein guter Artikel.
    Weiter so!

  17. 17. Juni 2013 Dennis Antworten

    Ich habe den Wald vor lauter Bäumen nicht gesehen und dein Punkt Nr. 8 tt_news Datensatzstruktur – war tatsächlich der Übeltäter.

    Ich habe es einfach nicht gesehen.

    Ich wollte mich an dieser Stelle einfach mal bedanken und ganz herlzlich DANKE sagen.

    Greetz aus Dortmund

  18. 12. Februar 2014 Markus Antworten

    Bei mir haben alle oben genannte Punkte nichts geholfen. Erst als ich festgestellt habe, dass der Cache Fehler beim Schreiben macht und ich diesen deaktiviert habe, geht die Seite.
    ‚init‘ =>
    array (
    ‚enableCHashCache‘ => false,

  19. 13. Februar 2014 Eduard Weber Antworten

    Ha!!!
    Ich würde raten:
    Der Fehler ist, dass der decode Cache von RealURL den URL-Namen von z.B. Newsbeiträgen statt der ID speichert wo eigentlich eine ID hingehört (also z.B. steht im Cache dann newsid=name-der-news statt newsid=99).

    Stimmts Markus? Wenn Ja, dann wäre ich über eine Info sehr dankbar!!! Das Problem raubt mir im Moment den Schlaf!

  20. 22. April 2014 Matthias Hermsdorf Antworten

    Als ich eine zweite rootpage angelegt hatte, bekam ich auf manchen Seiten diesen Fehler.

    Das use-as-rootpage habe ich eingefügt, caches gelöscht, aber das war es alles nicht. Der Fehler war trivialer.

    Ich hatte die rootpage in „Dingsdingswebsite – Startseite“ umbenannt. Als ich sie in „Dingsdingswebsite“ umbenannte, ging es wieder. RealURL hat also ein Problem mit Leerzeichen oder – im Seitentitel.

    Der Artikel hier war trotzdem interessant.

  21. 6. August 2015 Sebastian Afeldt Antworten

    Ein Grund könnte auch sein, dass im Typoscript bei einem HMENU-Objekt mit der Eigenschaft „excludeUidList“ bestimmte Seiten ausgeschlossen werden. Auch wenn man diese Seiten per Link aufrufen möchte, bekommt man u.U. diesen Fehler. Dann kann man die Seiten kurz aus der Liste nehmen, aufrufen (damit die RealURLs erzeugt werden können) und dann wieder in die Liste eintragen.

    Sehr nützliche Seite übrigens!

  22. 31. März 2016 Pat Antworten

    firstHitPathCache gibts laut realURL Dokumentation nicht mehr:
    [….This option was removed from RealURL in version 1.11.0…]

  23. 25. Mai 2018 Ralf Antworten

    Super! Problem gelöst! Vielen Dank!

  24. 26. Oktober 2020 Andreasor Antworten

    ich stimme zu

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Machart Studios Werbeagentur