JeffGeerling.com wurde zu Hugo migriert

 (jeffgeerling.com)
2 Punkte von GN⁺ 2026-01-06 | 1 Kommentare | Auf WhatsApp teilen
  • JeffGeerling.com, das seit 2009 auf Drupal basierte, wurde für mehr Effizienz beim Betrieb eines persönlichen Blogs auf den statischen Site-Generator Hugo (SSG) umgestellt
  • Die vielen Upgrades und der Wartungsaufwand von Drupal 6 bis 10 waren der wichtigste Anlass für den Wechsel
  • Hugo unterstützt Markdown-basiertes Schreiben und vereinfacht damit den bisherigen komplexen Veröffentlichungsprozess; Veröffentlichen und Deployment lassen sich mit einer einzigen Befehlszeile erledigen
  • Während der Migration können einige Probleme wie fehlerhafte Bildlinks und verlorene URLs auftreten; Kommentar- und Suchfunktion sollen in einem späteren Schritt wiederhergestellt werden
  • Als Beispiel für einzelne Entwickler zeigt der Fall, wie ein schlanker Workflow und effizientere Wartung die praktischen Vorteile eines Wechsels zu einer statischen Website verdeutlichen

Hintergrund des Wechsels von Drupal zu Hugo

  • Die Website begann 2009 mit Drupal 6 und wurde schrittweise auf 7, 8, 9 und 10 aktualisiert
    • Das CMS, das er beruflich mehr als zehn Jahre lang nutzte, kam auch auf dem persönlichen Blog zum Einsatz
  • Nach dem komplexen Upgrade-Prozess von Drupal 7 auf 8 nahm die Ermüdung zu, für einen privaten Blog weiterhin eine unternehmensorientierte Digital Experience Platform (DXP) zu betreiben
  • Der Blog dient als Begleitplattform für persönliche Projekte und YouTube-Inhalte; der Wechsel wurde beschlossen, um sich stärker auf das Schreiben statt auf die CMS-Wartung zu konzentrieren

Warum Hugo gewählt wurde

  • Es gab bereits Erfahrungen damit, frühere Hobby-Websites auf statisches Hosting umzustellen; einige davon wurden auf Jekyll oder Hugo migriert
  • Jekyll eignet sich gut für GitHub Pages, aber als Nicht-Ruby-Spezialist wurde die einfache Konfiguration und hohe Geschwindigkeit von Hugo bevorzugt
  • Hugo bietet native Markdown-Unterstützung und fügt sich damit nahtlos in die bisherige Schreibweise ein

Migrationsprozess und Probleme

  • Die Migration läuft in GitHub Issue #158
  • Wegen von mehr als 3.500 Beiträgen und 20 Jahren Daten sind einige defekte Bilder, fehlerhafte Links und fehlende Redirects möglich
  • Es wird versucht, die bestehende URL-Struktur so weit wie möglich beizubehalten oder Redirects hinzuzufügen

Verbesserter Markdown-basierter Workflow

  • Seit 2020 werden alle Beiträge in Markdown geschrieben
    • Zuvor wurden Texte in Sublime Text in Markdown verfasst, in HTML umgewandelt und dann manuell in Drupal hochgeladen
  • In Drupal waren beim Erstellen eines Beitrags mehrere Schritte nötig
    • Text einfügen, Bilder einzeln hochladen und einbetten, Veröffentlichungsdatum anpassen, Cache leeren usw.
    • Einschließlich Cloudflare-Cache-Verwaltung zur DDoS-Abwehr war der Ablauf entsprechend aufwendig
  • In Hugo kann nach dem Schreiben der Markdown-Datei mit dem Befehl hugo && git commit && git push sofort veröffentlicht werden
  • Der Aufwand für die Serververwaltung mit Composer, Drush, PHP, MariaDB, Nginx usw. entfällt, was die Wartung effizienter macht

