Mein letzter Beitrag wurde im März 2021 veröffentlicht, und seitdem ist fast nichts mit dem Blog passiert - trotz Umzügen, Serverwechseln und zahlreichen anderen Entwicklungen. WordPress war eher irritierend als hilfreich für die Rückkehr zum Schreiben von Beiträgen: Es war langsam, erforderte ständige Plugin-Updates und Sicherheitslücken häuften sich, während es für einen Blog, der nur wenige Beiträge pro Jahr veröffentlicht, übermäßig komplex war.

Seit Jahren hatte ich erwogen, zu einem statischen Site-Generator zu wechseln, aber der Gedanke an die Migration - 87 Beiträge, viele HTML-Überreste, Mediendateien - schreckte mich immer ab. Dann entdeckte ich OpenCode, und alles änderte sich.

Migrationsplan#

OpenCode ist ein terminalbasiertes KI-Tool, das es mir ermöglichte, den größten Teil des Migrationsprozesses zu automatisieren. Der Plan bestand aus fünf Hauptschritten:

  1. WordPress-Inhalt exportieren und in Markdown für Hugo-Struktur konvertieren
  2. Entfernung alter HTML-Überreste
  3. Verlagerung des PrivateBin (ZoliBin) Dienstes
  4. Konfiguration der mehrsprachigen Hugo-Site
  5. Übersetzung aller Beiträge in vier Sprachen

Die letzten beiden Punkte schienen besonders ambitioniert, aber letztendlich habe ich sie umgesetzt.

Inhalts-Export und Konvertierung#

Mit der integrierten Exportfunktion von WordPress habe ich alle Inhalte im XML-Format extrahiert. Ich beauftragte die KI mit dem Schreiben eines Skripts, das dies in ein Hugo-kompatibles Markdown-Format konvertierte, wobei Titel, Daten, Kategorien und Tags erhalten blieben. Shortcodes wurden in HTML/Markdown-Äquivalente umgewandelt, und Disqus-Kommentar-Identifikatoren blieben im Front Matter erhalten.

Mediendateien wurden in den static/-Ordner von Hugo kopiert, sodass alte Links weiterhin funktionieren.

HTML-Bereinigung#

WordPress-Inhalte enthielten zahlreiche HTML-Überreste, die Hugo nicht richtig verarbeiten konnte: unnötige  -Zeichen, spezielle Codeblöcke, WordPress-spezifische Bild-Tags und andere Formatierungen.

Die KI überprüfte alle Beiträge und konvertierte HTML nach Markdown, wo möglich. Komplexere Formatierungen wurden dank des Parameters unsafe = true in Hugos config.toml beibehalten. Dies ermöglichte es, dass alte HTML-Inhalte weiterhin angezeigt werden, ohne alles manuell neu schreiben zu müssen.

ZoliBin-Verlegung#

Ich behielt den ZoliBin (PrivateBin) Paste-Dienst an seinem ursprünglichen Standort, weiterhin über den nginx Reverse Proxy erreichbar. Da Hugo eine statische Site ist, benötigt es kein PHP, aber die Paste-Funktionalität war weiterhin erforderlich. Die Konfiguration blieb unverändert: dateibasierte Speicherung, 1-wöchiges Ablaufdatum, Passwortschutz.

Mehrsprachige Einrichtung#

Ich konfigurierte die mehrsprachige Unterstützung von Hugo für vier Sprachen: Ungarisch (Standard), Englisch, Portugiesisch und Deutsch. Die Einstellung defaultContentLanguageInSubdir = true ermöglichte es, dass ungarische Inhalte weiterhin unter der Root-Domain erreichbar bleiben.

Menüpunkte wurden in alle Sprachen übersetzt, aber URL-Slugs blieben aus Migrationsgründen auf Ungarisch. Mediendateien sind weiterhin über die alten Pfade verfügbar, dank des static/-Ordners von Hugo.

Übersetzungsprozess#

Die Übersetzung verlief recht ereignislos, es war nur eine einfache Prompt (natürlich aktualisierte die KI kontinuierlich die AGENTS.md, und die Dokumentation landete auch dort bezüglich der Seitenstruktur).

Startseiten-Probleme#

Ein interessanter Fehler trat mit Hugo Version 0.146 auf: Die Datei content/index.md erzeugte ein Leaf Bundle, das das Rendern anderer Inhalte verhinderte. Die Lösung bestand darin, die Datei zu löschen und die Startseiten-Konfiguration vollständig in config.toml zu verschieben.

Das Terminal-Theme-Template musste auch geändert werden, weil die mehrsprachige Startseite Beiträge nicht korrekt filterte. Die Verwendung von .Site.RegularPages löste das Problem, sodass auf der ungarischen Startseite nur ungarische Inhalte erscheinen.

Ergebnisse und Lehren#

Die Migration dauerte einige Stunden, wobei die meiste Zeit für das erneute Prompten des KI-Agenten aufgewendet wurde, während ich beobachtete, wie die Migration fortschritt und verschiedene Probleme auf der im Aufbau befindlichen Site sah.

Das Ergebnis ist eine schnelle, statische Hugo-Site, die kein PHP benötigt und minimale Ressourcen verbraucht. Automatische Updates stellen sicher, dass immer die neueste Version läuft.

All dies machte es möglich, dass 261 Übersetzungen und HTML-Bereinigung eine Arbeit von wenigen Stunden statt einem Monat wurden. Das GLM 5.1-Modell lieferte gute Übersetzungen, und wo es Fehler machte, tat es dies konsistent, was schnelle Korrekturen ermöglichte. Leider war die Übersetzungsqualität nicht immer perfekt, also musste ich anschließend das deepseek-v3.1.671b-Modell für den letzten Schliff ausführen.

Ehrlich gesagt hätte ich nicht gedacht, dass ein KI-Agent zu einer so komplexen Migration fähig wäre, und es lässt mich darüber nachdenken, wie viel Bedarf es in Zukunft für Sysadmins geben wird. Beim Lesen von Programmier-Subreddits ist bereits sichtbar, dass Menschen sich statt einfachem Codieren mehr in Projektmanager/Product-Owner-Positionen bewegen.

Die Frage ist, wie der Beruf zukünftige IT-Fachkräfte hervorbringen wird, wenn es keine Notwendigkeit mehr für Helpdesk-Mitarbeiter der Einstiegsebene (1. Level) gibt. Ich glaube nicht, dass wir lange auf die Antwort warten müssen…