Der eigentliche Export der Beiträge aus der WordPress-Datenbank wurde mit Hilfe eines Perl-Skripts realisiert, welches speziell für diesen Zweck geschrieben wurde. Das Hauptaugenmerk lag hierbei auf einen möglichst “passenden” Export und nicht auf schönen oder wiederverwendbarem Code.

Zur Ablage der Beiträge wurden im “content”-Ordner zwei Unterordner angelegt: im Ordner “page” landeten die Seiten der Website, im Ordner “post” die Beiträge.

Damit die in WordPress vorhandene Kategoriestruktur und somit auch die Permalinks erhalten blieben, wurde die Kategorie-Struktur unterhalb des “post”-Ordners nachgebildet, d.h. für den Beitrag “https://blog.thul.org/musik/audio/pink-floyd-the-final-cut/” der Ordner “content/post/musik/audio/pink-floyd-the-final-cut/” erzeugt und der Beitragsinhalt in diesem in der Datei “index.html” abgelegt.

Für die wenigen Seiten der WordPress-Instanz wurde eine flache Hierarchie gewählt, d.h. der Beitrag “https://blog.thul.org/impressum/” wurde in den Ordner “content/page/impressum” kopiert.

Weiterlesen

Im Laufe der rund 25 Jahre, die ich im World Wide Web aktiv bin, wurden verschiedene Systeme zum Verwalten und zur Anzeige meiner Webpräsenzen eingesetzt:

Allererste Gehversuche wurden anfangs mit “handgemachtem HTML” unter der Domain “shadowfire.de” mit dem Editor HTML-Editor Phase 5 durchgeführt, bevor unter dem klangvollen Namen “shadowCMS” ein selbstentwickeltes Content Management System auf Perl-Basis in Betrieb genommen wurde. Auf Dauer war das direkte Erstellen und Bearbeiten von Beiträgen in der Datenbank aber mehr als lästig (und ich fand nie die Motivation, ein brauchbares Backend zu entwickeln) und so sah Joomla! nach einem vielversprechenden Ersatz aus.

Jahre später erfolgte dann die Umstellung von einer klassischen Website in ein Blog. Hier gab es ein kurzes Kopf-an-Kopf-Rennen zwischen Serendipity und WordPress, welches letztendlich von WordPress für sich entschieden wurde. Mit dieser Umstellung wurde ein Großteil der vorhandenen Beiträge in Form eines Blogs serialisiert und es änderten sich zum bisher letzten Mal die nach außen verwendeten URLs.

Im Laufe der letzten Jahre haben sich meine Bedürfnisse und WordPress immer mehr auseinanderentwickelt, weshalb nach reiflicher Überlegung und Sichtung einiger Alternativen die Migtation auf Hugo anstand. Inhalte, URLs und Blog-Struktur sollten hierbei bis auf einige wenige Korrekturen übernommen werden.

Zum Zeitpunkt der Umstellung war das Blog auf 1.069 Artikel (1.065 Beiträge und 4 Seiten) und 739 Kommentare angewachsen, die alle zur Übernahme anstanden. Gleichzeitig mit der Umstellung sollte auch das 3.192 Dateien umfassende “Uploads”-Verzeichnis aufgeteilt und die zu einem Beitrag gehörenden Medien zusammen mit dem jeweiligen Beitrag in einem Ordner abgelegt werden.

Auf der Hugo-Website werden einige Migrationswerkzeuge gelistet, die aber alle das geplante Einsatzszenario nicht vollständig abdecken konnten. Auch die Idee, mittels z.B. “wget” ein Abbild der fertig gerenderten Website zu erzeugen und weiterzuverarbeiten, wurde als unpraktikabel verworfen.

Als effektivster Weg blieb das Auslesen der Beitragsinhalte und Kommentare direkt aus der WordPress-Datenbank. Dabei sollte auf jeden Fall ein Teil der WordPress-Ausgabefunktionalität wie z.B. wpautop() erhalten bleiben, so daß die einzelnen Beiträge im HTML-Format abgelegt identisch mit den von WordPress dargestellten Beiträgen sein sollten. Weiterhin sollten auch Sonderfälle wie z.B. die Bildergalerien berücksichtigt werden, welche mittels Resources-Einträgen und einem Gallery-Shortcode von Hugo neu erstellt werden sollten.

