solrfal für TYPO3: Datei-Indexierung mit Apache Solr

Warum TYPO3-Standardsuche bei großen Dokumentbeständen kapituliert

Sobald eine TYPO3-Installation mehr als ein paar hundert PDF-Dokumente verwaltet, scheitert die eingebaute Suche an zwei Grenzen: Sie findet nur Inhalte in Datenbank-Feldern, nicht in Dateien, und ihre Ranking-Logik ignoriert die Relevanz-Signale, die Redakteure brauchen. solrfal schließt genau diese Lücke, indem es den File Abstraction Layer (FAL) von TYPO3 direkt an Apache Solr koppelt und jede Datei inklusive ihrer Metadaten durchsuchbar macht. Die Extension richtet sich an Organisationen, die Dokumente als Kern ihrer Wissensarbeit betrachten: Behörden mit Formularen, Verlage mit Fachliteratur, Hochschulen mit Lehrmaterial.

Typische Einsatzszenarien

In einer technischen Hochschule mit rund 40.000 Studierenden liegt die Studienordnung in 180 PDF-Dateien vor, verteilt über zwölf Fakultäten. Ohne solrfal findet ein Studierender den Passus zur Prüfungsanmeldung nur, wenn ein Redakteur den Text zusätzlich als Meta-Beschreibung hinterlegt hat. Mit solrfal indexiert Apache Tika jede Seite, und die Suchanfrage liefert den richtigen Absatz samt Zitat.

Ein zweites Szenario kennen Bundesbehörden, die Gesetzestexte, Richtlinien und Formulare über ein TYPO3-CMS ausliefern. Die Dokumente ändern sich häufig, und Zugriffsrechte sind an Organisationseinheiten geknüpft. solrfal synchronisiert die fe_groups-Zugehörigkeit der Dateien automatisch in den Solr-Index, sodass ein Mitarbeiter aus dem Referat V nur Treffer sieht, für die er Leseberechtigung besitzt.

Der dritte Fall tritt bei Fachverlagen auf: Ein Verlag mit 12.000 Zeitschriftenartikeln als PDF möchte den Archivbestand über eine Facettensuche nach Jahrgang, Autor und Rubrik durchsuchbar machen. solrfal extrahiert die Metadaten, befüllt die Solr-Felder und liefert die Datenbasis für eine Facette, die klassische TYPO3-Extensions wie ke_search in dieser Größenordnung nicht mehr bedienen können.

Technische Architektur unter Apache Tika und EXT:solr

solrfal ist eine Erweiterung der Kern-Extension EXT:solr von dkd Internet Service und setzt zwingend einen laufenden Apache Solr Server voraus, typischerweise in Version 8 oder 9. Die eigentliche Textextraktion übernimmt Apache Tika, entweder als eingebetteter Service im Solr-Container oder als eigenständiger Tika-Server. solrfal klinkt sich über die TYPO3-Event-API in den FAL-Lebenszyklus ein: Jede hochgeladene, verschobene oder gelöschte Datei löst einen Indexierungs-Job aus, der asynchron im TYPO3-Scheduler abgearbeitet wird.

Konfiguriert wird solrfal über TypoScript und die Extension-Konfiguration. Das Solr-Schema lässt sich per Managed Schema API anpassen, sodass zusätzliche Felder wie Dokumenttyp, Abteilung oder Sprache ohne Solr-Restart hinzugefügt werden können. Relevanz-Tuning erfolgt über Boosting-Queries und Function Queries, die in der Query-Konfiguration der EXT:solr definiert werden. solrfal erbt dabei alle Sprach-Features der EXT:solr, inklusive der mehrsprachigen Analyzer für Deutsch, Englisch, Französisch und weitere Standardsprachen.

Häufige Probleme und Lösungen

Das erste Problem taucht meist beim Erstindex auf: Apache Tika bricht bei kaputten oder verschlüsselten PDFs mit einem OutOfMemoryError ab und reißt den gesamten Indexer mit. Die Extension markiert die Datei dann als fehlerhaft und überspringt sie beim nächsten Lauf nicht automatisch. Wir analysieren die Tika-Logs, trennen die verschlüsselten von den wirklich defekten Dateien und richten einen Pre-Check ein, der problematische Dateien aussortiert, bevor sie den Indexer erreichen.

Das zweite wiederkehrende Thema ist Relevanz. Teams berichten, dass die Suche zwar alle Dokumente findet, aber irrelevante Treffer ganz oben stehen. Der Grund liegt fast immer in der Default-Feldgewichtung: solrfal indexiert den gesamten Dateiinhalt in ein einziges Feld, ohne zwischen Titel, Überschriften und Fließtext zu unterscheiden. Eine saubere Lösung erfordert ein angepasstes Schema mit getrennten Feldern für Titel, Metadaten und Body sowie Boosting-Regeln, die Titeltreffer höher gewichten.

Das dritte Problem betrifft Performance bei großen Beständen. Ab etwa 50.000 indexierten Dateien wird der Scheduler zum Flaschenhals, weil solrfal jeden Job einzeln verarbeitet. Die Lösung ist Batch-Indexierung in Kombination mit einem dedizierten Worker-Prozess, der parallel zu den normalen Scheduler-Tasks läuft und solrfal-Jobs priorisiert abarbeitet. Zusätzlich lohnt sich eine differenzielle Indexierung, die bei jedem Durchlauf nur neue oder geänderte Dateien neu verarbeitet, was den Wartungs-Aufwand bei stabilen Dokumentbeständen deutlich reduziert.

Ein viertes, selteneres Thema tritt bei mehrsprachigen Installationen auf: solrfal indexiert Dateien sprachunabhängig in einen gemeinsamen Index, sodass eine französische Studie in der deutschen Trefferliste auftaucht, wenn das Suchwort international verbreitet ist. Eine saubere Sprach-Trennung erfordert mehrere Solr-Cores oder eine zusätzliche Sprach-Facette, die sich über die EXT:solr-Konfiguration pro Site-Root separat steuern lässt.

Migration und Versions-Kompatibilität

solrfal folgt dem Release-Zyklus der EXT:solr, die aktuell TYPO3 v12 und v13 unterstützt. Der Sprung von TYPO3 v9 auf v12 ist der häufigste Migrationspfad und bedeutet fast immer auch einen Sprung von Solr 6 auf Solr 9. Dabei ändern sich das Schema-Format, die Managed-Schema-API und einige Analyzer-Klassen, was einen vollständigen Reindex erforderlich macht. Bestehende Boosting-Regeln müssen gegen das neue Query-Parser-Verhalten validiert werden, da Solr 9 bestimmte Default-Operatoren anders auswertet als Solr 6.

Wer von ke_search oder einer rein datenbankgestützten Suche migriert, muss berücksichtigen, dass solrfal einen eigenen Solr-Server voraussetzt und damit Hosting-Anforderungen erweitert. Gosign begleitet diese Migrationen seit Jahren und übernimmt bei Bedarf auch den Wechsel auf ein containerbasiertes Solr-Setup, das sich in bestehende Deployment-Pipelines einfügt.

Zu beachten ist außerdem, dass die Wartungslast von solrfal nicht zu unterschätzen ist: Solr selbst erhält regelmäßige Security-Updates, und das Schema muss bei jedem größeren Upgrade gegen neue Analyzer-Klassen geprüft werden. Ein Projekt, das sich einmal für solrfal entscheidet, übernimmt damit die Verantwortung für einen eigenen Search-Stack und sollte das beim initialen Sizing und bei der Planung der Betriebsressourcen einkalkulieren.