Der Umzug von WordPress zum Bash Static Site Generator (Warum? Weil es geht! - K. Klein) vollzieht sich wie viele Migrationsprojekte erst in großen und dann in immer kleineren Schritten. 80% sind automatisierter, 20% sind Handarbeit. 80% brauchen 20% der Zeit, 20% brauchen 80% der Zeit, und dann ist das Projekt auch schon halb fertig.
Der Reihe nach:
Exportieren der Blog Posts
Um den Bestand an Blog Posts aus WordPress in Markdown-Dateien zu exportieren, habe ich das Plugin QH Markdown Exporter verwendet.
Der exportiert brav alle Posts in eine ZIP-Datei und stellt sie zum Download bereit.
Grobe Nachsorge
Die ZIP-Datei packe ich in ein eigene Verzeichnis aus und schaue mir die erzeugten Dateinamen an. Die folgen dem Muster aus Jahr-Monat-Tag_Titel_mit_Leerzeichen.md . Das entspricht in etwa dem Namensformat, das BSSG verwendet, nur die Unterstriche müssen zu Bindestrichen werden. Das lässt sich auf MacOS mit der systemeigenen Umbenennen-Funktion leicht für alle ausgewählten Dateien erledigen.
In die Markdown-Dateien hat der Exporter Metadaten wie Veröffentlichungsdatum, Kategorien und Tags aus WordPress in einen YAML-Vorspann geschrieben, sogenannte Frontmatter. Das sieht z.B. für den ersten Eintrag in diesem Blog so aus:
---
title: "Natasha Bedingfield: Unwritten"
author:
- "[[Andreas Schödl]]"
published: 2004-11-01
created: 2026-09-02
description: "\"These Words\" ist die zweite ...
categories:
- "musik"
- "reconstructed"
word_count: 561
---
# Natasha Bedingfield: Unwritten
Felder wie title, author und description passen zu der BSSG Frontmatter. word_count kann weg, zusammen mit dem source, denn die wird es nach erfolgreicher Migration nicht mehr geben.
categories kennt BSSG (noch) nicht, und auch das Format für tags ist bei BSSG eine Komma-separierte Liste, keine YAML-Liste. Das sind diese 20%-Dinge, um die ich mich später kümmere.
Um einschätzen zu können, ob die Migration insgesamt funktioniert, muss ich aber an published und created ran. published ist das Original-Veröffentlichungdatum, created ist das Datum des Exports, und damit für Migrationszwecke unpassend.
Die Gegenstück in BSSG zu created und published sind näherungsweise date und lastmod und auf die benenne ich die mit einem Editor um, der ganze Verzeichnisse bearbeiten kann. Auf Windows ist das z.B. Notepad++, unter MacOS habe ich BBEdit.
Bleibt das Problem, dass created, jetzt date, auf dem Export-Datum steht. Da holen wir die Regechse aus dem Terrarium, tschuldigung, die Regular Expressions (RegEx) aus der Werkzeugkiste und ersetzen, wieder im BBEdit
lastmod: (.+)$\ndate: .+$
durch
lastmod: \1\ndate: \1
Ohne hier in die Details von RegEx gehen zu wollen: (.+) ist eine Capture Group, die das Datum hinter lastmod fängt und als Variable \1 für die Ersetzung verfügbar macht. Ich sorge hier also dafür, dass date und lastmod auf den gleichen Wert, wie gesagt das Original-Veröffentlichungsdatum von WordPress, gesetzt werden.
Das reicht für’s Erste, um die Blog Posts in der Original-Zeitlinie neu generieren zu können. Durch den identischen Aufbau des Dateipfads sollten werden sich durch die Migration die URLs nicht ändern. Was wichtig wäre, wenn ich Millionen von täglichen Besuchern hätte, die alle meine Posts in den Bookmarks hätten.
Die restlichen 20%
Wo gehobelt wird ... Was noch nicht migriert ist, sind die Bilder zu den Posts, das wird Handarbeit, aber überschaubar.
Und dann muss ich das gleiche nochmal für die Handvoll WordPress Pages machen. Die könnte ich zur Not auch von Hand rüberholen. Mal schauen.
Bilder URLs anpassen
Im Export stehen die URLs zu den Bildern komplett drin,
https://blog.inpc.de/wp-content/uploads/2024/05/IMG_9406.jpeg
und daraus muss
/images/2024/05/IMG_9406.jpeg
werden. Weil ich Cleverle den kompletten Medien-Ordner von WordPress ins images/ Verzeichnis von BSSG kopiert habe, muss ich am Ende der URL nichts anpassen. Also, alle Bilder-URLs von Hand in das Frontmatter image: Element einfügen und dann einmal global search & replace. So ähnlich bekommen auch die meisten Bilder in den Posts wieder die korrekte URL.
Wichtig dabei ist der führende Slash vor images, sonst passiert die Auflösung der Bild-URL relativ zur aktuellen Seite: /images
(wird fortgesetzt ...)