Bei ca. 90.000 Seiten, verteilt in fast 300 Domains, ist es hilfeich eine (gute) eigene Suche zu haben.

Für TYPO3 hat sich ext:solr als robuste Lösung für die Hochschulen im Land Meckelnburg-Vorpommern durchgesetzt. Die enge Integration in das Content-Management-System und die Solr-seitigen Anpassungen, die die Erweiterung mit sich bringt, sind ideal.

Neben schnöden Seiten werden Nachrichten, Veranstaltungen, Studiengänge, Mediatheksbeiträge, Fortbildungskurse, Stellenausschreibungen und, und, und automatisch im großen Solr-Index gepflegt. Die Eigenständigkeit der jeweiligen Hochschule wird durch dedizierte Solr-Cores gewährleistet.

Hürden bei der Indexierung

Die ext:solr Überwacht durch verschiedene Hooks/EventListener Änderungen an den Inhalten. Sei es das Hinzufügen, Verschieben oder Löschen von Datensätzen (oder Seiten) - alle Aktionen können zu einer Aktualisierung des Solr-Indexes führen.

Durch die große Aktivität von tausenden Redakteur*innen im Backend werden diese Aktualisierungen nicht sofort ausgeführt. Ereignisse werden gesammelt und anschließend gestaffelt abgearbeitet. So kann es einige Minuten dauern, bis eine Änderung auch in der Suche erscheint.

Um die Last der Indexierung zu verringern wird der Monitoring-Typ "Delayed (Scheduler task)" verwendet. Die Änderungsereignisse werden datenbankseitig in der Tabelle tx_solr_eventqueue_item gespeichert und durch einen Task ("Event Queue Worker") in die eigentliche Indexierungswarteschlange übergeben. Bei größeren Änderungen an den Inhalten können schnell mehrere zehntausend Änderungseinträge zustande kommen. Daher ist es wichtig einen geeigneten Wert für die Abarbeitungsgröße des Event Queue Workes zu finden: 5.000 Events passt bei der zuvorgenannten Größenordnung sehr gut. Der Task wird alle 10 Minuten ausgeführt und läuft nicht länger als eine Minute.

Damit befinden sich die zu indexierenden Einträge also in der eigentlichen Warteschlange (Tabelle tx_solr_indexqueue_item). Für jede Domain läuft nun in regelmäßigen Abständen ein Task, der den Solr-Index aktualisiert.

Allgemeine Datensätze werden dabei direkt indexiert. Seiten jedoch gelangen erst durch ein Crawling in den Index.

Crawling

Durch einen cURL-Aufruf des TYPO3-Server selbst werden die Seiten abgefragt und sämtlicher Inhalt zwischen <!--TYPO3SEARCH_begin--> und <!--TYPO3SEARCH_end--> aus dem HTML-Quellcode als Inhalt an den Solr-Index übergeben. Wenn das Template einer Seite komplizierte Menübäume und anderen Zauber benötigt, kann ein Crawling-Durchgang mehrere Minuten Dauern. Dadurch kann es zu Konflikten mit anderen Prozessen kommen. Außerdem ist es nicht gut, wenn einfache Dinge so lange dauern. Daher wird ein reduziertes Template verwendet, wenn die Seiten für die Suchmaschine aufgerufen werden; es wird dann nur der Inhalt der Seite ausgegeben.

Per TypoScript wird beim Crawl ein HTTP-Header gesetzt: plugin.tx_solr.index.queue.pages.indexer.frontendDataHelper.headers.crawler = suchmaschine:1. Dokumentiert ist dies in der ext:solr nicht - aber das Skript einsehbar: PageIndexer. An geeigneter Stelle wird dieser HTTP-Header (suchmaschine: 1) dann abgefragt, um das Template der Seite auszutauschen.

Das Crawling ist damit durchschnittlich doppelt so schnell und die Seiten ruck zuck indexiert.

Natürlich könnte in der Template-Bedingung auch nach dem TYPO3-UserAgent geschaut werden. Dieser wird jedoch auch beim Aufruf von Fehlerseiten gesetzt und kennzeichnet den Crawler leider nicht eindeutig.