Webentwicklung

TYPO3 und Solr

14.04.2025

Wenn man beim Aufbau einer TYPO3 Seite eine Suche einbauen möchte, steht man oft vor der Entscheidung: möchte ich indexed_search, die eingebaute Suche, oder solr benutzen?

Solr ist eine Volltext-Suchplatform, die in Java geschrieben ist, und seit 2004 entwickelt wird. Solr basiert auf der Suchmaschinen-Bibliothek Lucene, die noch ein wenig älter ist (1999). Für die Indexierung und Suche nutzt Solr „Cores“ – dies sind Bündel unter anderem aus Schemas, Sprachen, und weiterer Konfiguration. Cores sind sprachspezifisch, da für eine gute Suche (mit Ähnlichkeiten, Vorschlägen) ein gewisses Wissen von Sprache essentiell ist.

Mehrere Webseiten (in einem Auftritt, aber auch in mehreren) können sich durchaus einen dieser Cores teilen. Dies ermöglicht auch, dass man in einem Multisite-Auftritt Site-übergreifende Suchanfragen stellt. Für unseren Kunden AWV – Arbeitsgemeinschaft für wirtschaftliche Verwaltung e. V. haben wir dies für seine drei Unterseiten umgesetzt.

Hosting

Die Extension solr verknüpft ein TYPO3 mit einem Solr-Server. Bei verschiedenen Hosting-Anbietern kann man diesen mieten – ab etwa 10€ / Monat. Die Kosten hängen oft von der gewünschten Menge der Cores und der Menge an Dokumenten im Index ab. Arbeitsspeicher spielt zuweilen auch eine Rolle, mit zu wenig Speicher kommt Solr nicht gut klar. Mit www.hosted-solr.com von dkd haben wir bei kleinen Seiten gute Erfahrungen gemacht. Das Solr-Hosting muss zusätzlich auch die von der TYPO3 Extension benötigten Plugins beinhalten. In der Extension-Dokumentation gibt es eine Matrix der unterstützten Versionen. Tatsächlich haben wir aber auch schon mit nicht unterstützten Kombinationen gute Erfahrungen gemacht.

Konfiguration

Nach der ersten Einrichtung der Verbindung zu Solr-Servern passiert die Konfiguration der Extension in großen Teilen über Typoscript. Mit der Extension Solr ist es möglich, nicht nur Seiteninhalte, sondern auch Datensätze sinnvoll zu indexieren. Dabei mischt die Extension Schema-Daten, die festgelegt sind, mit solchen, die man dynamisch mit Typoscript konfigurieren kann. Wenn weitere Felder indexiert, muss man diese auch durchsuchen (hört sich wie eine Selbstverständlichkeit an). Bestimmte Feldtypen bieten sich dabei besonders für Produktdaten wie Artikelnummern an, da sie nicht wie Sprache interpretiert werden. Eine geeignete Query-Funktion sorgt dann dafür, dass solche Treffer höher priorisiert werden.

Falls man das Bedürfnis nach eigenen Aussehen hat, lässt sich dies über eigene Fluid-Templates bzw. Partials umsetzen. So unterscheidet sich die Darstellung bei unseren Kunden deutlich, selten benutzen wir die Standardtemplates der Solr-Extension. So haben wir z.B. für die Fachagentur Wind und Solar eine eigene Variante des DateRange-Sliders gebaut und die Darstellung der gruppierten Treffer deutlich angepasst.

Sonderfälle

In speziellen Fällen kann es sich auch lohnen, die Extension solr nur im Hintergrund arbeiten zu lassen. Bei unserem Kunden Isotec arbeitet die Jobsuche nach diesem Prinzip: die Anfragen an einen Extbase-Controller werden in Solr-Anfragen umgewandelt, die auch eine effiziente Umkreissuche nutzen können (welche die Extension solr nicht als direktes Beispiel bietet). Auf Partnerseiten lässt sich so auch bequem eine Ergebnisliste ohne offensichtliche Suche umsetzen.

Beispiel: aus Umkreissuche in SQL


