Wenn indexed_search nicht indiziert

Das hier ist eine kleine Schritt-für-Schritt Checkliste um zu prüfen, warum indexed_search nicht funktioniert.

1. Logge Dich aus dem Backend aus.

Oder verwende einen anderen Browser um das Frontend zu besuchen während Du im Backend arbeitest. Wenn man im Backend eingeloggt ist, wird das Caching manchmal automatisch deaktiviert.

2. Prüfe, ob das indexing eingeschaltet ist.

Im TSsetup: page.config.index_enable = 1

3. Prüfe, ob das Caching deaktiviert wurde.

Die Seiteninhalte werden nur indiziert, wenn sie auch in Typo3 gecached werden, also in eine der Tabellen cf_cache… wandern. Der absolute indexed_search-Killer ist folglich $GLOBALS[„TSFE“]->set_no_cache();
Eingrenzung:
Diese Zeile

if ($GLOBALS['TSFE']->no_cache) echo "No Cache ist aktiviert!";

als letzte Zeile in die index.php von Typo3 einfügen. Wenn der Text beim Aufruf der Seite ausgegeben wird, dann nacheinander folgende Sache prüfen:

  • Ist unter den Seiteneigenschaften -> Verhalten -> Cache deaktiviert?
  • Gibt es im TSsetup diese beiden Zeilen?
    config.no_cache = 0
    config.cache = 1
  • Muss eine Extension speziell zum Cachen konfiguriert werden wie z.B. plugin.tt_news.allowCaching = 1
  • Ist eine Extension auf der Seite im Einsatz, die im Quelltext set_no_cache(); aufruft?

Der „Übeltäter“ kann durch die syslog eingegrenzt werden. Dazu in der typo3conf/localconf.php diesen Eintrag machen und dann die Seite im Frontend neu laden.

$TYPO3_CONF_VARS['SYS']['systemLog'] = 'file,log.txt,0';

Im Stammverzeichnis erscheint dann eine Datei log.txt – mit einem Eintrag in dieser Art „$TSFE->set_no_cache() was triggered by typo3conf/ext/dbfindit/pi1/…“ – dort muss man suchen!

4. Enthält der Quelltext die Such-Marker?

Alle Texte, die von der indexed_search durchsucht werden sollen müssen innerhalb dieser Marker sein:

<!--TYPO3SEARCH_begin-->
... dieser Text wird indiziert ...
<!--TYPO3SEARCH_end-->

5. Ist eine fe_login-Box auf allen Seiten eingebunden?

So schön es auch ist, ein Login-Formular für Benutzer auf allen Seiten zu haben: Das fe_login-Formular schaltet per $TSFE->set_no_cache(); das Caching ab. Abhilfe: Das Formular von einer anderen Seite per AJAX laden und einbinden.

6. Ist die Extension „crawler“ installiert?

Wenn Crawler aktiv ist, wird indexed_search nicht ausgeführt. In der Core-Extension indexed_search unter typo3/sysext/indexed_search/class.indexer.php findet man in der function hook_indexContent alle Entscheidungen darüber, ob indiziert werden soll oder nicht. Der ganze sieht ungefähr so aus:

