Neben diesem Blog, auf dem WordPress zum Einsatz kommt, habe ich noch ein paar Web-Sites, bei denen sich der Betrieb eines datenbank-basierten Content Management Systems nicht lohnen würde. So etwa auf geschke.net, meiner ältesten Domain, registriert in grauer Vorzeit anno 1997, wo tatsächlich „nur“ statische Web-Seiten ausgeliefert werden.
Als das Web laufen lernte
Was nach Steinzeit klingt, hat handfeste Vorteile, von denen ich hier nur die für mich wichtigsten nennen möchte. Statische Web-Seiten in Form von einzelnen HTML-, CSS- und JavaScript-Dateien benötigen außer einem Web-Server keine weitere Infrastruktur, insofern keine Datenbank, kein PHP oder sonstige serverseitigen Sprachen, somit auch keine Updates dieser Komponenten. Ganz zu schweigen von Updates des CMS aufgrund von neuen Entwicklungen oder gar Sicherheitslücken. Einmal installiert, und es läuft und läuft und läuft – Updates der Server-Software an sich sollte man natürlich dennoch nicht vergessen. Das Thema Sicherheit ist ebenfalls nicht zu verachten – da vom Web-Server nichts weiter verlangt wird, als Seiten in Form von Dateien auszuliefern, existiert kein umfangreiches Backend wie etwa bei WordPress, somit auch kein Login, keine Datenbank usw., und somit nahezu keine Angriffsfläche für Sicherheitslücken. Das Hosting selbst ist ressourcenschonend, die Performance daher entsprechend hoch, selbst bei geringer Server-Kapazität. Von hervorragender Skalierbarkeit, der einfachen Verwendung von CDNs (Content Delivery Networks) will ich erst gar nicht anfangen, zumindest für die drei Requests auf meine Seiten würde vermutlich auch ein ESP32 oder ein zehn Jahre altes Handy ausreichen.
Da es jedoch eher wenig Spaß macht, Web-Seiten manuell zu bauen – diese Zeit ist seit spätestens 1998 wirklich vorbei – gibt es die Softwaregattung der Statischen Website Generatoren (Static Site Generator, SSG). Diese dienen dazu, Inhalt und Design zusammenzubringen. Die eigentlichen Inhalte werden also nicht direkt im HTML-Format verfasst, sondern in einer einfacheren Sprache wie etwa Markdown, während das Design aus vorgefertigten oder auch eigens erstellten Templates kommt. Zusammen mit einer gewissen Konfiguration erstellt der SSG dann aus den einzelnen Komponenten die komplette Web-Site in Form der dazu gehörigen HTML-, CSS- und ggf. JavaScript-Dateien. Diese können zur Veröffentlichung, neudeutsch Deployment, dann einfach auf den jeweiligen Web-Server kopiert werden.
CMS? SSG? WTF?
SSGs könnte man somit auch als eine Art CMS bezeichnen, nur dass die Bearbeitung auf anderer Ebene stattfindet als in einer Web-UI wie bei WordPress oder nahezu fast allen anderen Content-Management-Systemen. Oder konkreter – für die Bearbeitung der Inhalte in Form von Markdown-Dateien genügt ein einfacher Text-Editor, dasselbe gilt für die Anpassung der notwendigen Konfigurationsdateien. Das Editieren von Bildern wird einfach mit den Programmen erledigt, die man üblicherweise dafür benutzt, anschließend werden die Bild-Dateien an die entsprechende Stelle im lokalen Dateisystem kopiert. Und für das Deployment reicht möglicherweise sogar ein simpler FTP-/FTPS-/SFTP-Client, andererseits kann dieser Schritt auch wunderbar automatisiert werden. Wenn beispielsweise Git und GitHub für die Versionierung genutzt wird, was sich bei einem dateibasierten System von vornherein anbietet, kann das Deployment durch die Verwendung einer GitHub-Action erfolgen. Updates von Web-Seiten sind damit perfekt in den Workflow integriert.
Natürlich gibt es auch Nachteile, die letztlich in der Struktur begründet – also inhärent – sind. Wirklich dynamische Inhalte sind nur mit zusätzlichen Diensten möglich, das betrifft etwa Benutzerkonten, Formulare, Kommentare usw.. Der redaktionelle Workflow ist weniger intuitiv bzw. weniger bequem als wenn sämtliche Aktionen über eine zentrale Web-UI gesteuert werden. Die Build-Zeit und damit die Zeit bis zur Veröffentlichung von Änderungen kann insbesondere bei größeren Sites etwas länger sein, und die anfängliche Konfiguration, insbesondere bzgl. des Deployment ist etwas aufwändiger. Insgesamt hängt der Sinn oder Unsinn der Verwendung eines Tools wie üblich vom jeweiligen Einsatzzweck ab – als Faustregel könnte man angeben, dass SSGs hervorragend für stabile, inhaltsgetriebene Seiten geeignet sind, aber weniger für stark interaktive oder redaktionslastige Plattformen.
Hugo? Hugo!
Daher nutze ich sowohl WordPress für dieses Blog hier (erstmal) weiter, während u.a. die mehr oder minder nur „Hallo, hier bin ich…“ aussagenden Seiten auf geschke.net mittels eines SSGs generiert werden. Dafür nutze ich die Software namens Hugo, wobei ich kaum erwähnen muss, dass es natürlich auch andere SSGs gibt. Hugo ist in Go geschrieben, allein das war für mich ein Argument für den Einsatz, ist extrem schnell, d.h. der Build-Prozess verbraucht nur wenig Zeit, hat keine Abhängigkeiten (wie z.B. eine riesige Node-Toolchain), alles ist in einem Go-Binary integriert und somit auf unterschiedlichen Plattformen auf einfache Art und Weise installierbar. Hugo ist außerdem sehr flexibel bei Taxonomien, Menüs, multilingualer Struktur und bietet ein umfassendes Feature-Set (Pagination, Listen…) und beinhaltet ein mächtiges auf Go basierendes Template-System. Über die Vor- und Nachteile weiterer SSGs wie Jekyll, Gatsby, Nuxt, Next.js, Elevently und wie sie alle heißen, will ich hier gar nicht schreiben, jedes davon hat seine Stärken und Schwächen, und während ich mich eher im Go-Umfeld wohl fühle, Ruby aber herzlich dankend ablehne, wird ein Jekyll-Anwender unter Umständen genau das Gegenteil gelten.
Meine Hugo-Story (und das erste Hugo-Theme)
Genug der Vorrede, nun endlich zum Kern dieses Beitrags, wobei dieser genaugenommen auch wieder eine gewisse Vorgeschichte benötigt… Also – es war einmal… Nein, in aller Kürze – vor etlichen Jahren war bei mir noch mehr Domain-Wildwuchs angesagt, und irgendwie wollte ich zumindest Inhalte auf die dazu gehörigen Web-Sites packen, ohne jedes Mal WordPress in Anspruch zu nehmen. Zunächst hatte ich dazu das dateibasierte PHP-CMS namens Grav eingesetzt, und dafür das Design erstellt, was in einem kleinen Theme namens Tikva mündete.
Da ich keine Pixel schubsen wollte und mir das Design des Bootstrap-CSS-Framework allgemein sehr gut gefiel, wurde dieses als Basis des Tikva-Themes auserkoren. Gleichzeitig nutzte ich WordPress für dieses Blog, und aus nahezu denselben Gründen, die zum Theme Tikva für Grav führten, entwickelte ich ein damals noch identisch genanntes Theme Tikva für WordPress. Da Grav für den Einsatzzweck jedoch letztlich zu viel des Guten wurde, folgte irgendwann der Umstieg auf Hugo, wofür ich dann das Theme „Tikva“ von Grav auf Hugo portierte. Im Laufe der Zeit kamen jedoch beim WordPress-Theme noch kleinere Features hinzu, von denen ich einige wiederum auf das Hugo-Theme übertragen habe. Somit gab es letztlich zwei parallel laufende Entwicklungen – einmal Tikva für Hugo und einmal für WordPress. Wobei Letzteres wiederum von einem dank Umstieg von Bootstrap 4 auf Boostrap 5 neuen bzw. darauf basierenden, aber weiter entwickelten Theme ersetzt wurde… also gut, lassen wir das.
Die Jahre vergingen, und tatsächlich hatte ich für eine geraume Zeit die Seiten auf geschke.net und anderen, Hugo-basierenden Web-Sites nicht verändert. Auch das Theme Tikva für Hugo hatte seine letzten Änderung vor mehr als zweieinhalb Jahren erhalten, die letzten einigermaßen relevanten Änderungen lagen bereits fünf Jahre zurück, während die eigentliche Entwicklung vor etwa sieben Jahren stattgefunden hatte. Alles danach war letztlich nur Pflege und ein wenig Versions-Updaten.
Nun hatten mich letztlich Änderungen am Backend für das Kontaktformular dazu gebracht, die Hugo-basierten Seiten einmal wieder genauer unter die Lupe zu nehmen. Und wie dem so ist, fielen natürlich einige Aspekte auf, bei denen eine Änderung bzw. ein grundlegendes Update zumindest wünschenswert war. Tikva für Hugo basierte noch auf Bootstrap 4, war also alles andere als aktuell. Die Berücksichtigung von mobilen Devices war ebenfalls – sagen wir mal – verbesserungswürdig. Kleinere Probleme, die auf GitHub eingetragen worden waren, hatte ich geflissentlich ignoriert, denn insgesamt war letztlich alles so veraltet, dass ich den Einsatz überhaupt nicht mehr empfehlen hatte wollen. Immerhin wurde Bootstrap 5 bereits 2021 freigegeben, somit wurde es höchste Zeit, das Theme dahingehend anzupassen.
(Fast) alles neu: Felmdrav – ein Hugo-Theme
Die ersten Schritte bestanden genau aus diesem Punkt, d.h. Bootstrap 4 wurde durch Bootstrap 5 ersetzt. Aber dann gab es noch die Icon-Library Font Awesome, die inzwischen eher durch Lizenz-Verwirrungen, Free- vs. Pro-Version, und somit zu vorsichtig formuliert strategischer Reibung führte. Hingegen waren die Bootstrap Icons nicht nur von guter Qualität, sondern auch im Umfang gewachsen und dank einfacher, einheitlicher MIT-Lizenz problemlos in Themes verwendbar. Ergo: Font Awesome raus, Bootstrap Icons rein. Dann hatte ich ja noch die Designs von Bootswatch eingesetzt – auch da bedurfte es eines Updates. Für CSS-Dateien wurden nun teilweise Hugo Pipes genutzt, alte Abhängigkeiten aus Bootstrap 4 wurden entfernt, usw.. Die Migration bzw. insbesondere Tests anhand der exampleSite führten zu weiteren Änderungen, Anpassungen und Optimierungen, etwa der Verwendung der neuen Template-Struktur ab Hugo 0.146.0, nach dem Motto – wenn schon neu, dann auch richtig.
Des Weiteren waren auch diverse Optionen aus der Konfigurationsdatei überholt und damit unnötig geworden, etwa zur direkten, pixel-genauen Positionierung, da dies nicht mehr aktuellen Anforderungen entsprach und durch Bootstrap-eigene CSS-Klassen ersetzt werden konnte. Weitere Features, aber auch absichtlich herbei geführte Brüche gegenüber dem Theme, das sich einst Tikva nannte, führten dazu, dass Rückwärtskompatibilität schon lange nicht mehr gegeben war. Letztlich führten die Änderungen in der Gesamtheit dazu, dass das Theme kein blößes Update von Tikva wurde, sondern ein neues Theme, das allenfalls als Nachfolger bezeichnet werden konnte. Somit hat es auch einen neuen Namen erhalten, der da lautet: Felmdrav.
Felmdrav bietet neben dem responsiven, mobile-first Design von Bootstrap 5 auch einige Features, die es beim Vorgänger noch gar nicht gab. Dabei hatte ich weniger die eigene, simple und zuvor genannte Site im Kopf, sondern eher den universellen Einsatz, vielleicht auch, um zukünftig in einem Blog wie diesem hier verwendet werden zu können.
Block-System für Inhalte und Layout
Vollständig neu ist das Block-System, das den Aufbau von Seiten aus wiederverwendbaren, klar definierten Komponenten ermöglicht. Zwar ist die Trennung von Inhalten und Layout bzw. Design bereits durch die Verwendung eines Themes gegeben, durch die Content-Blöcke wird dieses Schema jedoch auf einzelne Bestandteile von Seiten angewendet. Die Vorlage war letztlich Bootstrap selbst, oder vielmehr einzelne Komponenten auf den Beispiel-Seiten, etwa die „Features„. Beispielsweise befindet sich auf einer Start-Seite selten nur reiner Text, sondern Inhalte werden kurz angekündigt und verlinkt, vielleicht noch mit einem Bild unterlegt oder mit passenden Icons versehen – in diesem Sinne bilden derartige Elemente die übliche „Call-to-Action„-Maßnahme (CTA) ab, die den Benutzer zu einer gezielten Handlung veranlassen sollen, etwa um einen Artikel zu lesen, Kontakt aufzunehmen oder ähnliches. Typische Elemente wären etwa unterschiedliche „Hero“-Blöcke, d.h. optisch auffällige und größere Bereiche mit Bildern, oder auch „Feature“-Blöcke.
Zur besseren Vorstellung zunächst ein Beispiel eines „Hero-Blocks“:
Und ein „Featured“-Bereich könnte etwa wie folgt aussehen:
Technisch setzen sich die Blöcke aus den jeweiligen Inhalten, die wiederum in einem Markdown-File definiert werden, und den Layouts, die in einem Hugo-Partial enthalten sind, zusammen. Für die Homepage existiert die Möglichkeit, diese komplett aus unterschiedlichen Blöcken mittels Front-Matter-Definition zu kreieren. Auf beliebigen Markdown-Seiten werden Blöcke als Shortcode eingebunden. Und natürlich beschreibt die Block-Dokumentation sowohl die Einbindung als auch die unterschiedlichen Blöcke in hoffentlich ausreichender Ausführlichkeit.
Der „Featured Posts“-Block
Besonderen Augenmerk habe ich auf den „Featured Posts“-Block gelegt. Als Vorbild diente dieses Blog – seinerzeit hatte ich dem WordPress-Theme ein Feature hinzugefügt, das eine Kennzeichnung eines Artikels ermöglicht. Damit können Beiträge hervorgehoben werden, um in einem speziellen Bereich oberhalb der Beitragsliste zu erscheinen. Dieses Feature ist bei Felmdrav für Hugo sogar noch mächtiger, denn einerseits können beliebige Seiten manuell mit allen Angaben wie Titel, Text, Beitragsbild, Tags, Kategorie, URL usw. für einen Featured-Posts-Bereich ausgewählt werden, andererseits kann die Auswahl auch nach bestimmten Kriterien, z.B. die neuesten n Artikel aus einem bestimmten Bereich, automatisiert erfolgen. Nicht zuletzt können mehrere Featured-Posts-Bereiche definiert werden, und in einzelnen Artikeln kann wiederum festgelegt werden, in welchen Bereichen die Artikel erscheinen sollen. Ebenso ist eine Kombination aus manueller und automatischer Auswahl möglich. Und falls einem das nicht reicht, spricht nichts dagegen, weitere Features (ok, Wortspiel…) hinzuzufügen.
Nach vielen Worten nun auch endlich der dazu gehörige Screenshot eines Featured-Posts-Bereiches:
Felmdrav und Listen, Sidebars, Grid, Designs…
Ein weiteres, neues Feature betrifft die Listen-Ansicht von Inhalten. Über strukturierte Front-Matter-Optionen lassen sich Listen gezielt steuern, auch über mehrere Sections gleichzeitig, wobei eine Sortierung nach Datum, Titel oder Gewicht (weight) erfolgen kann. Damit können beispielsweise einzelne Beiträge aufgrund der Gewichts-Option dauerhaft an oberster Position gehalten werden, während die übrigen Listen-Inhalte durch die automatische Sortierung zusammengestellt werden.
Wesentlich erweitert wurden die Features der Sidebar – anstatt nur einer, die global in der Config-Datei definiert wurde, können nun eine, zwei oder auch gar keine Sidebar eingerichtet werden, wobei es zwar eine globale Voreinstellung gibt, die aber pro Seite bzw. Seitenbereiche mittels Front-Matter überschrieben werden kann. Dabei kommt außerdem das Bootstrap-Grid-System zum Einsatz, mit dem die Spaltenbreite der Sidebars und des Inhalts-Bereiches angepasst werden kann.
Felmdrav kommt wie sein Vorgänger mit einer Auswahl von über 30 Designs, die aus dem Bootswatch-Repertoire stammen, ergänzt durch einige selbst erstellte, bietet flexible Footer- und Subfooter-Bereiche, und lässt sich darüber hinaus vielfältig bzgl. Schriften und Farben anpassen. Die dazu gehörige Beispiel-Seite zeigt die wichtigsten Features von Felmdrav im Zusammenspiel und ermöglicht es, die mitgelieferten Layouts, Blöcke und Designs auszuprobieren. Und nicht zuletzt ist nun eine Dokumentation vorhanden, die diesen Namen auch verdient, im Gegensatz zu den schmalen Kommentaren im Config-File vom alten Theme.
Hugo oder WordPress?
Nun könnte Hugo mit Felmdrav eigentlich sofort das für dieses Blog einsetzte WordPress ersetzen, oder? Im Prinzip ja, aber… Wie eingangs erwähnt, stellen „interaktive“ Features wie Kommentare oder Formulare generell zumindest eine Herausforderung dar. Ohne externe Dienste bleiben statische Seiten eben statische Seiten. Für das auf geschke.net verwendete Kontaktformular hatte ich mir eine kleine, auf Go basierende Backend-Lösung erstellt, die den Namen „Fyntral“ erhielt.
Genau diese war auch der ursprüngliche Ansatz, sich überhaupt wieder mit Hugo bzw. dem Theme zu beschäftigen. Für das Kontaktformular hatte ich vor ewigen Zeiten eine „serverless“-Lösung mit PHP gebaut, die auf dem Open-Source-Projekt bref und AWS Lambda basierte. Der Support für die damals verwendete PHP-Runtime-Engine wurde jedoch eingestellt, genaugenommen hatte ich mich inzwischen gewundert, dass der Code überhaupt noch funktionierte. Zwar wurde auch bref stetig weiter entwickelt, somit wäre auch weiterhin die Nutzung von AWS Lambda möglich gewesen, doch um ehrlich zu sein wollte ich lieber autark bleiben und mich nicht wieder in die Abhängigkeit von AWS und deren gefühlt Myriaden von Diensten und dem damit verbundenen Overhead begeben. Fyntral hingegen ist ein einzelnes, kleines Go-Binary, das sich prima in die bestehende Server-Infrastruktur einfügt – eine kleine Config-Datei, und Docker sowie Traefik erledigen den Rest.
Fazit
Felmdrav könnte somit der Ausgangspunkt für eine weitere Entwicklung sein. Es ist mitnichten ein fertiges Endprodukt, denn mit dem realen Einsatz wachsen mit einiger Sicherheit auch die Anforderungen. Weitere Blöcke wären beispielsweise sehr einfach hinzuzufügen, das Konzept würde ich als durchaus rund bezeichnen. Die Grundlagen sind gelegt, alles weitere bleibt bewusst offen. Wer sich Felmdrav näher anschauen möchte oder eigene Gedanken hat, auch zum Einsatz von Hugo bzw. SSGs vs. CMS, möge nicht zögern, einen Kommentar zu hinterlassen. Hinweise, Fragen oder auch kritische Anmerkungen sind ausdrücklich willkommen.
Und eine kleine Offenlegung am Rande: Bei der Entwicklung von Felmdrav hat mir KI in Form von ChatGPT geholfen, insbesondere betrifft dies die Erstellung der Dokumentation. Dieses von mir seit jeher ungeliebte Thema ließ sich wirklich perfekt delegieren. Dafür ist dieser Text hier 100% handgeklöppelt. Versprochen!