foreach ($geoOverallResults as $geoLocationZip) {
  $where[$geoLocationZip['ID']] = '((ACOS((SIN(RADIANS(' . $geoLocationZip['Lat'] . ')) * SIN(RADIANS(zip_latitude))) +
    (COS(RADIANS(' . $geoLocationZip['Lat'] . ')) * COS(RADIANS(zip_latitude)) * COS(RADIANS(zip_longitude) - RADIANS(' . $geoLocationZip['Lng'] . ')))
    ) * 6371
    ) <= ' . $searchRadius . ')';
}
//This cannot be added as an extbase QB constraint, it is added at the end of the function
$distanceQuerySQLWhere = implode(' OR ', $where);

// ….

if ($distanceQuerySQLWhere) {
$extbaseQueryParser = GeneralUtility::makeInstance(Typo3DbQueryParser::class);
$queryBuilder = $extbaseQueryParser->convertQueryToDoctrineQueryBuilder($query);
$queryBuilder->andWhere($distanceQuerySQLWhere);

wird eine Umkreissuche in Solr:

$query->addFilterQuery(['key' => 'geo', 'query' => '{!geofilt sfield=geo_coordinates_location}']);
$query->addParam('pt', round($first['Lat'], 2) . ',' . round($first['Lng'], 2));

// radius
$radius = (int)($filter['radius'] ?? 25);
$query->addParam('d', $radius);

Hintergrund war dieser Migration war unter anderem, dass ein schneller Spatial Index in MySQL nicht immer genutzt werden kann (z.B. bei Aurora-DB).

Vergleich mit EXT:indexed_search

Mit dem Standard-TYPO3 wird eine Such mitgeliefert: EXT:indexed_search. Diese bietet eine einfache Suche. Ein Problem von indexed_search ist die Indexierung: es gibt in den Indexdaten keinen echten Zusammenhang zu Datensätzen, indexed_search (ohne eigenen Indexer) indexiert nur Seiten. Dies muss man realistisch mit der Extension crawler kombiniert werden. Obwohl indexed_search zumindest inzwischen ein Fluid-Template hat, hat sich an der eigentlichen Arbeitsweise seit langem nichts verändert. Inbesondere bei Seiten mit Frontend-Benutzer-Login und mehr als einer Benutzergruppe ist die faktische Notwendigkeit einer Indexierung für jede Gruppenkombination tödlich für die Leistungsfähigkeit der Seite. Da es kein echtes Konzept von Datensatzindexierung gibt, ist es auch nicht einfach möglich Dinge zu indexieren, die keine direkte Darstellung auf der Webseite haben. Ohne ein Schema fehlt in indexed_search auch die Möglichkeit, unterschiedliche Inhalte (z.B. Seiten und Dateien) bei Treffern anders zu gewichten. Dies ist insbesondere dann wichtig, wenn Inhalte sich sehr stark vom Typ unterscheiden (z.B. Dateien und kurze Inhaltsseiten) und deswegen gängige Algorithmen für die Bewertung der Relevanz der Treffer für Kunden oft nicht nachvollziehbare Rankings erzeugen.

Was gibt es sonst noch?

Bei Shopware 6 kann ElasticSearch benutzt werden, was auch auf Lucene basiert, aber von der Technik sehr anders funktioniert. Horizontale Skalierung ist ein Grundgedanke von ElasticSearch. Früher konnte Solr nicht ohne Schema betrieben werden, was bei ElasticSearch der Normalfall ist. Die Extension Solr nutzt Schemas exzessiv. Für die TYPO3-Welt gibt es keine Extension analog zu EXT:solr für ElasticSearch, obwohl unserem hören nach einige Agentur elasticsearch in TYPO3-Projekten benutzen. In der TYPO3-Welt gibt es noch die Extension ke_search, die ebenfalls nicht komplett umsonst ist, aber ohne einen externen Solr-Service betrieben werden kann. Wir nutzen sie nur selten, da sie nicht die Flexibilität von solr bietet.

Dank an DKD

An dieser Stelle sollte unbedingt erwähnt werden, dass die Entwicklung der Extension solr maßgeblich von der Internetagentur dkd getragen wird. Dies geschieht aber in bester Open-Source Kultur bei Github. Bugfixes und Patches werden unserer Erfahrung nach gerne gesehen und werden unserer Erfahrung nach sehr konstruktiv behandelt. Für eine Entwicklungsbeteiligung erhalten Agenturen (oder Kunden) Zugang zu erweiterten Funktionen, z.B. der Extension solr_fal, die eine Indexierung von Dateien erlaubt.