Hinweis: Dieser Artikel ist älter als 3 Jahre
Inhalte, Quelltexte oder Links können zwischenzeitlich überholt sein.

Making of blog.jakobs.systems

Es war zu Beginn des (ersten?) Corona-Lockdowns im März 2020 als mir während eines abendlichen Jitsi-Meetings von einem befreundetem Admin aus Hamburg der Hinweis gegeben wurde, Hugo eine Chance zu geben. Bestimmt nachdem ich einen Rant über Rapidweaver losgelassen habe, mein bisheriger Static-Site-Generator auf dem Mac.

Der Gedanke musste ziemlich genau ein halbes Jahr reifen, bis es im August endlich so weit war, ein Testballon für Hugo ist gefunden: Mein persönlicher Blog und wenn alles klappt, meine offizielle Website, die langsam in die Jahre gekommen ist.

Und auch wenn ich mich (noch) nicht als Hugo-Experte bezeichnen würde, hier ein erster Einblick, ein Making of welche Hintergründe und Herausforderungen ich bei der Entwicklung in den vergangenen Tagen hatte.

Was ist Hugo?

Hugo ist ein Static Site Generator. Das bedeutet, alle Inhalte eines Internetauftrittes werden lokal auf einer Entwicklermaschine erstellt und anschliessend zu einem Webserver hochgeladen.

Damit unterscheidet es sich fundamental von den zahlreichen online-basierten Content-Management-Systemen. Von der zeitlichen Entwicklung werden Redaktionssysteme im Allgemeinen als Weiterentwicklung betrachtet und heute praktisch von jeder Werbeagentur und Unternehmen zur Umsetzung von Internetseiten eingesetzt. Es fällt mir schwer diesem Narrativ zu folgen. Von einer Weiterentwicklung kann häufig nicht die Rede sein. Gerade wenn Redaktionssysteme in häufiger Regelmäßigkeit als Fachanwendung für etwas “mißbraucht” werden, für das sie nie geschaffen wurden.

Betrachten wir zunächst die Vor- und Nachteile von Static-Site-Generatoren im allgemeinen, Hugo im spezifischen und meine persönlichen Anforderungen an eine Website:

Vorteile:

• Hugo ist eine freie Software mit einer aktiven Community.
• Es ist auf allen Plattformen (Linux, Mac, Windows) verfügbar.
• Hugo erstellt Internetseiten, die Server- und technologieneutral überall betrieben werden können. Egal ob lokal im eigenen Netz oder auf einem beliebigen Internet-Webserver. Selbst die typischen Shared- oder Massenhoster reichen aus.
• Durch Verzicht auf serverseitig generierte Seiten und insbesondere durch die Komplexitätsreduktion auf den produktiven Webservern wird eine maximale Sicherheit erzielt.
• Dadurch wird auch eine höhere Verfügbarkeit und bessere Skalierung gerade bei kritischen oder massenweise gleichzeitig abgerufene Inhalte (z.B. zu bestimmten Event).
• Die Content-Pflege erfolgt offline. Lediglich zur Übermittlung der Aktualisierung wird eine Internetverbindung benötigt. Das ist für jene interessant, die nicht dauerhaft online sein können oder es bewusst nicht wollen (z.B. kritische Unternehmensbereiche, reisende Mitarbeiter mit instabilen Mobilfunkverbindungen etc.)
• Flexibilität mit der Skriptsprache Go und der Möglichkeit eine Website in Komponenten (Partials), Bundles, Templates und Themes zu modularisieren.
• Anhand Schlüsselbegriffe (Tags) können Inhalte katalogisiert werden und in Go abgefragt werden. Bei Hugo nennen sich solche Kataloge Taxonomies und ermöglichen den Aufbau umfangreicher Wissensarchive und Listen über unstrukturierte Daten.
• Inhalte können ohne Programmierkenntnisse von Redakteuren als Textdateien (Markdown) erfasst werden. Zahlreiche Markdown-Editoren für beliebige Plattformen ermögliche ein ungestörtes Arbeiten.
• Die Interoperabilität von Content (Textdateien) und weiterer Assets (Bilder, Downloads) ist bei Hugo gegeben. Es müsen keine Inhalte aufwändig im- oder exportiert werden.
• Hinsichtlich Internationalisierung lassen i18n-Sprachdateien aus Übersetzungsplattformen wie beispielsweise Weblate mühelos integrieren und im Code referenzieren.
• Komplette Freiheit einen Workflow oder Prozess selbst zu gestalten. Redaktionelle Inhalte können z.B. aus Ablageordnern quer aus einem Netzwerk stammen und automatisiert in vorgegebenen Intervallen z.B. stündlich oder täglich auf einer Internetseite publiziert werden.
• In Kombination mit git als Versionsverwaltung werden umfangreiche und große Internetpräsentationen transparent verwaltbar. Häufig ist das genau ein Problem bei Online-Content-Management-Systemen.

