Auf Mastodon ansehen
Bald wird GNU/Linux.ch fünf Jahre alt. In dieser Zeit wurden viele Artikel geschrieben und Podcast-Folgen aufgenommen. Damit bieten wir eine der grössten Informationsquellen über Freie Software und Freie Gesellschaft im deutschsprachigen Raum. Das Besondere daran ist, dass die Inhalte nicht von einer abhängigen und kommerziellen Redaktion stammen, sondern von euch, der Community. Darauf sind wir stolz.
Eine Informationsquelle steht und fällt mit der Auffindbarkeit der Inhalte. Niemand scrollt durch über 4000 Artikel, um das Gewünschte zu finden. Es gibt die Kategorien, mit denen man ein Themengebiet eingrenzen kann. In manchen Fällen ist das hilfreich; z. B. wenn man die Liste aller Podcast-Folgen sehen möchte oder nur an den Beiträgen über Spiele interessiert ist. Doch was wirklich zählt und häufig genutzt wird, ist die Suchfunktion.
Bisher haben wir für die Suche ein modifiziertes Bludit-Plugin verwendet:
Die alte Suchfunktion liefert sechs Spalten (Titel, Kurzbeschreibung, Datum, Ersteller, Kategorie und Tags), wobei die Spaltentitel unvollständig sind, wie wir heute bemerkt haben (die Kurzbeschreibung fehlt). Die Suche legt los, sobald man mit dem Eintippen des Suchbegriffs beginnt. Das ist nett, aber ziemlich sinnfrei. Ausserdem verlangsamt es die Suche sehr.
Die neue Suchfunktion ist gefühlt zehnmal schneller als die alte. Sie reduziert die Spalten und verschwendet keine Zeit mit der "Suche während der Eingabe". Zudem sind die Ergebnisse paginiert, also auf Seiten aufgeteilt. Vorher wurden unter Umständen 1000 Suchergebnisse auf einer Seite angezeigt.
Tim hat die Suche von Grund auf neu geschrieben und an die Bedürfnisse der Community angepasst. Zum Zeitpunkt des Erscheinens dieses Artikels liegt die neue Suche in einer ersten Version vor. Es können sich noch weitere Verbesserungen ergeben.
Der technische Hintergrund
Die bisherige Suche basierte auf dem Bludit Plugin "sitemap-table-generator" von MrReSc. Dabei wird eine Liste aller Beiträge erstellt und mithilfe von list.js sortierbar und durchsuchbar gemacht. Technisch wird dem Browser also eine riesige HTML-Tabelle zur Verfügung gestellt, die dann im zweiten Schritt durch Javascript vom Browser selbst gefiltert wird.
Die neue Suche basiert auf einem eigenen Bludit Plugin. Da Bludit ein Flat-File CMS ist und mit JSON-Dateien auf dem Server als "Datenbanken" arbeitet, nutzt unser Plugin auch diese Funktionalität. Bei jeder Änderung wird ein Suchindex in eine JSON-Datei geschrieben. Stellt die Nutzer:in nun eine Suchanfrage, so wird diese an den Server übermittelt und das bereits gefilterte Ergebnis (ebenfalls im JSON-Format) an den Browser zurückgesendet. Das Javascript im Browser (in diesem Fall datatables) muss dann nur noch diese deutlich geringere Datenmenge in eine hübsche HTML-Tabelle schreiben und übernimmt weiterhin die Sortierung.
Das Plugin sucht in den Feldern Titel, Kurzbeschreibung, Autor und Tags. Die Logik vergibt Relevanzpunkte, je öfter der/die Suchbegriffe vorkommen, desto mehr Punkte gibt es. Füllwörter werden von der Suche ignoriert. Außerdem zählt ein Vorkommen im Titel mehr als in den anderen Feldern. Ist die Relevanz identisch, dann wird nach Datum sortiert. Die Sortierung kann nachträglich durch einen Klick auf die Spaltenüberschriften geändert werden.
Unser Plugin trägt den kreativen Namen "table-search" und steht unter der MIT-Lizenz zur Verfügung.
Das Rad neu erfinden?
Suchlösungen gibt es bereits einige, wir haben trotzdem Gründe, warum wir eine eigene implementiert haben. Um von unseren Spenden nicht unnötig Geld auszugeben, verwenden wir ein relativ günstiges Shared-Hosting. Das reicht für uns aus, begrenzt uns aber auch in den technischen Möglichkeiten. Bestehende Lösungen bestehen in der Regel aus komplexer Software und/oder Datenbanken, die wir nicht betreiben wollen und können.
Die neue Suche performt (auf unserem Shared-Hosting) aus unserer Sicht ganz gut. Bei jeder Seitenänderung wird der Suchindex mit aktuell ca. 26.500 Suchbegriffen in rund 400 ms neu erstellt und auf die Platte geschrieben. Ein Suchergebnis für ein Wort wird in rund 10 ms nach Relevanz sortiert ausgeliefert, bei 4 Suchbegriffen sind es etwa 20 ms.
Fazit
Mit der neuen Suche wird es einfacher und angenehmer, den gewünschten Inhalt zu finden. Die Suchergebnisse werden übersichtlich dargestellt und sind nach Relevanz sortiert. Doch das Wichtigste ist die enorme Geschwindigkeit der Suche.
Titelbild: https://pixabay.com/photos/search-finger-index-google-6819839/
Wenn es gelöst ist ist gut, aber falls das Thema doch nochmal aufkommt: Datenbanken sind kein Hexenwerk und auch mit jedem Shared-Hosting (das ich kenne) kompatibel. So eine Suche kann man wunderbar einfach mit SQLite umsetzen, und sicher auch mit PostgreSQL oder MariaDB, falls der Hoster nur das anbietet. Schlagwort ist dann "Full Text Search", bei SQLite als Beispiel https://sqlite.org/fts5.html
Danke für den Hinweis :) wenn unser CMS eh in einer Datenbank speichern würde, hätten wir das bestimmt auch bevorzugt. So müssten wir erstmal die Inhalte synchron halten und das Frontend zur Suche trotzdem noch bauen. Was im Artikel gemeint war, sind Lösungen wie ElasticSearch, da wird es schnell eng beim Hosting.
Schön, das die Suche die Lioh und ich vor 5 Jahren zusammen gehackt haben bis heute lief 😁.