ke_search Premium for TYPO3

Enterprise-Suche ohne Solr-Server ist mit ke_search Premium in TYPO3 möglich

Die interne Suche einer Website ist das Feature, das am meisten genutzt und am wenigsten gepflegt wird. Besucher erwarten Autocomplete, Tippfehler-Toleranz und die Fähigkeit, nicht nur Seiten, sondern auch PDFs und Office-Dokumente zu durchsuchen. ke_search Premium liefert genau das für TYPO3, ohne dass ein externer Solr- oder Elasticsearch-Server betrieben werden muss. Alle Daten liegen in der TYPO3-Datenbank, der Index wird über den Scheduler aktualisiert, und die Administration bleibt im TYPO3-Backend.

Für mittelgrosse Websites mit 500 bis 5.000 Seiten und einer Handvoll Datei-Downloads ist ke_search Premium die wirtschaftlichste Suchlösung im TYPO3-Ökosystem. Erst ab 10.000+ indexierten Dokumenten oder bei Sub-Sekunden-Anforderungen an die Antwortzeit wird Solr zur besseren Wahl.

Typical use cases range from Unternehmenswebsites bis zu Wissensportalen

Das Standardszenario ist die Unternehmenswebsite mit Produktkatalog, Magazin, FAQ und Download-Bereich. Besucher suchen nach Produktnamen, Fachbegriffen oder Dokumenten und erwarten Ergebnisse aus allen Bereichen in einer einzigen Trefferliste. ke_search Premium indexiert Seiteninhalte, News-Artikel, Downloads (PDF, DOCX, XLSX) und Custom-Records wie Produkte oder Mitarbeiterprofile. Die Autocomplete-Funktion zeigt bereits beim Tippen Vorschläge an und reduziert die Suchabbruchrate um geschätzte 15 bis 25%.

Zweites Szenario: Wissensportale und Dokumentensammlungen. Hochschulen, Verbände und öffentliche Einrichtungen stellen oft hunderte PDFs zum Download bereit: Forschungsberichte, Satzungen, Formulare, Protokolle. Ohne Datei-Indexierung durchsucht die TYPO3-Suche nur die Seitentexte, nicht den Inhalt der PDFs. ke_search Premium extrahiert den Text aus PDF, DOCX und weiteren Formaten und macht ihn durchsuchbar.

Drittes Szenario: Custom Indexer für Drittsysteme. Unternehmen mit einem PIM, einem DAM oder einem externen Produktkatalog können über die Custom-Indexer-API beliebige Datenquellen in den Suchindex einbinden. Ein Indexer-Job holt Daten per API, transformiert sie in ke_search-Records und speichert sie im Index. Das ist besonders relevant für E-Commerce-Szenarien, in denen Produktdaten nicht in TYPO3 liegen.

Technical architecture uses die TYPO3-Datenbank als Suchindex

ke_search speichert den Index in einer dedizierten Tabelle (tx_kesearch_index) in der TYPO3-Datenbank. Jeder Index-Eintrag enthält Titel, Inhalt, Tags, Typ und Sortierungsinformationen. Die Indexierung läuft über Scheduler-Tasks, die in konfigurierbaren Intervallen (typisch: nächtlich) den Content neu indexieren. Die Premium-Version erweitert den Basis-Indexer um Datei-Indexierung, Autocomplete und Custom Indexer.

Die Datei-Indexierung nutzt Apache Tika oder pdftotext für die Text-Extraktion aus PDFs und catdoc für Office-Dokumente. Diese Tools müssen auf dem Server installiert sein, was auf Shared-Hosting-Umgebungen ein Problem sein kann. Auf dedizierten Servern und in Docker-Containern ist die Installation trivial.

Die Suchanfrage im Frontend arbeitet über eine LIKE-basierte Datenbanksuche mit optionalem Fulltext-Index. Bei kleineren Datenmengen ist die Performance ausreichend, bei grösseren Indexen (5.000+ Einträge) empfiehlt sich ein MySQL-Fulltext-Index auf den relevanten Spalten, um die Suchzeit unter 200ms zu halten.

Autocomplete wird über einen AJAX-Endpoint realisiert, der bei jedem Tastendruck eine PREFIX-Suche auf dem Index durchführt. Die Ergebnisse werden als JSON geliefert und im Frontend per JavaScript als Dropdown angezeigt. Die Konfiguration erlaubt, die Mindest-Zeichenanzahl (empfohlen: 3) und die maximale Anzahl der Vorschläge (empfohlen: 8) einzustellen.

Common problems involve Indexierungszeit, fehlende Tika-Installation und Relevanz-Sortierung

Problem eins: Lange Indexierungszeiten bei grossen Datenmengen. Eine Website mit 3.000 Seiten und 500 PDFs kann 30 bis 60 Minuten für eine vollständige Neuindexierung benötigen. Die Lösung: Inkrementelle Indexierung aktivieren, die nur geänderte Inhalte neu indexiert. Bei ke_search Premium ist das über den Scheduler konfigurierbar.

Problem zwei: Fehlende Tika- oder pdftotext-Installation. Ohne diese Tools schlägt die Datei-Indexierung still fehl, ohne Fehlermeldung. Redakteure laden PDFs hoch, die nie im Suchindex landen. Die Lösung: Nach der Installation einen Test-Indexierungslauf starten und prüfen, ob PDF-Inhalte im Index erscheinen. Ein einfacher CLI-Befehl prüft die Verfügbarkeit: which pdftotext oder java -jar tika-app.jar --version.

Problem drei: Relevanz-Sortierung. Die Standard-Sortierung basiert auf einem einfachen Scoring-Algorithmus, der Treffer in Titeln höher gewichtet als Treffer im Body. Für komplexe Anforderungen (Boosting nach Aktualität, nach Seitentyp oder nach Custom-Feldern) muss das Scoring per TypoScript angepasst werden. Die Premium-Version bietet mehr Scoring-Parameter als die kostenlose Basisversion.

TYPO3 v12 wird vollständig unterstützt, v13-Kompatibilität ist in Arbeit

ke_search wird von einem dedizierten Entwicklerteam gepflegt und ist bei jedem TYPO3-LTS-Release zeitnah kompatibel. Die aktuelle Premium-Version unterstützt TYPO3 v11 und v12. Für v13 ist die Kompatibilität in Entwicklung. Beim Upgrade von älteren TYPO3-Versionen betreffen Breaking Changes vor allem die TypoScript-Konfiguration der Indexer und die Scheduler-Task-Registrierung. Der Suchindex selbst muss nach einem Upgrade komplett neu aufgebaut werden, was je nach Datenmenge eine Stunde oder mehr dauern kann.

Gosign setzt ke_search Premium in TYPO3-Projekten ein, die eine interne Suche brauchen, aber den Betrieb eines Solr-Servers nicht rechtfertigen. Für die meisten mittelgrossen Websites mit unter 5.000 indexierten Dokumenten ist ke_search Premium die wirtschaftlich sinnvollste Lösung. Erst wenn Anforderungen wie Facettierung, Fuzzy-Matching oder Sub-Sekunden-Antwortzeiten bei grossen Datenmengen dazukommen, empfehlen wir den Umstieg auf Apache Solr mit der TYPO3-Solr-Extension.