Der Kreis schließt sich

oder Enttäuschung schwingt mit.

Als ich 1994 mit ersten HTML Seiten experimentierte war es schon recht toll überhaupt einen Webserver, oder eine Webseite zu haben. HTML, Frames, Tabellen und Gifs oder JPGs waren die Mittel der Wahl und ein Wysiwyg-Editor war schon ein gewisser Luxus.

So ab 2000 waren dynamische Seiten in, oft weniger weil sie besser waren, sondern weil sie halt auf asp oder php basierten und irgendwie cooler waren. Parallel dazu entwickelten sich Content Management Systeme, die dem Webautor das mühselige setzen der Seiten erleichtern sollten.

2004 stieß ich auf die Software Mambo CMS (und auf diverse andere geniale Systeme, von denen ich aber die meisten wieder vergessen habe) und kurz darauf auf dessen Nachfolger (ForkFork ein Fork ist in der OpenSource Welt eine Abspaltung, bei dem zu einem Zeitpunkt der Code der Software übernommen und als eigenes Projekt weitergeführt wird) Joomla und auch auf WordPress.

Mit Joomla realisierte ich viele Projekte, während mich zwar das damals kleine, schlanke und schnelle WordPress faszinierte, ich aber keine passenden Einsatzzweck dafür hatte.

Wieder etwas später, WordPress war mittlerweile keine kleine schlanke Blogsoftware mehr sondern ein ausgewachsenes CMS, begann ich meine Webseite damit zu betreiben. Aktuell ist das immer noch die Basis dieser Webseite.

Joomla und WordPress (auch verschiedenen anderen Tools wie Drupal, HumHub, uvm., welche ich getestet oder eingesetzt habe, die mir aber den Aufwand einer Migration meiner Webseite nicht wert waren) haben einige Dinge gemeinsam. Da wäre der recht aufgeblähte Unterbau inklusive Benutzerverwaltung, Pluginverwaltung und zahllosen Features, von denen ich nur sehr wenige benötige. Auch die serverseitige Scriptsprache PHP ist ihnen gemein, mit denen das Backend, die Datenbank und die eigentliche Webseite betrieben bzw. ausgegeben werden. Und natürlich eine Datenbank, in der nicht nur der Inhalt der Webseiten, sondern wirklich, wirklich viele Dinge in Tabellen abgelegt werden.

Das mag bei umfangreichen und hochfrequentierten Webseiten Vorteile haben, bei meinen kleinen Webprojekten hat es in der Regel einen großen Nachteil: Es macht die Webseite träge – ja vergleichsweise langsam. Also wird mit Präprozessoren und In Memory-Caching versucht die dynamische Webseite zu überlisten und eine Mischung aus vorausschauend aufbereitendem Content als statische Variante aus dem Cache geliefert. So wird der einige 100 MB große Apparat gar nicht erst in Betrieb genommen um meine paar KB an Webinhalt zu präsentieren. Dynamisch ist bei mir sowieso eher wenig – und wenn, dann eher weil WordPress es kann, denn das ich es wirklich brauche.

Ich stand also wieder vor einem kleinen, eher experimentellen Projekt und wollte wie gewohnt WordPress, MariaDB, Apache2 und PHP installieren. Moment! Der „HostHost Als Host bezeichnet man einen PC / Server, welcher das für eine Virtualisierung benötigte Betriebssystem (KVM, VMWare®) für Gastrechner bereitstellt. Oft auch scherzhaft "Blech" genannt, da hier meist die "reale" Hardware gemeint ist.“ ist ein Armv6 Rechner mit 500MB Ram, besser bekannt als Raspberry Pi 1B. „Da war doch vor kurzem ein Artikel über alternative CMS-Systeme“, den kramte ich aus meiner Linkliste.

Zwei grundlegende Ansätze drängten sich mir auf, FlatFileCMS (z.B. GravCMS, Typemill, …) und Static Site Generatoren (z.B. Hugo, Jekyll, …).

FlatFile CMS bedeutet, dass die Webinhalte in Markdown Dateien in einer Ordnerstruktur, die der Webseitenstruktur entspricht, im Dateisystem des Webservers abgelegt werden. Der Zugriff ist so insbesondere bei kleinen Webseiten, bei denen die Markdown Datei via PHP mit dem Template verknüpft und vom Webserver bereitgestellt und ausgeliefert wird, erheblich schneller als bei einer angeflanschten Datenbank. Das mag bei umfangreichen Webseiten oder bei sehr vielen Webzugriffen anders sein, aber das habe ich nicht getestet.

Bei einem Static Site Generator wird typischerweise aus Markdown Dateien und einem Template eine pure HTML-Datei mit CSS und evtl. ein wenig Javascript generiert. Die dadurch entstehende Ordnerstruktur wird auf dem Webserver abgelegt und als reines HTML ausgeliefert. Das gibt noch einmal einen richtigen Performance-Kick oder anders herum gesehen schont es die Ressourcen. Die wohl größten Nachteile sind das separat zu behandelnde GUI, bzw. die recht steile Lernkurve bei der Grundeinrichtung aller Elemente. Das mit dem GUI hat natürlich auch Vorteile, ich kann es unabhängig vom Static File Generator auswählen.

