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 indeksuje treści stron, artykuły news, pobrania (PDF, DOCX, XLSX) i rekordy custom jak produkty czy profile pracowników. Funkcja autocomplete wersji Premium 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 już w darmowej wersji 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ść. Indeksowanie plików i własne indeksery ma już darmowa wersja; wersja Premium dodaje m.in. autocomplete, synonimy, podpowiedzi „Czy chodziło Ci o…?” i Custom Ranking.

Indeksowanie plików wykorzystuje pdftotext i pdfinfo dla PDF-ów oraz catdoc, catppt i xls2csv dla starszych formatów Office; pliki DOCX, PPTX i XLSX ke_search czyta bez dodatkowych narzędzi. 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 korzysta z wyszukiwania pełnotekstowego MySQL lub MariaDB (MATCH … AGAINST) na indeksie FULLTEXT, który ke_search sam zakłada w tabeli tx_kesearch_index. Dodatkowy indeks na istotnych kolumnach nie jest więc potrzebny.

Autocomplete jest realizowany przez endpoint AJAX i podpowiada frazy, których inni odwiedzający już używali i które dawały wyniki. 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 pdftotext 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. ke_search oferuje to od wersji 3.8 już w darmowej wersji, konfigurowane przez Scheduler.

Problem drugi: brakująca instalacja pdftotext. Bez tego narzędzia PDF-y nie trafiają do indeksu, a ke_search odnotowuje to tylko w logu. 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.

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) to nie wystarcza: własne ważenie oferuje wersja Premium z Custom Ranking i Boost Keywords, a wagę tytułu w wersji bazowej ustawia się w konfiguracji rozszerzenia.

Aktualne wersje obsługują TYPO3 v13 i v14, dla v12 jest seria 6.x

ke_search jest pielęgnowane przez dedykowany zespół programistów i jest kompatybilne z każdym wydaniem TYPO3 LTS na czas. Aktualne wersje 7.x ke_search i ke_search Premium obsługują TYPO3 v13 i v14, dla TYPO3 v12 są wersje 6.x. 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 fuzzy matching lub czasy odpowiedzi poniżej sekundy przy dużych ilościach danych, zalecamy przejście na Apache Solr z rozszerzeniem TYPO3-Solr.