Elasticsearch für TYPO3: eigene Datensätze gezielt durchsuchbar
Für Projekte, deren Kern nicht Seiten sind, sondern Produkte, Termine, Standorte oder Publikationen.
Viele TYPO3-Projekte bestehen nicht in erster Linie aus Seiten. Ihr Kern sind eigene Datensätze: Produkte, Veranstaltungen, Standorte, Publikationen, Stellenangebote. Sie liegen in eigenen Tabellen, mit Kategorien, Relationen und mehreren Sprachen.
Für solche Projekte entwickle ich die Suche individuell. Was in den Index kommt, wie er aktuell bleibt und was die Suche im Frontend kann, richtet sich nach Ihren Daten und Ihren Nutzern, nicht nach dem, was eine Standardlösung vorgibt.
Wann Solr die bessere Wahl ist
Nicht jede Suche braucht eine individuelle Entwicklung. Soll die Suche vor allem Seiten und Inhaltselemente finden, empfehle ich Solr mit der Extension EXT:solr. Seiten, Dateien und Standard-Extensions indiziert sie von Haus aus, ein Backend-Modul bringt sie mit.
Dasselbe gilt, wenn viel Logik an Frontend-Logins und Benutzergruppen hängt. Dort ist Solr gelöst und erprobt. Eine eigene Entwicklung lohnt sich, wenn die Datensätze selbst das Produkt sind.
Und nicht jede Filterfrage braucht eine Suchmaschine. Facetten über ein paar tausend Datensätze liefert auch eine GraphQL-Schicht direkt aus der Datenbank. Wo die Grenze liegt, steht unter TYPO3 als GraphQL-Backend (englisch).
Was eigene Datensätze brauchen
Ein Datensatz ist kein Dokument. Ein Produkt hat Kategorien, Varianten, Hersteller und Datenblätter. Eine Veranstaltung hat Ort, Termine und Referenten. Für die Suche führe ich das zu einem Dokument zusammen, bewusst redundant, damit die Abfrage nichts mehr nachschlagen muss.
Facetten brauchen typisierte Felder: Zahl, Datum, Schlüsselwort. Das gerenderte HTML einer Detailseite liefert Volltext, aber keinen Filter „bis 500 Euro“ oder „Termine im März“.
Ändert sich eine Kategorie, betrifft das oft hunderte Einträge. Sie alle müssen neu in den Index, ohne dass jemand daran denken muss.
Im Backend: was in den Index kommt
Welche Felder durchsuchbar sind, welche als Filter dienen und welche nur angezeigt werden, legen wir gemeinsam fest. Ein Treffer im Titel kann mehr zählen als einer in der Beschreibung, ein aktueller Termin mehr als ein vergangener.
Was Redakteure selbst steuern sollen, kommt ins TYPO3-Backend. Möglich sind zum Beispiel:
- Synonyme pflegen, damit „Rad“ auch „Fahrrad“ findet
- Top-Treffer für bestimmte Suchbegriffe festlegen
- den Stand des Index einsehen und einzelne Bereiche neu aufbauen
- Suchbegriffe ohne Treffer auswerten, um Lücken im Inhalt zu finden
Aktuell bleiben
Ein Index ist nur so gut wie seine Aktualität. Änderungen im Backend übernimmt der Index automatisch. Das gilt auch für Daten, die nicht über das Backend kommen, etwa aus Frontend-Formularen oder Importen.
Ändert sich ein verknüpfter Datensatz, werden alle abhängigen Einträge neu eingereiht. Große Importe laufen über eine Warteschlange statt im laufenden Seitenaufruf.
Ändert sich der Aufbau des Index, entsteht der neue Index im Hintergrund, dann wird umgeschaltet. Die Suche bleibt dabei online.
Sprachen und Sichtbarkeit
Jede Sprache bekommt einen eigenen Index mit passender Textanalyse. Für Deutsch gehört die Zerlegung von Komposita dazu, damit ein „Gartenstuhl“ auch bei der Suche nach „Stuhl“ auftaucht.
Versteckte Datensätze sowie Start- und Endzeiten werden beim Indizieren und in der Abfrage berücksichtigt. In den Index kommen nur veröffentlichte Daten, Entwürfe aus Workspaces bleiben draußen.
Im Frontend: was die Suche kann
Im Frontend zeigt sich, ob eine Suche als gut empfunden wird. Je nach Projekt sind möglich:
- Tippfehler-Toleranz: „Veranstalung“ findet trotzdem die Veranstaltung
- Vorschläge beim Tippen und „Meinten Sie …?“ bei leeren Ergebnissen
- Facetten mit Trefferzahlen, die sich bei jeder Auswahl neu berechnen
- Bereichsfilter für Preise, Größen oder Zeiträume
- Umkreissuche für Standorte, sortiert nach Entfernung
- Hervorgehobene Fundstellen im Textauszug
- Sortierung nach Relevanz, Datum oder einem eigenen Feld
Drei Wege, den Index abzufragen
Wie die Suche abgefragt wird, bestimmt Geschwindigkeit und Aufwand. Ich setze drei Wege ein, je nach Projekt.
Über die TYPO3-Seite
Ein Plugin fragt den Index ab, Fluid rendert die Treffer. Der volle TYPO3-Kontext steht zur Verfügung, JavaScript ist nicht nötig. Für Listenseiten mit festen Filtern ist das oft der beste Weg, weil sich die Ergebnisse cachen lassen.
Über eine Middleware als Endpoint
Eine Middleware in TYPO3 nimmt die Suchanfrage an, bevor eine Seite gerendert wird, und liefert JSON. Das Frontend zeigt die Treffer direkt an. Das passt für Vorschläge beim Tippen und für Filter, die sofort reagieren. Sprache und Website-Kontext bleiben verfügbar.
Headless, an TYPO3 vorbei
In Headless-Projekten fragt ein Endpoint in Next.js den Index direkt ab. Pro Anfrage läuft kein PHP mehr. Was nicht sichtbar sein darf, etwa versteckte Datensätze oder abgelaufene Termine, filtert der Endpoint fest heraus.
In dieser Reihenfolge wird die Suche schneller. In allen drei Fällen bleibt die Such-Engine von außen unerreichbar, weil die Anfrage immer über eine Schicht auf dem Server läuft.
Elasticsearch oder OpenSearch
Beide Engines haben dieselbe Herkunft und sprechen weitgehend dieselbe Abfragesprache. Elasticsearch gibt es seit 2024 wieder auch unter einer Open-Source-Lizenz, einzelne Funktionen setzen eine kostenpflichtige Lizenzstufe voraus. OpenSearch steht unter Apache 2.0 bei der Linux Foundation, alle Funktionen sind frei.
Welche Engine passt, hängt vom Hosting und vom Funktionsumfang ab, den das Projekt braucht. Bestandsprojekte auf Elasticsearch 7 sollten das Upgrade einplanen, denn für die 7er-Reihe gibt es keinen Support mehr.
Klingt nach Ihrem Projekt?
Sprechen wir unverbindlich darüber.