Hübsch, aber…

Auf meiner Suche nach einem Ersatz-CMS wurde mir zweimal Grav empfohlen (hier und hier): Das ist ein CMS, das auf flat files setzt. Und wenn man sich fragt, wie Dateien denn «flach» sein können – und ob sie das nicht immer sind, da die Bits auf dem Datenträger meist ausgelegt und nicht geschichtet werden –, dann gelangt man zu dem Wikipedia-Artikel Flat-file database: Die Daten werden nicht in einer speziellen Datenbank, sondern in normalen Textdateien abgelegt. Flatpress, mein altes CMS, macht das so.

Die Vorteile liegen auf der Hand: Die Anforderungen sind niederschwellig. Man benötigt nicht wie bei WordPress und anderen datenbankgestützten Content-Management-Systemen zusätzliche Software wie MySQL oder dergleichen. Und man die Struktur und die Komplexität unter Kontrolle: Man kann die Sache so simpel wie möglich halten.

Die Vorteile einer «richtigen» Datenbank, die im Jargon auch «relationales Datenbankmanagementsystem», (einigermassen) kurz RDBMS genannt wird, sind hingegen, dass auch mehrere Leute mit den Daten arbeiten können, ohne ihre Eingaben gegenseitig zu überschreiben. Es gibt organisatorisches Drumherum wie Transaktionen und Zugriffsberechtigungen.

Die Datenbank garantiert auch bei grossen Websites Tempo

Und es ist der Anspruch, dass eine Datenbank besser skaliert und auch bei grossen Datenmengen noch eine adäquate Leistung zeigt. Allerdings dürfte es so sein, dass die Datenbank erst ab einer gewissen Datenmenge die Performance-Vorteile ausspielt. Bei wenigen Daten ist mutmasslich flat file im Vorteil – auch wenn es schwierig ist abzuschätzen, wo die Trennlinie verläuft.

Bei Flatpress, so wie ich das System genutzt habe, war die Schwelle in einigen Aspekten erreicht: Die eingebaute Suche war annähernd nutzlos, weil viel zu langsam. Auch Auswertungen oder Änderungen über alle Beiträge hinweg waren umständlich. Im Vergleich dazu ist es bei WordPress simpel, eine Suche oder einen Suchen-Ersetzen-Vorgang über die passende Tabellenspalte laufen zu lassen. Das geht auch bei mehr als zweitausend Beiträgen und Millionen von Zeichen blitzschnell. Ich denke daher, dass die Datenbank für meine Bedürfnisse zwar nicht zwingend, aber auch kein völlig übertriebener Overhead ist.

Grav hat eine Ordnerstruktur, die sich einem sofort erschliesst. Unter userpages stecken die Beiträge, und zwar in nummerierten Ordner (01.home, 02.typography sind die Beispiele der Standard-Installation). Darin hat es Dateien wie default.md, die aus normalen Textdateien bestehen und mit Markdown-Inhalten bestückt werden. Wie hier gesagt, bin ich ein Fan von Markdown. Man kann auch HTML verwenden, wenn man möchte.

Modern und ausführlich dokumentiert

An Grav überzeugt die ausführliche Dokumentation und die moderne Anmutung. Es ist Open-Source. Es gibt schöne Themes, mehrere Dutzend Plugins, einen Paketmanager und vielseitige Unterstützung für mehrsprachige Sites und Mediadateien.

Das klingt alles toll, doch nach etwas Spielen mit diesem CMS würde ich es für ein Blog nicht nutzen, und zwar aus folgenden Gründen:

• Nach meinen Erfahrungen mit Flatpress bin ich ein gebranntes Kind, was Content-Management-Systeme angeht, die noch nicht einmal ihre eigene Wikipedia-Seite haben. Eine breite Unterstützung hat Vorteile – auch wenn man so nicht unbedingt zu den Pionieren gehört.
• Grav ist ein universelles CMS, mehr auf Firmen-Homepages und thematisch strukturierte Websites ausgelegt – und nicht speziell aufs Bloggen. Man kann es fürs Bloggen verwenden und hier gibt es ein wirklich hübsches Beispiel. Auch die eindrückliche Site Sequence Break hat eine chronologische Struktur. Aber ich sehe überall nur ein paar wenige Einträge. Ich zweifle, dass dieses CMS bei meinen mehr als 2000 Beiträge sonderlich praktisch wäre, wo es in der Beschreibung zur Blog-Erstellung heisst: «Create a page of type Blog. That page is the blog Homepage, with the blog posts list. Create one or more child pages of type Item. Those are the blog posts.»
• Der Umgang mit den Seiten – siehe hier – ist mir zu umständlich.
• Stichwort Migration: Man bekäme die alte Flatpress-Dateistruktur irgendwie in die Ablage von Grav hinein und natürlich liesse sich BBCode auch nach Markdown oder, vermutlich einfacher, HTML konvertieren. Doch was ist mit den Kommentaren? Es braucht dafür anscheinend ein separates Plugin. Und das deutet darauf hin, dass Kommentare eher eine Nebensache sind. Und das lässt für die Datenübernahme nichts Gutes erahnen.
• Grav ist offensichtlich auf Flexibilität ausgelegt und auf Nutzer zugeschnitten, die wissen, was sie tun. Doch der Ansatz ist, wenn man von klassischen Blog-Systemen kommt, ungewohnt. Es gibt eine anfänglich steile Lernkurve. Das ist okay, wenn man eine neue Site aufzieht und Zeit fürs Einrichten mitbringt. Wenn man quasi im fliegenden Wechsel eine bestehende Website ummodeln will, ist das nicht unbedingt erwünscht.
• Es gibt ein AdSense-Plugin, aber das wird nicht mehr gepflegt. Wenn ich weiterhin Werbung schalten wollen würde, müsste ich das von Hand einbauen, so wie das auch bei Flatpress nötig war. Aber darauf habe ich wirklich keine Lust.

Meine Visitenkarten-Website läuft jetzt mit Grav

Fazit: Ich werde mit Grav gerne noch etwas weiterspielen. Es gibt Webangebote, für die es gut passen würde; zum Beispiel für dorfposcht.ch, falls ich dort mit meinem selbstgestrickten CMS namens Page Butler einmal nicht mehr zufrieden sein sollte. Ich kann es mir auch sehr gut für meine Ego-Page vorstellen. Es ist sogar so, dass Grav unter matthiasschuessler.ch/grav installiert ist – aus reiner Lust an der Freude.

Nachtrag: Ich habe nun meine persönliche Website unter matthiasschuessler.ch auf einen hübschen Onepager umgestellt. Dafür funktioniert Grav ganz gut. Meine Erfahrungen sind ausführlich hier nachzulesen.

Doch meine Blog-Bedürfnisse befriedigt das CMS zu wenig: Ich möchte schnell und flexibel bloggen: Beiträge auf Halde produzieren, einfach umdatieren und das Blog auch als Halde für Ideen und Themen verwenden. Da nützt mir eine iPad-App wie die von WordPress mehr als die zugegeben sehr recht nerdige Herangehensweise von Grav.