ke_search Premium dla TYPO3

Wyszukiwanie enterprise bez serwera Solr jest możliwe w TYPO3 dzięki ke_search Premium

Wewnętrzna wyszukiwarka strony to funkcja używana najczęściej i najmniej pielęgnowana. Odwiedzający oczekują autocomplete, tolerancji błędów literowych i zdolności przeszukiwania nie tylko stron, ale też PDF-ów i dokumentów Office. ke_search Premium dostarcza dokładnie to dla TYPO3, bez konieczności prowadzenia zewnętrznego serwera Solr lub Elasticsearch. Wszystkie dane leżą w bazie danych TYPO3, indeks jest aktualizowany przez Scheduler, a administracja pozostaje w backendzie TYPO3.

Dla stron średniej wielkości z 500 do 5.000 podstron i garścią pobrań plików ke_search Premium to najbardziej ekonomiczne rozwiązanie wyszukiwania w ekosystemie TYPO3. Dopiero od 10.000+ zaindeksowanych dokumentów lub przy wymaganiach czasu odpowiedzi poniżej sekundy Solr staje się lepszym wyborem.

Typowe scenariusze zastosowań sięgają od stron firmowych do portali wiedzy

Standardowy scenariusz to firmowa strona z katalogiem produktów, magazynem, FAQ i obszarem pobrań. Odwiedzający szukają nazw produktów, terminów fachowych lub dokumentów i oczekują wyników ze wszystkich obszarów w jednej liście trafień. ke_search Premium indeksuje treści stron, artykuły news, pobrania (PDF, DOCX, XLSX) i rekordy custom jak produkty czy profile pracowników. Funkcja autocomplete pokazuje sugestie już podczas pisania i redukuje współczynnik porzucenia wyszukiwania o szacunkowo 15 do 25%.

Drugi scenariusz: portale wiedzy i zbiory dokumentów. Uczelnie, stowarzyszenia i instytucje publiczne często udostępniają setki PDF-ów do pobrania: raporty badawcze, statuty, formularze, protokoły. Bez indeksowania plików wyszukiwarka TYPO3 przeszukuje tylko teksty stron, a nie zawartość PDF-ów. ke_search Premium wyciąga tekst z PDF, DOCX i innych formatów i czyni go przeszukiwalnym.

Trzeci scenariusz: Custom Indexer dla systemów zewnętrznych. Firmy z PIM, DAM lub zewnętrznym katalogiem produktów mogą przez API Custom Indexer włączyć dowolne źródła danych do indeksu wyszukiwania. Zadanie indeksera pobiera dane przez API, przekształca je w rekordy ke_search i zapisuje w indeksie. Jest to szczególnie istotne dla scenariuszy e-commerce, gdzie dane produktów nie leżą w TYPO3.

Architektura techniczna wykorzystuje bazę danych TYPO3 jako indeks wyszukiwania

ke_search zapisuje indeks w dedykowanej tabeli (tx_kesearch_index) w bazie danych TYPO3. Każdy wpis indeksu zawiera tytuł, treść, tagi, typ i informacje sortowania. Indeksowanie działa przez zadania Scheduler, które w konfigurowalnych interwałach (typowo: nocnie) na nowo indeksują treść. Wersja Premium rozszerza bazowy indekser o indeksowanie plików, autocomplete i Custom Indexer.

Indeksowanie plików wykorzystuje Apache Tika lub pdftotext do wyciągania tekstu z PDF-ów i catdoc dla dokumentów Office. Te narzędzia muszą być zainstalowane na serwerze, co w środowiskach shared hosting może stanowić problem. Na serwerach dedykowanych i w kontenerach Docker instalacja jest trywialna.

Zapytanie wyszukiwania w frontendzie pracuje przez wyszukiwanie w bazie danych oparte na LIKE z opcjonalnym indeksem fulltext. Przy mniejszych ilościach danych wydajność jest wystarczająca, przy większych indeksach (5.000+ wpisów) zalecany jest indeks fulltext MySQL na istotnych kolumnach, aby utrzymać czas wyszukiwania poniżej 200 ms.

Autocomplete jest realizowany przez endpoint AJAX, który przy każdym naciśnięciu klawisza wykonuje wyszukiwanie PREFIX na indeksie. Wyniki są dostarczane jako JSON i wyświetlane w frontendzie przez JavaScript jako dropdown. Konfiguracja pozwala ustawić minimalną liczbę znaków (zalecane: 3) i maksymalną liczbę sugestii (zalecane: 8).

Częste problemy dotyczą czasu indeksowania, brakującej instalacji Tika i sortowania relewancji

Problem pierwszy: długie czasy indeksowania przy dużych ilościach danych. Strona z 3.000 podstron i 500 PDF-ami może potrzebować 30 do 60 minut na pełne ponowne zaindeksowanie. Rozwiązanie: aktywować indeksowanie inkrementalne, które na nowo indeksuje tylko zmienione treści. W ke_search Premium jest to konfigurowane przez Scheduler.

Problem drugi: brakująca instalacja Tika lub pdftotext. Bez tych narzędzi indeksowanie plików cicho zawodzi, bez komunikatu o błędzie. Redaktorzy wgrywają PDF-y, które nigdy nie trafiają do indeksu wyszukiwania. Rozwiązanie: po instalacji uruchomić testowy przebieg indeksowania i sprawdzić, czy treści PDF pojawiają się w indeksie. Proste polecenie CLI sprawdza dostępność: which pdftotext lub java -jar tika-app.jar --version.

Problem trzeci: sortowanie relewancji. Standardowe sortowanie opiera się na prostym algorytmie scoringu, który waży trafienia w tytułach wyżej niż trafienia w treści. Dla złożonych wymagań (boosting według aktualności, według typu strony lub według pól custom) scoring musi być dostosowany przez TypoScript. Wersja Premium oferuje więcej parametrów scoringu niż darmowa wersja bazowa.

TYPO3 v12 jest w pełni wspierane, kompatybilność z v13 jest w pracy

ke_search jest pielęgnowane przez dedykowany zespół programistów i jest kompatybilne z każdym wydaniem TYPO3 LTS na czas. Aktualna wersja Premium obsługuje TYPO3 v11 i v12. Dla v13 kompatybilność jest w trakcie rozwoju. Przy upgrade ze starszych wersji TYPO3 breaking changes dotyczą głównie konfiguracji TypoScript indekserów i rejestracji zadań Scheduler. Sam indeks wyszukiwania musi być kompletnie odbudowany po upgrade, co w zależności od ilości danych może trwać godzinę lub więcej.

Gosign wdraża ke_search Premium w projektach TYPO3, które potrzebują wewnętrznego wyszukiwania, ale nie uzasadniają prowadzenia serwera Solr. Dla większości stron średniej wielkości z poniżej 5.000 zaindeksowanych dokumentów ke_search Premium to najbardziej ekonomicznie sensowne rozwiązanie. Dopiero gdy dochodzą wymagania takie jak facettowanie, fuzzy matching lub czasy odpowiedzi poniżej sekundy przy dużych ilościach danych, zalecamy przejście na Apache Solr z rozszerzeniem TYPO3-Solr.