Weitere Pläne (TODOs)

  • Die Kommentarfunktion soll in Phase 2 mit einem selbst gehosteten statischen Kommentarsystem wiederhergestellt werden
  • Die Website-Suche basierte früher auf Apache Solr, ist derzeit aber deaktiviert
    • Eine Suchimplementierung innerhalb von Hugo wird in Issue #168 geprüft
  • In der Anfangsphase der Migration sind Kommentare deaktiviert, und die Übernahme der Altbestände wird voraussichtlich Zeit benötigen

Bedeutung des Wechsels

  • Weg von Drupals komplexer Struktur für Inhaltserstellung und -verwaltung hin zu einem einfachen und effizienten Betriebsmodell für statische Websites
  • Ein praxisnahes Beispiel dafür, wie einzelne Entwickler von weniger Wartungsaufwand und mehr Raum für kreatives Arbeiten profitieren können
  • Der Wechsel zu Hugo wird als Schritt bewertet, der die langfristige Tragfähigkeit des Betriebs eines persönlichen Blogs verbessert

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-06
Hacker-News-Kommentare

  • Vor ein paar Jahren habe ich meine persönliche Website auf einen selbstgebauten statischen Site-Generator auf Common-Lisp-Basis umgestellt.
    Anfangs waren es etwa 850 Zeilen, inzwischen ist er auf rund 1500 Zeilen angewachsen und rendert fast alles statisch: Blogposts, Gästebuch, Kommentarseiten, RSS-Feeds nach Tags und mehr.
    Weil ich den gesamten Code sowie HTML und CSS von Hand schreibe, kann ich die Ästhetik vollständig kontrollieren und neue Funktionen schnell ergänzen.
    Um zum Beispiel eine „Backlinks“-Seite hinzuzufügen, brauchte ich nur etwa 40 Zeilen CL-Code und 15 Minuten.
    Inzwischen ist das System sehr stabil, sodass ich kaum noch daran arbeiten muss und mich einfach aufs Schreiben konzentrieren kann.

    • Für einen Charakter wie mich war ein selbstgehosteter Blog das Problem.
      Ich habe meine ganze Zeit damit verbracht, an der Blog-Engine herumzubasteln, und am Ende gar nichts geschrieben.
      Deshalb bin ich absichtlich wieder zu einer Hosting-Lösung mit weniger Kontrolle zurückgekehrt. Jetzt kann ich mich nur noch aufs Schreiben konzentrieren.
    • Mir gefällt an einem Single-Purpose-Static-Site-Generator auch die Freiheit und Stabilität.
      Früher habe ich ein öffentliches Projekt namens Tclssg betrieben; durch Nutzerfeedback habe ich viel dokumentiert und viele Funktionen ergänzt.
      Aber weil es ein öffentliches Projekt war, konnte ich die Struktur nicht einfach nach Belieben ändern.
      Jetzt nutze ich einen Generator nur für meine eigene Seite, bestehend aus Python (900 Zeilen) und Pandoc Lua (700 Zeilen).
      Die technische Entwicklung habe ich auf meiner Website dokumentiert.
    • Geht mir genauso. Ich habe meine Seite taoofmac.com erst auf Hy portiert und dann wieder in Python neu geschrieben.
      Jetzt baue ich sie erneut mit TypeScript/Bun, und trotzdem sind noch LISP-artige Elemente darin.
      Ich suche einen leichtgewichtigen LISP/Scheme-Dialekt, der SQLite und HTML-Parsing eingebaut hat und nativ kompiliert werden kann.
      Mehr dazu habe ich hier zusammengestellt.
    • Ich habe dasselbe gemacht und den Site-Generator in Go implementiert.
      Auch nach Jahren kann ich die komplette Website noch in unter einer Sekunde bauen.
      RSS-Feeds und Code-Highlighting habe ich ebenfalls selbst eingebaut und dafür Chroma und Blackfriday verwendet.
      Ich habe Hugo ausprobiert, fand es aber zu komplex und habe deshalb selbst etwas gebaut.
    • Mich würde interessieren, wie ihr bei einem statischen Blog Kommentare handhabt.

  • Ich bin früher von svbtle zu Hugo gewechselt und bereue das ehrlich gesagt ein wenig.
    Ich habe ein Theme geforkt, aber Hugo ist oft kaputtgegangen, sodass die Wartung zu viel Zeit gekostet hat.
    Inzwischen lässt sich die Seite überhaupt nicht mehr bauen.
    Mein Rat wäre, die Binärversion zum Bauen der Seite zusammen mit dem Quellcode in die Versionsverwaltung zu legen.

    • Mir ist klar geworden, dass manche Software nicht unbedingt aktualisiert werden muss.
      Bei statischen Site-Generatoren gibt es kaum Sicherheitsprobleme; wenn dir also keine Funktion fehlt, kannst du auch einfach bei der alten Version bleiben.
      Solange sich Betriebssystem oder CPU nicht drastisch ändern, ist das normalerweise kein Problem.
    • In der CI-Konfiguration kann man die Version einfach festschreiben.
      Ich habe mich dabei an dieser Konfiguration orientiert und die Version fixiert.
      Um eine funktionierende Version zu finden, ist binäre Suche am effizientesten.
    • Ich habe das mit einem benutzerdefinierten Docker-Image gelöst.
      Lokal und in der CI wird dieselbe Hugo-Version verwendet, also können solche Probleme gar nicht erst entstehen.
    • Wenn man eine Off-the-Shelf-Binärdatei verwendet, kann man sie in ${project}/bin/ ablegen, per .gitignore ausschließen und die Prüfsumme in einer Datei SHA256SUMS festhalten.
      Das ist ein bisschen wie eine einfache Version von Git LFS.
    • Ich hatte dasselbe Problem auch mit Jekyll.
      Beim Umzug auf einen neuen Rechner habe ich Angst davor, die Versionen wieder passend zu bekommen, und deshalb portiere ich die Seite inzwischen nach PHP, bin damit aber noch nicht fertig.

  • Wenn man seine Texte ohnehin in Markdown schreibt, ist der Umstieg auf Hugo nachvollziehbar.
    Ich habe selbst mehr als 500 Jekyll-Posts nach Hugo migriert, und die Template-Syntax war dabei der schwierigste Teil.
    Insgesamt hat es sich aber gelohnt.
    Den Umstellungsprozess und ein automatisches Konvertierungsskript habe ich in diesem Blogpost beschrieben.

    • Mich würde interessieren, warum du von Jekyll zu Hugo gewechselt bist. Mit Jekyll bin ich eigentlich vollkommen zufrieden.

  • SSGs sind gut für statische Websites, aber sobald Interaktion gebraucht wird, braucht man einen Server.
    Wenn ohnehin ein Server läuft, ist es einfacher, Markdown dynamisch zu rendern.
    Letztlich erhöhen SSGs nur die Zahl der Abhängigkeiten und Dinge, die kaputtgehen können.
    Ich vermute, Jeff wird es später bereuen, wenn er Funktionen wie Kommentare ergänzen will.
    Persönlich halte ich einen einfachen Server auf SSR-Basis für die realistischere Lösung.

    • Aber wenn viele Besucher oder Bots kommen, kann ein Server auch zusammenbrechen.
      Statische Seiten haben dieses Risiko nicht, und der meiste Traffic ist ohnehin read-only.
      Jeff scheint die Kommentarfunktion laut Issue selbst implementieren zu wollen.
    • Ich betreibe ebenfalls selbstgehostete Analytics-Tools und ein Kommentarsystem.
      Im Vergleich zu meiner Drupal-Zeit ist der Codeumfang viel kleiner und einfacher.
    • Statische Site-Generatoren gehen eher in Richtung weniger Abhängigkeiten.
    • Ich rendere die statischen Seiten mit einem SSG und behandle Kommentare über einen Common-Lisp- + Hunchentoot-Server.
    • Ich habe meine Seite ebenfalls auf einen SSG umgestellt und bereue es überhaupt nicht. Je einfacher, desto besser.

  • Mich würde der Entscheidungsprozess bei der Wahl eines SSG interessieren.
    Es gibt viele große Tools wie Hugo, Eleventy und Jekyll, und gerade Hugo hat oft Breaking Changes.
    Bei einem älteren Projekt sollte man meiner Meinung nach inzwischen Stabilität garantieren.

    • Tatsächlich hat Hugo in v0.146 das Template-System komplett umgebaut.
      Dadurch ist der Build meines Blogs kaputtgegangen, und auch die Dokumentation ist noch nicht vollständig aktualisiert.
      Die Änderung an sich ist in Ordnung, aber das Problem ist, dass die Dokumentation nicht Schritt hält.

  • Mich würde interessieren, wie sich Pelican heutzutage schlägt. In der Python-Welt scheinen Hugo und Pelican die beiden großen Optionen zu sein.
    Im Vergleich zu RSS wirkt eine ActivityPub-Integration durchaus attraktiv.

    • Ich benutze Pelican und bin zufrieden damit.
      Früher habe ich Nikola verwendet, aber das hatte zu viele Abhängigkeiten und Probleme mit inkonsistenten inkrementellen Builds.
      An Pelican gefällt mir, dass es einfach geblieben ist.
    • Ich nutze Pelican auch schon seit Jahren.
      Die Dokumentation wirkt so, als sei sie zu 90 % fertig, also fehlen bei Details ein paar Dinge, aber wenn man nur die Grundfunktionen verwendet, ist es hervorragend.
    • Ich nutze Pelican mit mehreren selbstgeschriebenen Plugins.
      Es gibt monatliche Commits, also lebt das Projekt noch.
    • Wenn man Python kennt, ist Pelican die natürlichste Wahl.

  • Ich bin gerade dabei, von Hugo auf Zola umzusteigen.
    Konfiguration und Templates von Zola wirken für mich deutlich intuitiver.

    • Ich bin auch von Jekyll zu Zola gewechselt und habe das keine Sekunde bereut.
      Build und Deployment automatisiere ich mit GitHub Actions.
    • Wenn die Anforderungen nicht groß sind, ist die Kombination aus Zola + gist einfach und passend.

  • Ich benutze Hugo seit drei Jahren.
    Was ich gelernt habe: Themes sollte man forken und selbst pflegen.
    Submodule sollte man vermeiden, und Updates besser langsam angehen.
    Die Kommentarfunktion scheint weiterhin knifflig zu sein.

    • Genau. Themes unterscheiden sich am Ende ohnehin von Seite zu Seite.
      Ich wollte auch einmal ein Drupal-Theme übernehmen und habe dann aufgegeben.
      Ich halte es für besser, das Theme direkt einzubinden und nur die nötigen Teile zu überschreiben, statt mit Submodulen zu arbeiten.

  • Letztes Jahr habe ich mit Hugo einen Blog gestartet, und bei 18 Posts hatten drei Viertel Build-Fehler oder machten Probleme.
    Das war so instabil, dass ich ziemlich enttäuscht war.

    • Ich bin ebenfalls von Hugo zu einem selbstgebauten Python-SSG gewechselt.
      Statt mich an die Hugo-Arbeitsweise zu gewöhnen, war es viel angenehmer, mit einer Sprache, die ich bereits kenne, schnell etwas Eigenes umzusetzen.

  • Früher habe ich selbst einen einfachen SSG gebaut, und vor Kurzem habe ich auf der Suche nach etwas Strukturierterem 11ty ausprobiert.
    Aber Liquid-Templates fand ich extrem unbequem.
    Ich wollte JSX-basierte Templates nutzen, aber 11ty macht das ziemlich schwierig.
    Das NextJS-SSG hat zwar viele Funktionen, wirkt aber auch übermäßig komplex.
    Ich überlege deshalb, einen eigenen SSG auf einem Framework wie Tempest aufzubauen.

    • Eleventy unterstützt auch klassische Template-Sprachen wie Mustache.
      Ich habe selbst eine Punch-basierte Website nach Eleventy migriert und fand es besser als Hugo, solange die Build-Geschwindigkeit in Ordnung ist.
      Inzwischen habe ich alles neu mit Astro gebaut.
    • Wir haben die Marketing-Website unseres Startups von NextJS zu Astro migriert und sind sehr zufrieden.
      Es ist primär statisch, erlaubt aber bei Bedarf auch Backend-Logik.
      Für eine einfache Website war NextJS einfach zu komplex.