Deutlich erleichtert wurde die Umsetzung dadurch, daß in meiner WordPress-Instanz keinerlei fremde Plugins aktiv waren und auch die Struktur der Artikel (jeder Beitrag in exakt einer Kategorie, aber dafür mit beliebig vielen Tags versehen) den Export und die Ablage im Dateisystem deutlich erleichterte.

Ebenfalls nervenschonend war die Tatsache, daß nach einem kurzen Ausflug zur 5.x-Schiene WordPress wieder in der Version 4.19.x aktiv war und somit beim Umsetzen der Beiträge nicht auf neuere Gutenberg-Funktionalitäten und -Besonderheiten Rücksicht genommen werden musste.

Seitdem ich vor mehr als 10 Jahren von einer klassischen Website auf ein Blog umgestellt habe, war im Backend WordPress im Einsatz. Leider haben sich meine Bedürfnisse und WordPress in den letzten Jahren immer mehr auseinanderentwickelt, ein paar Gedanken hierzu habe ich im Beitrag “Gedanken aus dem Maschinenraum” festgehalten.

Dieser Beitrag ist nun der erste, der mit Hilfe eines neuen Backends erzeugt wurde. Die Wahl fiel auf Hugo, einen statischen Websitegenerator. Gerade im Hinblick auf die Tatsache, daß hier im Blog maximal 1-2 Beiträge pro Woche erscheinen, reicht es, wenn die Inhalte nicht bei jedem Aufruf einer Seite neu erzeugt werden, sondern eben nur dann, wenn sich am Inhalt auch tatsächlich etwas ändert.

Alle Beiträge wurden umgezogen und die URLs auch - bis auf einige wenige technisch begründete Ausnahmen - wie von WordPress vergeben beibehalten. Auch alle bisher abgegebenen Kommentare wurden übernommen und sind weiterhin den jeweiligen Beiträgen zu sehen, auch wenn aktuell Antworten nicht direkt als solche ersichtlich sind. Das Kontakt- und Kommentarformular sowie die Suche sehen leicht anders aus und sind der einzige dynamische Teil der Website. In hoffentlich nicht allzu ferner Zukunft wird noch ein detaillierter Blick auf die Migration und den Einstieg in Hugo erscheinen, dieser ist aber noch in Arbeit.

Sollte irgendwo noch irgendetwas klemmen, so bitte ich um entsprechende Nachricht.

Bei einer Aktualiserung schaltet WordPress die Website automatisch in den Wartungsmodus, ein Mechanismus, den man auch für manuelle Wartungen aktivieren kann.

Zum Aktivieren wird eine Datei “.maintenance” mit folgendem Inhalt im Hauptverzeichnis der WordPress-Installation angelegt, welche den Wartungsmodus bis zum Entfernen (oder Umbenennen der Datei) aktiviert.

Die Erklärung der Funktionsweise findet sich im WordPress-Quellcode innerhalb der Datei load.php

Im ersten Schritt wird das Vorhandensein einer Datei “.maintenance” im Hauptverzeichnis der WordPress-Installation geprüft. Ist diese vorhanden, so wird vom aktuellen Zeitstempel der Wert der Variablen “$upgrading” subtrahiert. Ist der Rest größer oder gleich 10 Minuten, so wird der Wartungsmodus deaktiviert.

Durch das Setzen der Variable “$upgrading” auf den aktuellen Zeitstempel bleibt die Differenz immer 0, die 10 Minuten werden nie überschritten und der Wartungsmodus kann manuell gesteuert werden.

Beim Lesen des Begrüßungstexts von WordPress 5.7 fühle ich mich in meinen Gedanken bestätigt:

Vielleicht liegt es aber auch nur an der unglücklichen Übersetzung des englischen Texts:

Jazz up your stories in an editor that’s cleaner, crisper, and does more to get out of your way.