Nachteile:

• Die Freiheit, eigene Prozesse realisieren zu können ist gleichzeitig auch Nachteil. Viele können und wollen einen solchen Prozess nicht und sind froh, die Erstellung einer Website teilweise oder vollständig zu externalisieren.
• Ein grafisches Frontend oder eine Entwicklungsoberfläche, die vergleichbar mit der Oberfläche und dem Funktionsumfang anderer Generatoren wie z.B. Rapidweaver ist, gibt es nicht.
• Die Lernkurve zu Beginn ist höher und es muss eine lokale Arbeitsumgebung eingerichtet sein, was beides bei einem Online-Redaktionssystem meist keine Rolle spielt.

Mir fallen wirklich nicht mehr Nachteile ein. Habe ich was vergessen? Dann bite um Hinweis per Mail.

Anforderungen an einen Blog/ Website:

• keine serverseitige Skripte (z.B. PHP).
• keine clientseitigen, aktiven Inhalte (Javascripts).
• keine Ressourcen von Dritten.
• Eine nachhaltige, technologische Grundlage (freie Software).
• Inhalte müssen getrennt vom Design vorliegen.
• Automatisierter Build und Aktualisierung.
• Und last but not least: Ein minimalistisches, elegantes und zeitloses Design.

Wie diese Website entstand

Was das Design anbetrifft habe ich mich dazu entschieden aus der Themengalerie ein geeignetes Theme als Grundlage zum Kennenlernen weiter meinen Bedürfnissen anzupassen.

Rein optisch gefiel mir auf Anhieb “Kiss Em” von Pavel Pi. Er hat es seinerseits als Fork des Themes “Kiss” entwickelt, das wiederum auf Grundlage von “Hemingway” entstanden ist. Die Konsequenz davon war mir anfangs nicht bewusst.

Die Installation von Hugo ist unkompliziert. Die erste Website mit dem Theme in wenigen Zeilen erstellt und die config.toml schnell angepasst. Für den Einstieg hilfreich hat sich das Tutorial von Thomas Leistner¹ erwiesen.

Als Projekt- und Markdown Editor nutzte ich den GNOME Builder.

Die Ernüchterung kam mit Anblick der ersten Online-Tests und der Notwendigkeit, doch früher als erhofft in die Theme-Anpassung einzusteigen. Neben den gemeldeten Fehlern kamen selbstverständlich Farbanpassungen und intern eingebundene Webschriftarten sowie veränderte Tap-Abstände der Navigationselemente hinzu.

Hier rächte es sich, zum Einstieg einen dreifachen Fork als Theme ausgewählt zu haben. So war die Suche nach den passenden CSS Stilvorlagen besonders zeitaufwändig da es galt, den Weg zwischen den zahlreichen unbenutzten jedoch weitervererbten Stilen zu finden.

Auch bei den Partials gab es die Notwendigkeit Hand anzulegen. Bei dem Versuch der fertiggestellten deutschen Sprachfassung auch eine Englische beizufügen stellte ich fest, daß diese immer wieder auf die deutschen Inhalte zurück sprang. Die Hugo Konzepte und notwendigen Go-Abfragen waren im Theme nicht umgesetzt. Und so floss ein halber Tag (mit den typischen Unterbrechungen) in den englischen Branch.

Fazit

Die Erlebnisse sollen den Gesamteindruck von Hugo nicht schmälern. Ich blicke auf einige gelungene und produktive Tage zurück und habe endlich einen modernen Blog.

Besonders gefällt mir die Möglichkeit mit Go bisher komplexe Vorgänge schmerzfrei und unkompliziert umzusetzen zu können. Hier ein Beispiel für Pipes:

{{ $style := resources.Get "css/main.css" | resources.Minify | resources.Fingerprint }}

<link rel="stylesheet" href="{{ $style.Permalink }}">

Bei Rapidweaver hieß das nach jedem Build manuell mit dem yui-compressor sich durch die CSS zu wühlen und in der Konsole die Fingerprints zu erstellen.

Ein Migrationstool für Webs aus Rapidweaver heraus scheint es nicht zu geben, dafür aber für eine Menge andere Content-Management-Systeme².

Hugo als Static-Site-Generator kann was und ist mächtiger als gedacht. Und ja, es wird demnächst bei meiner offizielle Firmen-Website zum Einsatz kommen.

Zuvor möchte ich jedoch meinen Workflow für das Deployment vollständig automatisiert wissen.

In diesem Sinne, Euer Tomas Jakobs