Wechsel von Hugo auf Zola

Die Recherche

Mein Hugo Theme war inkompatibel mit der aktuellen Hugo Version. Bei der Suche nach Lösungen fand ich Zola. Zola ist in Rust implementiert, damit etwas neuer als Hugo und eine der Installationsmethoden ist flatpak. Das ist wunderbar Linux-Distributionsunabhängig und gerade jetzt, wo ich noch immer zwischen nix und debian hin und her überlege, praktisch. Als Theme nutze ich tabi. Die Konfiguration basiert auf Dateien, die Dokumentation ist logisch und einfach. Analog zu Hugo muss man die jeweilig gewünschte Einstellung in der richtigen Datei durchführen und da auch bei Zola bei jedem Speichern die Draft - Seite neu generiert wird, ist ein iteratives Vorgehen gut machbar. Immer nur einen Schritt machen, speichern, Ergebnis oder Fehlermeldung prüfen, weitermachen.

Der tatsächliche Wechsel

Das schöne an markdown basierten Static Site Generatoren ist: Das Ergebnis ist eine Sammlung an Dateien, die zu einer Hosting - Plattform, in meinem Fall Codeberg Pages kopiert werden. Jedes Veröffentlichen ist ein neues "Dateien Kopieren". Damit ist ein Wechsel des zugrundeliegenden Static Site Generators recht einfach.

Der Content besteht bei Zola und Hugo aus Markdown Dateien. Das heißt, auch hier ist es recht einfach zu wechseln. No Vendor Login ist einfach was Schönes. Oder genauer gesagt: No Tool Login ist was Schönes.

Neues Codeberg Repository

Zunächst lege ich ein neues Codeberg Repository an. Dabei mache ich das initiale Setup, um danach in meinem gewohnten Workflow arbeiten zu können. In meinem Fall ist es eine tmuxinator Konfiguration mit je einem Tab für Neovim zum Schreiben, Lazygit für Repository - Verwaltung und einem Terminal, das automatisch bei tmuxinator start den flatpak run org.getzola.zola serve --drafts --open Befehl ausführt. Mein Workflow ist dann: In mein homepage Verzeichnis wechseln, tmuxinator start durchführen und schon bin ich in einer tmux Session mit allem, was ich brauche. Zusätzlich öffnet sich im Webbrowser die aktuelle homepage, welche sich mit jedem Speichern neu generiert.

Initiales Zola Setup

Hier orientiere ich mich an den Dokumentationen von Zola und tabi in meinem Iterativen Schritt für Schritt Vorgehen. Im Endeffekt arbeite ich mit der config.toml und einigen index.md Dateien. Wer es genau wissen will, schau einfach in die ersten git commits des Repos.

Content von Hugo Repository kopieren

Der Content sind Markdown Files und einige Bilder. Die Idee war: vom Hugo Repository and die richtige Stelle im Zola Repository kopieren. Und genau das funktioniert wunderbar. Direkt nach dem Kopieren generiert sich die Seite neu und meine Blog Posts werden sicht - und lesbar. Ins Auge sticht nur ein Detail: die embettet Youtube Links funktionieren noch nicht in Zola. Die Lösung ist schnell gefunden, die Syntax zum Embetten ist anders:

<div {% if class %}class="{{class}}"{% endif %}>
    <iframe src="https://www.youtube-nocookie.com/embed/{{id}}{% if playlist %}?list={{playlist}}{% endif %}{% if autoplay %}?autoplay=1{% endif %}" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
</div>

In allen Markdown Dateien mit Youtube Links passe ich die jeweilige Syntax an. Hier sind neovim Macros natürlich sehr praktisch.

commit c9e17902321557e488eb8e89dd68524e172af4b9
Author: Matthias Jonen <git@jonen.at>
Date:   Sat Aug 30 11:36:52 2025 +0200

    youtube links an zola angepasst

diff --git a/content/blog/immicherforschen/index.md b/content/blog/immicherforschen/index.md
index a494572..b285429 100644
--- a/content/blog/immicherforschen/index.md
+++ b/content/blog/immicherforschen/index.md
@@ -88,7 +88,7 @@ dedizierten Blog Post schreiben.
 Und das kleine littlenas entlasten.
 [Die Dokumenation](https://immich.app/docs/features/ml-hardware-acceleration)
 zeigt, es geht wieder mit Docker compose. Ein Youtube Video gibt es auch:
-{{< youtubeLite id="QHWNu_in0Zc" label="Put your gaming GPU to work! Remote machine learning on Windows with Docker and WSL2 from anywhere." >}}
+<div >
    <iframe src="https://www.youtube-nocookie.com/embed/QHWNu_in0Zc" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
</div>

Automatisierung des Veröffentlichens

Auf der Zola Webseite ist für Codeberg Pages eine Automatisierung mit Woodpecker CI dokumentiert. Das habe ich selbst aber noch nicht konfiguriert und für den Start - und wohl noch sehr lange - reicht aus meiner Sicht ein einfaches bash Skript:

#!/usr/bin/env bash

shopt -s extglob
shopt -s dotglob
tmp_dir=$(mktemp -d)

pushd $tmp_dir
echo "Codeberg pages git repo clonen"
git clone ssh://git@codeberg.org/MatthiasJonen/pages.git
cd pages
rm -rf !(.git) # Alles außer das .git directory löschen um ein sauberes Ziel für zola zu haben
popd

echo "Zola build durchführen"
flatpak run org.getzola.zola build
cp -ar ./public/. $tmp_dir/pages/.

pushd $tmp_dir/pages
echo "Zola build veröffentlichen"
git add .
git commit -m "Veröffentlichung: $(date +'%Y-%m-%d')"
git push
popd

# Cleanup
shopt -u extglob
shopt -u dotglob

trap 'rm -rf "$tmp_dir"' EXIT

Die Nutzung ist recht einfach: Im Root - Verzeichnis des Repositories einfach publish.sh starten.

Feintuning

Da die Seite grundsätzlich schon ganz gut aussieht, mache ich jetzt das Finetuning. Das sind bisher folgende Schritte:

• Lokalisation auf deutsch
• Posts auf toml Syntax umgestellt. Hugo arbeitet mit yaml Syntax. Dabei habe ich auch die Taxonomies (die Tags) definiert. Auch hier helfen neovim Macros sehr.
• Sozials (die favicons mit Links im Footer der Seite) definiert.

Fazit

Für mich fühlt sich der Wechsel einfacher an, als ich zuvor erwartet hatte. Die ersten Schritte mit Zola sind für mich logisch nachvollziehbar und die Arbeit mit der config.toml Datei ist wegen der guten Fehlermeldungen von zola sehr anwenderfreundlich. Da die Dokumentation gut ist, muss ich wenig recherchieren. Mein Blog wird hoffentlich lange bei Zola bleiben können.

Matthias