Es galt verschiedene Kriterien zu erfüllen und verschiedene Bedürfnisse abzuwägen, hauptsächlich waren das neben ressourcensparendem Fußabdruck ein komfortables Erstellen und Verwalten von Artikeln für die Webseite und ein einfacher Einsatz bzw. ein schnelles Einarbeiten.

Nach verschiedenen Versuchen setzte sich das FlatFile CMS Grav durch. Eine einfache Installation, dazu sollten PHP und Nginx zum Betrieb ausreichen. Die angebotenen Templates waren schlicht, aufgeräumt und richtig schnell. Auch das Backend (Grav-Admin) war in kurzer Zeit zu erlernen und mit der Markdown Syntax für die Webseiten hatte ich mich auch schon angefreundet.

So begeistert ich anfangs von GravCMS war, kamen aber auch einige Rückschläge. Für mein kleines Projekt benötigte ich keine Plugins außer dem Admin-Modul. Das Core-System von Grav lief mit PHP 8.2 wie geschmiert und das simple Template, das ich mir ausgesucht hatte, schien auch alle meine Wünsche zu erfüllen.

Kurz darauf sollte ein weiterer, etwas anspruchsvollerer Blog entstehen. Begeistert wie ich nun mal war, wollte ich GravCMS gleich bei diesem weiteren, erheblich umfangreicheren Projekt einsetzen und gegenüber dem von mir standardmäßig eingesetzten WordPress den Vortritt lassen. Leider folgten hier einige Hiobsbotschaften. Neben den Fonts von Google bzw. über Fontawesome, was im Endeffekt auf das selbe hinaus läuft – einen Verstoß gegen die DSGVO bzw. das Riskieren einer Abmahnung – stellte sich viele der schon in die Jahre gekommenen Plugins als nicht oder nur bedingt einsatzfähig heraus. Woran das lag, finde ich möglicherweise irgendwann heraus, ich vermute es waren Probleme mit PHP8.2 / 8.3. Am unangenehmsten viel mir der sorglose Umgang der Community mit Anbietern wie Google, Awesomefont oder Disqus auf. Es war schon eine gewisse Pfriemelei die Templates möglichst vollständig davon zu befreien.

Beim Thema Kommentarfunktion stieg ich dann nach drei Tagen vergeblichen Recherchierens und Experimentierens endgültig aus. Die Vorhandenen Module wollten partout nicht mit meinem System zusammenarbeiten. Schweren Herzens trennte ich mich also wieder von GravCMS und suchte weiter.

Natürlich hätte ich wieder zu WordPress greifen können, aber wenn ich schon einmal den Entschluss gefasst hatte, wollte ich es ohne durchziehen.

Ich sah mir Jekyll und Hugo, zwei OpenSource Static HTML Generatoren an. Das klang vielversprechend – dachte ich… Zuerst einmal musste ich feststellen, dass es sich hier nicht um ein CMS im herkömmlichen Sinne handelte. Viel mehr arbeitet man mit Jekyll oder Hugo auf einem Entwicklungssystem, dem eigenen PC zum Beispiel. Änderungen kann man so Live im Browser betrachten und ausgiebig testen. Wenn man zufrieden ist, schiebt man nur des Ergebnis auf den Webserver.

Schließlich entschied ich mich für Jekyll, mehr aus Sympathie, denn aus harten Fakten.

Auch bei Jekyll stieß ich auf das Problem eingebundener Fonts, hatte aber schon Übung diese aus dem von mir erwählten Template zu entfernen. Jetzt kam der Knüller! Jekyll generiert HTML Dateien – Punkt. Mir war schon lange nicht mehr bewusst, wie viele Funktionen man mit HTML und CSS nicht hat. Ein simples Kontaktformular stellt hier schon eine gewisse Herausforderung dar.

Ich las mich durch viele Forenbeiträge. Die Nutzer von Jekyll schienen eine Abneigung gegen PHP zu haben, standen Betreibern wie Github (Microsoft) oder Disqus (teils werbefinanziert) aber offen gegenüber – eine für mich etwas merkwürdige und schwer nachvollziehbare Sichtweise. Für mich ist der Verbleib meiner Daten auf meinem Server aber ein sehr wichtiges Element, darum erstellte ich mir mein Kontaktformular mit PHP erst mal selbst, was Jekyll erstaunlich gut ab kann.

Was ich noch erwähnen sollte, die Lernkurve bzgl. Jekyll ist steil. Richtig steil. Wenn man sich aber eingearbeitet hat, bekommt man ein Gefühl zurück, das ich schon seit langem nicht mehr kannte: „Kontrolle über meine Webseite!“

Also betreibe ich im Jahr 2024 eine HTML-basierte Webseite, mit wenigen zusätzlichen Codeschnipseln. Old fashioned? Vintage? Schnell, bunt und stabil!

Nachtrag: ich verwende als Kommentar-System „Isso“ ein kleiner in Python geschriebener Service, der die Verwaltung der Kommentare übernimmt, lokal und Ressourcensparend.