if ($pObj->config['config']['index_enable']) {
   if (!$indexerConfig['disableFrontendIndexing'] || $this->crawlerActive) {
       if (!$pObj->page['no_search']) {
          if (!$pObj->no_cache) {
               if (!strcmp($pObj->sys_language_uid,$pObj->sys_language_content)) {
...

7. Wurde bei der Konfiguration von indexed_search das Indexing abgeschaltet?

Unter „Erweiterungen“ auf die Extension „indexed_search“ klicken. In den Reiter „Konfiguration“ wechseln. Etwa in der Mitte befindet sich eine Checkbox mit dem Titel „Disable Indexing in Frontend“. Ist das Häkchen gesetzt? Dann kann es nicht klappen. Die Variable befindet sich auch (serialisiert) in der localconf.php in der Zeile

$GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['indexed_search'] ...

Typo3 Cache-Tabellen regelmäßig löschen

Zum Debuggen hilft mir auch dieses kleine PHP-Script, dass alle Cache-Tabellen und Indizierungen löscht. Eignet sich auch gut zum regelmäßigen Leeren der Cache-Tabellen in Typo3, falls z.B. eine Cache-Killer-Extension wie Kaldender „cal“ im Einsatz ist: Dieses Script als Cron-Job (evtl. ohne die index_…-Tabellen) regelmäßig aufrufen…



Nächste Probleme: indexed_search indiziert, aber zeigt „NO results“ an

1. Verwendest Du das aktualisierte Template von indexed_search?

Lieber noch mal abgleichen: unter typo3/sysext/indexed_search findet man das aktuelle Template. Es enthält evtl. kleinere Änderungen am Code, z.B. neue ID-Attribute oder hidden-Felder. Verwendet man ein eigenes Template aus alten Projekten, fehlen diese IDs möglicherweise.

...





...

2. Stimmt die search.rootPidList?

Im Setup gibt es eine Einstellung für plugin.tx_indexedsearch.search.rootPidList die zu Problemen führen kann. Klassischer Fall: Man hat eine Multidomain-Installation und möchte die Suchergebnisse nur auf eine Domain beschränken. Eigentlich würde man laut Doku so etwas machen, wobei „621“ die Page-ID der entsprechenden Domain im Seitenbaum ist.

plugin.tx_indexedsearch.search.rootPidList = 621

Warum das nicht funktioniert ist mir bis heute nicht ganz klar. Funktioniert hat hingegen folgende Einstellung:

plugin.tx_indexedsearch {
   _DEFAULT_PI_VARS.sections=rl621_621
   search {
      rootPidList = -1
   }
}

Die Variable rl621_621 (rl steht für „RootLevel“) landet als Marker ###SECTIONS### im Such-Template:

   

Nächstes Problem: Suchergebnisse von indexed_search werden angezeigt, aber Pagination / Paginierung / Pagebrowser / Seitennavigation funktioniert nicht.

1. Verwendest Du einen eigene Suchbox (z.B. macina_searchbox) oder ein ganz eigenes Template für das Suchfeld? Kommt die id=“tx_indexedsearch_pointer“, „tx_indexedseach“ oder „tx_indexedsearch_freeIndexUid“ doppelt im DOM vor?

Das Problem an dem „normalen“ indexed_search-Plugin ist, dass das Suchfeld und die Suchergebnisse fest miteinander verbunden sind. Möchte man ein Suchfeld auf allen Seiten integrieren, dann stört das sofort, weil auf der Suchergebnis-Seite auch das Suchfeld zu einer Ergebnis-Liste wird. Die meisten Leute greifen dann auf eine andere Extension zurück (macina_searchbox) oder bauen das Formular nach, das von indexed_search geliefert wird.
Der Haken dabei: In das Formular mit dem kleinen Suchfeld für alle Seiten wird versehentlich das id-Attribut mitkopiert:

Diese IDs werden aber im PageBrowser der Suchergebnis-Liste per JavaScript manipuliert:

onclick="document.getElementById('tx_indexedsearch_pointer').value='0';document.getElementById('tx_indexedsearch_freeIndexUid').value='-1';document.getElementById('tx_indexedsearch').submit();return false;"

Sobald das Dokument zwei Elemente mit der gleichen ID enthält, wird nur das erste Element verändert. Wenn jetzt zufälligerweise das Suchfeld im DOM vor der Suchergbnisliste erscheint, dann wird es an der falschen Stelle geändert. Das gemeine daran: Evtl. hat man bei einer anderen Webseite das Problem nie gehabt, trotz identischer Setup-Scripte und Templates. Nur war dort die Reihenfolge zwischen Suchergebnis-Liste (indexed_search) und Suchbox (macina_searchbox) im HTML-Quelltext (DOM) anders herum, darum funktioniert es.
Lösung: Alle ID-Attribute der FORM- und INPUT-Tags im kleinen Suchfeld eindeutig machen. Und eindeutig heißt: nicht tx_indexedsearch, tx_indexedsearch_pointer oder tx_indexedsearch_freeIndexUid verwenden. Man kann die IDs bei dem Template für die Suchbox auch ganz entfernen.

2. Hast Du wichtige Teile aus dem Suchergebnis-Template gelöscht?

Klassischer Fehler: Du möchtest, dass über der Suchergebnis-Liste kein Feld für „Suche, erweiterte Suche“ etc. erscheint. Dazu hast Du ja ein eigenes Suchfeld integriert. Also: Raus damit aus dem Template. Problem ist aber, dass auch die hidden-Felder mit ids (siehe oben) verschwunden und das JavaScript findet sein Ziel nicht.
Lösung: Alle Felder und Formulare, die nicht angezeigt werden sollen per CSS ausblenden (display: none) – NICHT aus dem Template löschen!

Gute Links zum Thema:
Tutorial zu crawler

10 Gedanken zu „Wenn indexed_search nicht indiziert“

  1. Gerne! Der ganze Artikel ist eigentlich extrem eigennützig, Du glaubst nicht, wie oft wir unsere eigene Seite schon zu dem Thema gegoogelt haben 😉

  2. Hallo david!

    Danke vielmals für diese tolle Übersicht, echt wertvoll.

    Schau mal hier, http://www.typo3forum.net/forum/typo3-fragen-probleme/48224-indexed-search-indexiert.html, der User „tsk“ weist darauf hin, dass auch der browsereigene Cache stören kann. So empfiehlt es sich im Zusammenhant mit indexed_search, mit zwei Browsern zu arbeiten.

    Wollte dies noch ergänzen – der Tipp von „tsk“ war für mich die Lösung.

    Weiterhin alles Gute und Gruss
    Peter

  3. Hallo Peter!
    Das hatte ich ganz oben im ersten Punkt versucht deutlich zu machen: „…verwende einen anderen Browser um das Frontend zu besuchen während Du im Backend arbeitest….“ Danke Dir trotzdem für den Hinweis – freut mich, wenn diese Seite weiter ergänzt wird.

  4. Eben habe ich das Problem durch Deaktivieren und Aktivieren der indexed_search-Extension beheben können. Vermutlich waren die Hooks nicht registriert (keine Ahnung warum).

  5. Die Suche wollte bei uns NICHT indexieren… und folgende Zeile war schuld in TS.
    Vielleicht hilft es Jemand anders, der die Suche bei TYPO3 7.5.x einsetzt:

    config.sys_language_uid = 1

    war das Problem.

  6. @ David: Herzlichen Dank für diese ausführliche Hilfestellung!

    @ Shaun: Noch viel mehr Dank für deinen Hinweis mit der „config.sys_language_uid = 1“. Ich habe tagelang nach der Ursache gesucht, warum an einem bestimmten Tag die Indizierung stoppte und nicht wieder anlaufen wollte. Und ich habe wirklich alles versucht – bis zum Deaktivieren der „Entscheidungen“ in Punkt 6. Und nach absoluter Verzweiflung habe ich deinen Eintrag als die Ursache des Problems identifizieren können 😀 😀 😀

    @ David: Nimm das bitte unbedingt mit in die Hilfestellungen auf. Denn hierüber werden mit Sicherheit noch andere Webseitenbetreiber stolpern.

  7. Ein wertvoller Artikel, vielen Dank dafür!

    Über folgende Frage bin ich auch aktuell gestolpert und habe eine mögliche Lösung gefunden:

    Nächste Probleme: indexed_search indiziert, aber zeigt „NO results“ an
    2. Stimmt die search.rootPidList?
    **Warum das nicht funktioniert ist mir bis heute nicht ganz klar. Funktioniert hat hingegen folgende Einstellung:**

    Bei mir war das Problem, dass die Root des Teilseitenbaumes („Als Anfang der Website benutzen“) unterhalb der Einbindung des TypoScripts für die Suche lag. Mit Verschieben des TS und erneuter Indexierung wurden dann auch Ergebnisse angezeigt. Vorher wurde beim Indexieren der Pfad mit „rl0“ in der DB-Tabelle „index_sections“ eine Ebene über dem „Anfang der Website“, die auch der search.rootPidList entsprach, angefangen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.