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. Und es ist der Anspruch, dass eine Datenbank besser skaliert und auch bei grossen Datenmengen noch eine gute 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.

Hier ist es mir fast ein bisschen zu aufgeräumt.

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.

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.

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.

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.

Autor: Matthias

Diese Website gibt es seit 1999. Gebloggt wird hier seit 2007.

2 Gedanken zu „Hübsch, aber…“

  1. Danke für den Testbericht! Erspart mir immer Zeit, wenn ich die Sachen nicht selbst ausprobieren muss. 🙂

    Zum Thema Dateien vs. Datenbank: Dateien sind schneller als Datenbanken, wenn es um nicht-relationale Daten geht. Wenn man pro Blogbeitrag eine Datei hat, ist es sehr schnell, die Datei xy.txt zu öffnen und anzuzeigen. Beim zweiten Aufruf ist die Datei dann sogar im Filesystem-Cache und es geht noch schneller.

    Langsamer (bei vielen Daten extrem viel langsamer) ist man aber bei relationalen Daten: alle Beiträge zu einer Kategorie anzuzeigen zum Beispiel. Denn entweder trägt man die Kategorie in der Datei jedes Beitrags ein und führt eine Liste, welche Beiträge zu welcher Kategorie gehören, oder man muss alle Beitrags-Dateien einlesen für die Suche.

    Es gibt deshalb immer weniger Szenarien, in denen man ohne Datenbank besser bedient ist. Es muss aber nicht immer gleich ein Datenbank-Server wie MySQL sein. Mit SQLite hat man zum Beispiel viele Vorteile einer Datenbank, ohne dass ein Dienst laufen muss. Skaliert aber nicht bei gleichzeitigen (Schreib-)Zugriffen.

  2. Ein interessanter Artikel. Ich selbst stand vor kurzem vor der Entscheidung zwischen Grav, Bludit und WordPress. Letztlich ist es bei mir Bludit geworden, weil es mir am meisten zugesagt hat. In der Praxis vermisse ich in allen Flat-File-Systemen aber gewohnte & geliebte Funktionen aus WordPress, wie zum Beispiel das Tool für interne Verlinkungen. Es ist sehr mühsam, erst händisch die zu verlinkende Seite heraussuchen zu müssen und dann einzufügen. Ein weiterer Nachteil an Bludit (ich weiß nicht ob das für die anderen Flat File CMS auch gilt) ist der, dass sich beim Ändern des Artikel-Titels auch automatisch die URL ändert – sicherlich kann man das mit etwas Coding ändern, aber irgendwie sehne ich mich dann doch nach der Bequemlichkeit von WordPress. Ich denke ich werde früher oder später wieder zu WordPress zurückkehren. Denn wie du bereits angemerkt hast, liegt der Vorteil dieser Systeme eher in OnePage-Seiten oder Firmenhomepages, die nicht unbedingt auf einen großen Artikelfundus zurückgreifen.

Kommentar verfassen