Ziel war es, nur noch Webseiten zu haben, die statisch sind. D. h. sie werden nicht mehr auf einem Server mit PHP dynamisch erstellt sondern Zuhause einmalig vorgebaut, hochgeladen und dann bekommt jeder Benutzer immer die selben Dateien.

Dadurch benötigt man weder eine Scriptsprache auf dem Server noch eine Datenank (was DokuWiki aber auch so nicht benötigt, da es mit Text-Dateien statt einer Datenbank arbeitet).

Hier beschreibe ich alle notwendigen Schritte, um aus einem aktuellen DokuWiki eine statische Website zu erstellen, die man dann sorglos auf jeden Webspace werfen kann.

Das Werkzeug meiner Wahl ist wget, mit dem man ganze Websites oder Teile davon herunterladen kann. Dieses habe ich schon in der Vergangenheit genutzt, um mein altes MediaWiki in den Ruhestand zu schicken.

Ziel eines archivierten Wikis

Ich wollte den aktuellen Zustand des Wikis komplett mit allen Themenbereichen in einem Paket haben. Auch mit den Themenbereichen, die bereits im neuen Wiki enthalten sind. Damit die Informationen nicht doppelt vorhanden sind, sollten Weiterleitungen eingerichtet werden, sodass man beim “Öffnen/Anklicken” solcher Themenbereiche automatisch im neuen Wiki landet.

Das hat unter anderem den Hintergrund, dass man sehr einfach noch an die umgezogenen Themenbereiche dran kommt. Hätte ich sie im Wiki gelöscht, wären sie auch nicht mehr in der Sidebar links zu sehen.

Zudem besteht so die Möglichkeit, dass man das komplette archivierte Wiki weitergeben kann oder lokal zur Verfügung stellen. Als Archiv halt.

Vorbereitungen am Wiki vor dem Herunterladen mit wget

Damit später im archivierten Wiki möglichst selten 404-Fehlermeldungn erscheinen, habe ich alles deatkviert, was man nicht benötigt und/oder was ohne PHP nicht mehr funktionieren würde.

Deaktivierte ‘Aktionen’ von DokuWiki

In der Konfiguration von DokuWiki ist es möglich, bestimmte Aktionen zu deaktivieren. Einige davon waren bereits zuvor deaktiviert, ich habe dann noch alle anderen deaktiviert:

• Übersicht
• “Letzte Änderungen”
• “Links hierher”
• “Benutzerprofil”
• “Suche”, da sie PHP benötigt.
• “Setze neues Passwort”.
• “Diese Seite bearbeiten”
• Medien-Manager – Bei “Andere Aktionen (durch Komma getrennt)” media eingeben. Beim Aufruf von /start?do=media&ns= erscheint die Fehlermeldung Action disabled: media. Das hätte ich schon vor Jahren machen können, hätte ich es gewusst. Denn das war ein Bereich, der dauernd von Bots abgefragt wurde.

Indexmenü ohne Javascript

Ich habe das Indexmenu für die Sidebar (links) (Seitenname /wiki/sidebar) auf nojs umgestellt, damit kein JavaScript verwendet wird. Aus {{indexmenu>..#1|js#indextheme navbar tsort nsort notoc noscroll nocookie}} wird {{indexmenu>..#1|nojs#indextheme navbar tsort nsort notoc}}. Die Dokumentation dazu gibt es hier.

Die Liste der obersten Ebenen reicht in der Sidebar völlig aus, denn in jedem Namensraum ist am Ender der Startseite schon ein Indexmenü eingefügt, sodass man auf alle Seiten dort zugreifen kann. Zudem wird die Sidebar geöffnet dargestellt, sobald man sich auf einer Seite in einem der Unterbereiche befindet.

Weitere Änderungen

• DokuWiki-eigene Topbar-Seite gelöscht.
• Translation Plugin deaktiviert, da es sonst Links gibt auf z. B. start?id=linux/pulseaudio. Das wäre dann komplizierter geworden mit den ganzen Weiterleitungen (siehe unten) und es sind nur ein paar wenige Seiten in englischer Sprache in meinem Wiki (die ich später ins neue verschieben werde).
• Alle Benutzer außer Admin gelöscht
• Die Seite /wiki/syntax gelöscht. Die ist in jedem DokuWiki “vorinstalliert”.
• Namensraum en (English) aus dem Indexmenu ausgeschlossen.
• Startseite angepasst mit der Information, dass das Wiki archiviert wurde und nun statisch ist.

Es geht los – Wiki mit wget herunterladen

Während des Herunterladens habe ich sämtliche Weiterleitungen auf das neue Wiki temporär deaktiviert. Denn ich wollte das gesamte alte Wiki haben und nicht schon teiweise das neue.

Der Aufruf von wget zum Herunterladen des Wikis:

wget --recursive --no-clobber --page-requisites --html-extension --convert-links --restrict-file-names=unix --no-parent --reject-regex 'do=' --domains wiki.natenom.de https://wiki.natenom.de

-erobots=off

Ich habe das direkt auf dem Server ausgeführt, auf dem das Wiki läuft. Es hat circa 2 Minuten gedauert.

Die Befehlszeile habe ich von hier und die war hier verlinkt.

Zusätzlich habe ich noch die Sitemap heruntergeladen, die mit oberem Befehl nicht heruntergeladen wird:

wget https://wiki.natenom.de/sitemap.xml.gz

Wieso, weshalb, warum

• Man könnte --reject-regex noch erweitern mit 'do=|feed.php'. Ich möchte aber alle Feeds behalten, denn so kann man sehen, wenn man diese abonniert hat, dass es im Wiki nicht weiter geht. Und Programme und Suchmaschinen mögen es generell nicht, wenn Dateien plötzlich verschwinden. Dann lieber lassen und nichts neues eintragen.
• Dass URLs mit dem Parameter ?do= gefiltert werden, ist sinnvoll, weil man sonst zu jeder html-Datei noch einige weitere abc.html?do=def erhält. Z. B. für die Anmeldung, den Medien-Manager und einiges mehr. Hier der Unterschied zwischen einem Download mit wget mit --reject-regex 'do=' (links) und ohne (rechts):

  

DokuWiki durch statische Website ersetzen

Dann war der Zeitpunkt gekommen, das noch laufende DokuWiki durch das heruntergeladene archivierte Wiki zu ersetzen.

Das eine fliegt aus dem Webserver-Verzeichnis raus, das andere kommt rein. Dazu habe ich dann noch die zuvor heruntergeladene Sitemap hineinkopiert.

Backups sind immer wichtig, falls man doch noch mal an irgendwelche Dinge dran müsste.

Nacharbeiten in der Konfiguration des Webservers

Die Konfiguration des Webservers kann man nach dem Umzug deutlich vereinfachen, da nur noch das ausgeliefert wird, was auf dem Server liegt, ohne von PHP verarbeitet werden zu müssen. Darauf gehe ich hier nicht ein sondern werde nur ein paar Dinge nennen, die man ändern muss.

Mime Types wegen ‘Cache’-Anhang in Dateinamen

Da ein Dokuwiki einen Cachingmechanismus hat, werden einie Dateien, z. B. Bilder, je nach Art der Einbindung, mit ?cache= am Ende referenziert und beim Herunterladen entsprechend von wget benannt. Z. B. wird aus /url/zu/bild.jpg /url/zu/bild.jpg?cache=.

Klickt man auf eine solch referenzierte Datei, dann bietet der Webserver diese zum Download an, statt sie im Browser anzuzeigen. Das liegt daran, dass der Webserver nichts mit dieser “Dateiendung” anfangen kann.

Deshalb muss man dem Webserver mitteilen, was sich hinter diesen Endungen verbirgt. Das geht mit der folgenden Konfiguration: ¹

    location ~ \.jpg\?cache= {
        types { }
        default_type image/jpeg;
    }
    location ~ \.png\?cache= {
        types { }
        default_type image/png;
    }

Jetzt zusätzlich Auch auch .html am Ende achten

Die mit wget heruntergeladenen Dateien haben alle eine .html-Dateierweiterung bekommen. D. h. aus der vorherigen URL /android/ wurde /android.html.

Damit aber z. B. Links von extern noch richtig funkionieren, die ja auf /android/ verweisen, muss der Webserver angewiesen werden nicht nur auf /android/ zu prüfen, sondern auch auf /android.html und dann das Gefundene nutzen. Daher muss das in die config für das alte Wiki (wiki.natenom.de) das hier hinein:

    location / ...
        try_files $uri $uri.html $uri/ =404;

Der Webserver prüft also auf android, android.html und /android/ und gibt erst 404 zurück, wenn nichts davon gefunden wird.

Weiterleitungen mit .html auch am Ziel beachten

Da viele Inhalte meines alten Wikis schon in meinem neuen Wiki (wiki.natenom.com) enhalten sind und ensprechend verlinkt werden, musste ich auch dort noch die Konfiguration des Webservers anpassen.

Ich leite nach folgendem Muster von meinem alten Wiki ins neue Wiki weiter:

rewrite ^/android(.*)$ https://wiki.natenom.de/docs/android$1 redirect;

Das bedeutet, dass z. B. ein weitergeleitetes https://wiki.natenom.de/android im neuen Wiki wiki.natenom.com/ sowohl in der Form /android als auch in der Form /android.html ankommen kann. Damit letztere Form im neuen Wiki keine 404 verursacht, kann man den Webserver anweisen, die Dateiendung immer zu entfernen:

    location / {
        if ($request_uri ~ ^/(.*)\.html) {
            return 302 /$1;
        }
    }

Somit landen alle Formen der Weiterleitung am richtigen Ziel:

• /android -> wiki.natenom.com/android
• /android.html -> wiki.natenom.com/android.

Aufräumarbeiten

Dafür habe ich in den letzten Wochen und Monaten immer wieder sehr viel Arbeit investiert. Und nun war es endich soweit. Alle meine Webseiten waren statisch und so konnte ich (nachdem ich schon vor Monaten MySQL deinstallieren konnte, weil der Blog statisch wurde) endlich auch PHP von meinem Server deinstallieren:

systemctl stop php7.3-fpm
systemctl disable php7.3-fpm

apt remove --purge php*

php php-common php-fpm php-gd php-imagick php-mbstring php-sqlite3 php-xml php-zip php7.3 php7.3-cli php7.3-common php7.3-curl php7.3-fpm php7.3-gd php7.3-json php7.3-mbstring php7.3-opcache php7.3-readline php7.3-sqlite3 php7.3-xml php7.3-zip

Fertig 🙂

Hier das Ergebnis: Mein archiviertes Wiki, das jetzt auf wiki.natenom.de liegt.

Update: Jemand hat per E-Mail angemerkt, dass WordPress zwar mehr Anforderungen habe, dafür aber auch mehr Funktionalität wie Login oder Teamfähigkeit (die ich aber auch nicht benötige). Das ist richtig. :)

Ich habe Anfang Februar 2022 diesen Blog hier von WordPress auf Hugo umgestellt. Ich lasse hier mal die Liste der Vorteile stehen, die sich dadurch für meine Infrastruktur ergeben haben, falls ich jemals wieder mit dem Gedanken spielen sollte, WordPress oder etwas Ähnliches wieder verwenden zu wollen. Was ich derzeit nicht tue :)

• MySQL-Server abschalten und deinstallieren. Habe sonst nur noch ein DokuWiki im Betrieb, das keine Datenbank benötigt, weil es mit Flat files arbeitet.
• Backup von MySQL-Server deaktivieren.
• Backup des Webverzeichnisses des Blogs deaktivieren. Schließlich liegt jetzt die komplette Seite in einem lokalen Git-Repository und wird nur auf den Server geworfen.
• Alle Zugangsdaten für den Blog verwerfen.
• Schutzvorrichtungen (Basic Auth) für verschiedene Webverzeichnisse des Blogs wie /wp-admin entfernt.
• Vereinfachung der Nginx Konfiguration, da der Webserver für den Blog nur noch statische Dateien ausliefern muss.
• Entfernen des Cronjobs, der alle 10 Minuten lief und dafür sorgte, dass geplante Blogbeiträge zuverlässig veröffentlicht wurden, auch dann, wenn gerade niemand im Blog unterwegs war.
• Im Newsreader konnte ich den Filter löschen, den ich vor Jahren angelegt hatte, um News über Sicherheitslücken in WordPress und in Plugins zu erhalten.

Hier im zweiten Teil geht es darum, für die Übergangszeit das übrig gebliebene HTML, das nicht zu Markdown konvertiert werden konnte, automatisiert so zu verändern, dass der Blog trotzdem ansehnlich ist, wenn auch noch nicht perfekt. Das hat den Vorteil, dass ich den Blog mit Hugo bereits aktiv nutzen kann und nicht im Hintergrund erst alles auf manuell auf Markdown umstellen musste.

Es wird nicht ganz so viel werden, wie im ersten Teil.

Übrig gebliebenes HTML schön machen

Wie bereits erwähnt enthalten viele exportiere Beiträge noch einiges an HTML-Quelltext, der vom Export-Tool nicht in Markdown umgewandelt werden konnte. Und ich werde noch eine Weile mit diesem HTML Code leben müssen, bis ich es irgendwann geschafft habe, alles in sinnvolles Markdown zu übersetzen.

Ich wollte aber schon vorher den neuen Blog mit Hugo veröffentlichen. Deshalb war es notwendig, dass ich diesen bestehenden HTML Code soweit schön mache, dass es am besten gar nicht auffällt, dass die Quelle noch kein Markdown verwendet.

Nachfolgend werden die dafür notwendigen Anpassungen erläutert.

Wichtig: wp-content behalten

Damit nicht so gut wie alle Bilder und Fotos fehlen, die bisher nur über “alten” HTML-Code statt über Markdown eingebunden sind, habe ich eine Kopie des Verzeichnisses wp-content/uploads/ auch im Webverzeichnis der neuen statischen Webseite eingebunden. So funktionieren alle bisherigen Verlinkungen und Einbettungen weiterhin.

Mit der Zeit werde ich alle Galerien im Blog so umschreiben, dass die Page Bundles benutzen, d. h. die Bilder für einen Beitrag sind zusammen mit dem Beitrag selbst in einem eigenen Verzeichnis.

Verzerrte Fotos in Galerien

In einigen der Galerien wurden die Fotos noch in WordPress mit width=“2000” und height=“xxx” eingebunden. Das führte dazu, dass sie im neuen Hugo-Theme aufgrund der fehlenden Breite, oder weshalb auch immer, gestaucht angezeigt werden.

Daher habe ich die beiden Tags komplett entfernt mit:

sed -i -E -e 's/ width="[0-9]{1,4}"//g' *.md
sed -i -E -e 's/ height="[0-9]{1,4}"//g' *.md

Diese Zeilen entfernen natürlich alle Vorkommen von width und height. Soweit ich gesehen habe, bleiben diese Tags nach dem Export aus WordPress aber wirklich nur bei Bildern und vermutlich auch bei Videos erhalten.

Unscharfe Fotos – Zu klein wird zu groß angezeigt

In anderen Blogbeiträgen gab und gibt es immer noch unscharfe Fotos. Das liegt daran, dass diese Bilder in WordPress als kleine Vorschaubilder angezeigt wurden und bei einem Klick darauf die großen Varianten der Bilder in voller Auflösung in einer Lightbox geföffnet wurden.

So sah der Beitrag ursprünglich in WordPress aus:

Erste Möglichkeit bei unscharfen Bildern: Lightbox benutzen

Die verwendete Lightbox öffnet im Overlay nicht die kleine Datei sondern die verlinkte, große Datei. In der Lightbox ist das Bild somit scharf.

So sieht es dann aus:

In Hugo werden nur noch diese kleinen Bilder in viel zu groß dargestellt. Dank einer verwendeten Lightbox werden zumindest beim Anklicken die Originalfotos in einem Overlay angezeigt und für die Übergangszeit reicht mir das so auch.

Für diese Lösung habe ich mich erst einmal entschieden.

Zweite Möglichkeit bei unscharfen Bildern: HTML automatisiert anpassen …

Man kann das Problem auch damit beheben, dass man den HTML-Quelltext so abändert, dass statt der kleinen Dateien überall die Originaldateien eingebunden werden, aber weiterhin auch verlinkt bleiben.

Damit wird z. B. statt dem eingebetteten Bild mumble-git-1-100x50.jpg das Bild mumble-git-1.jpg eingebunden. Nicht optimal, da es aus sein kann, dass ein riesiges Originalfoto von einer Landschaft dann relativ klein angezeigt wird. Öffnet man einen Blogbeitrag mit einer Galerie von Landschaftsfotos, dann sieht man zwar nur kleine Bilder, der Browser lädt dann aber direkt alle Bilder in voller Auflösung herunter.

Deshalb habe ich mich gegen diese Lösung entschieden, obwohl sie am besten aussieht.

Hier trotzdem die Befehlszeile(n), um die URLs der kleinen Varianten der Bilder gegen die Originale zu ersetzen:

sed -i -E -e 's#-[0-9]{1,4}x[0-9]{1,4}\.jpg#\.jpg#g' *.md
sed -i -E -e 's#-[0-9]{1,4}x[0-9]{1,4}\.png#\.png#g' *.md
sed -i -E -e 's#-[0-9]{1,4}x[0-9]{1,4}\.gif#\.gif#g' *.md

Natürlich muss man diese Zeilen für die verwendeten Dateitypen anpassen (png, gif, …).

Das Ergebnis wäre dann:

srcsets entfernen

Um zusätzlich noch die srcsets aus solchen Galerien zu entfernen, kann man diese Zeile ausführen:

sed -i -E -e 's# class=".*;" />#/>#g' *.md

Ich habe das erst einmal sein lassen. Vielleicht schaffe ich es ja noch, dass diese srcsets doch noch genutzt werden, solange ich noch nicht alles auf Markdown umgewandelt habe.

Eingebettete Videos werden zu breit dargestellt

Mit dem video-Tag eingebundene Videos sind im Theme so breit, dass sie teilweise hinter dem rechten Seitenpanel versteckt sind.

Um das zu heben, habe ich erstmal ein bisschen css verwendet:

video {
  max-width: 100%;
  height: auto;
}

Damit werden alle Videoeinbettungen, auch die, die ich später mit Markdown verwenden werde, richtig angezeigt.

Später werde ich den HTML Code durch einen Shortcode video ersetzen.

Artikelbilder

In den WordPress-Themes, die ich bisher verwendet hatte, gab es immer Artikelbilder. Ich finde das sehr schön, weil es meiner Ansicht nach auflockernd wirkt und man besser erkennt, worum es in einem Blogbeitrag gehen könnte. Deshalb fand ich es schade, als ich bemerkte, dass in meinem ausgewählten Theme keine Artikelbilder zu sehen waren.

Ich habe dann selbst versucht Artikelbilder zu implementieren und dabei dann entdeckt, dass das Theme solche durchaus vorsieht und nur die richtigen Angaben im Front Matter fehlten.

Dank des Exports von WordPress landeten im Frontmatter bei immerhin ca. 1900 von 2460 Beiträgen die Angaben zu Artikelbildern im Stil von:

featured_image: dateiname.jpg

Doch das Hugo Theme erwartet die folgende Struktur:

images:
  - dateiname.jpg

Kein Problem, denn mit dem Streamingeditor sed unter Linux ist das mit einem Befehl erleidgt:

sed -i -E -e 's/^featured_image: (.*)$/images:\n  - \1/' *.md

Seitdem werden, wie auch im WordPress zuvor, Artikelbilder auch im mit Hugo generierten Blog angezeigt.

Reicht wieder

Das reicht auch schon für den zweiten Teil.

Im nächsten Teil geht es dann um Lightboxen, Kommentare, um verschiedene Konfigurationsmöglichkeiten und mehr.

Hier berichte ich davon, wie genau ich das gemacht habe, was es zu bedenken galt und wie es im Ergebnis geworden ist. In erster Linie ist es für mich als Dokumentation gedacht, damit ich das in x Zeit noch nachvollziehen kann. Und wenn jemand anderes damit auch noch etwas anfangen kann, dann ist es noch besser.

Dabei schreibe ich übrigens das erste Mal einen Blogbeitrag mit einem einfachen Editor, offline, ohne Browser, in einem einfachen Textbearbeitungsprogramm. Und das fühlt sich gut an.

Wieso überhaupt weg von WordPress?

Ich habe WordPress seit 2009 für meinen Blog benutzt und es immer auf eigenen Servern selbst gehostet. Ich war immer sehr zufrieden damit. WordPress hat es mir ermöglicht, mich immer nur auf den Inhalt konzentrieren zu können und hat mir die ganze Arbeit drumherum abgenommen. Und es ist immer noch so. Das schätze ich an dem Content Management System WordPress. Jedes Upgrade auf eine neue Version war immer fehlerfrei mit nur wenigen Klicks möglich.

Die meisten Funktionen von WordPress habe ich nie benutzt. Und mit dem Update auf den Gutenberg-Editor und jetzt kürzlich auf 5.9 mit dem Super Feature “Full Site Editing” ist noch klarer geworden, dass ich solch ein komplexes System nicht benötige. Es ist immer noch sehr einfach zu bedienen und zu aktualisieren, aber ich brauche es eben nicht.

Was ich brauche, ist eine einfache Möglichkeit, Texte zu schreiben, die Maus möglichst nicht bewegen zu müssen und außerdem benötige ich nur die grundlegensten Formatierungen. Kurzum das, was Markdown bietet.

Natürlich sind da noch andere Aspekte:

• Wartbarkeit: Webserver, PHP, Datenbank, alles will gepflegt werden und benötigt ab und zu Aufmerksamkeit. Mit Hugo kann man den kompletten Blog, der aus statischen Dateien (HTML, CSS, JavaScript) besteht, auf einen Webserver werfen und für immer dort liegen lassen.
• Portierbarkeit/Backup: Sollte ich mal vom Rad fallen und nicht mehr aufstehen, kann man sich das Archiv herunterladen und hat weiterhin Zugriff auf die Inhalte des Blogs. Entsprechend wird man sich später das einmal alle x Zeit aktualisierte Archiv herunterladen können. Dazu später mehr.
• Sicherheit: Da nichts dynamisch ausgeführt wird, gibt es auch keine Sicherheitslücken, die jemand ausnutzen könnte.
• “Einfachheit”: Text-Editor, Hugo laufen lassen, hochladen per SFTP. Fertig.

Ein schönes Theme für Hugo finden

Man kann natürlich auch selbst ein Theme bauen, aber das ist nichts für mich.

Eine Liste von aktuell 285 Themes gibt es auf der Webseite von Hugo, siehe hier.

Ich habe mich für das Theme Bootstrap Theme for Personal Blog and Documentations entschieden, weil es fast alles liefert, was ich benötige und vielfältige Einstellungsmöglichkeiten hat.

Was ich besonders mag:

• Dark Mode/Light Mode
• Suchfunktion (fuse.js)
• Durch Ausblenden der Seitenliste kann der Inhaltsbereich breiter gemacht werden.
• Es gibt bereits Shortcodes für Nachrichtenboxen (Info, Alarm, …). Siehe hier.
• Twitter Cards und Open Graph
• Responsive
• optional mehrsprachig
• Archivseiten
• Shortcods für Verleinern von Bildern. Die verkleinerten Bilder werden beim Rendern von Hugo aus den Originaldateien erzeugt.
• Lazy loading für Bilder
• Inhaltsverzeichnis für Blogbeiträge
• Keine Einbindung von externen Inhalten
• Liste von “ähnlichen Beiträgen”

Vor dem Export in WordPress aufräumen

Tabellen aufräumen

Vor dem Export der Daten kann man den Blog noch etwas aufräumen. Hat man z. B. wie ich über die Jahre viele verschiedene Plugins ausprobiert und wieder entfernt, dann könnten die Daten der Plugins immer noch irgendwo in den Tabellen der Datenbank liegen und beim Export in den Daten landen. Das wären alles zusätzliche Daten, die man nicht benötigt.

Dazu hatte ich mal einen eigenen Blogbeitrag verfasst, siehe hier.

Entwürfe

Werden Entwürfe exportiert, dann erhalten diese in der exportierten Version kein Datum und sind somit erstmal aus dem Sichtbereich raus oder bekommen seltsame Namen/URLs zugewiesen wie z. B. “?p=52696/”, das der fortlaufenden ID von Blogbeiträgen entspricht. Das will man später alles nicht einzeln bearbeiten müssen. Deshalb Entwürfe löschen oder veröffentlichen.

Verlinkungen in WordPress

Man kann in WordPress entweder die komplette URL verwenden (Standard), um auf einen Beitrag im eigenen Blog zu verlinken oder die ID des Beitrags verwenden.

Die komplette URL wäre z. B. “natenom.de/2021/01/beitrag-ueber-den-kleinen-elefanten” während die ID “natenom.de/?p=12345” wäre.

Solche Verlinkungen sollte man noch im laufenden WordPress Blog finden und in die erste Form (lange URL) überführen, da die zweite Form mit der ID in Hugo nicht funktionieren wird.

Dazu reicht die Suchfunktion im Adminpanel aus. Man sucht nach “/?p=”. In meinem Fall fanden sich ca. 130 solcher Beiträge mit ID Verlinkungen.

(optional) Backup des Blogs – Für Hugo nicht relevant

Da der Blog am Ende abgeschaltet werden soll, habe ich ein letztes Mal Backups gemacht:

• Backup der WordPress Datenbank
• Als Admin in WordPress angemeldet und unter Werkzeuge -> Daten exportieren -> Alle Inhalte ausgewählt und die xml-Datei heruntergeladen. In dieser Datei sind alle Beiträge, alle Seiten und auch die Kommentare von Benutzern enthalten. Nicht jedoch die hochgeladenen Dateien. In meinem Fall ist die Datei um 50 MiB groß und hat um die 50000 Zeilen.
• Backup des kompletten WordPress-Verzeichnisses inklusive den hochgeladenen Dateien und dem ganzen PHP-Zeug
• Herunterladen der kompletten Webseite mit wget, um später noch nachvollziehen zu können, unter welchen URLs was zu finden war. Für solche URLs, die Hugo nicht generiert. Die könnte man dann mit einem Webserver passend weiterleiten. Die Kommandozeile dafür ist:

wget --recursive --domains=natenom.de --html-extension --page-requisites --convert-links --no-parent "/" -R "*xmlrpc*" --reject-regex ".*wp-content.*"

-erobots=off

Das Verzeichnis wp-content habe ich bewusst ausgelassen, da es nur hochgeladene Dateien enthält (ca. 7 GiB), die bereits in einem anderen Backup enthalten sind.

Daten für Hugo aus WordPress exportieren

Mit dem Tool WordPress to Hugo Exporter kann man alle Seiten und Beiträg eines Blogs in eine Zip-Datei exportieren.

Ich gehe hier nicht darauf ein, wie man das Tool verwendet, da das ausreichend gut auf dessen Webseite erklärt ist. Wichtig ist hier nur, dass man am Ende eine Datei erhält, hier im Beispiel mit dem Namen wpexport.zip.

Auf der Projektseite steht, was man an der PHP-Datei anpassen muss, damit auch Kommentare exportiert werden.

Der Export kann eine ganze Weile dauern und sollte deshalb auf der Kommandozeile ausgeführt werden. Die wpexport.zip meines Blogs hatte eine Dateigröße von etwas mehr als 7 GiB.

Die Datei wpexport.zip hat diese Struktur:

seite-a/index.md
seite-b/index.md
irgendeine-seite/index.md
posts/
    2022-01-05-mein-beitrag-im-januar
    2022-01-06-mein-beitrag-ueber-bluemeleinchen
    2022-02-08-ein-neuer-beitrag-mit-tollen-fahrraedern
wp-content/
    uploads/
        2022/
            01/
                2022-01-04-hochgeladenes-bild-1.jpg
                2022-01-04-hochgeladenes-bild-2.jpg
config.yaml

• Es sind alle “Seiten” des Blogs als Verzeichnisse enthalten, in den index.md-Dateien sind die Inhalte.
• Die “Beiträge” (Englisch “Posts”) liegen als md-Dateien im Verzeichnis “posts”.
• Die hochgeladenen Dateien wie Fotos, Screenshots oder auch Audio und Video liegen im Verzeichnis wp-content/uploads, sortiert nach Jahr und Monat.
• Dann gibt es noch die Datei config.yaml, welche die URL des Blogs enthält, den Namen und die Beschreibung.

Die Daten lädt man dann auf den eigenen PC herunter.

Eine Webseite mit Hugo anlegen und Theme einfügen

Ich will hier nicht darauf eingehen, wie man eine Webseite mit Hugo anlegt und das Theme einfügt, das ist auf der Projektseite bereits ausführlich gut dokumentiert, siehe hier.

Sobald das erledigt und das Theme eingebunden ist, kann man die exportierten Daten aus dem heruntergeladenen Archiv entpacken und die Daten in das Verzeichnis des neuen Blogs hineinkopieren:

• Die Datei config.yaml habe ich weg gelassen.
• Das Verzeichnis posts wird nach content kopiert.
• Das Verzeichnisse seite-x werden nach content/pages kopiert.
• Das Verzeichnis wp-content wird nach static kopiert.

Ein bisschen Konfiguration

Eine Liste aller Einstellungsmöglichkeiten gibt es auf der Seite des Theme-Entwicklers.

Taxonomie

Bei der Taxonomie wollte ich die URLs von WordPress möglichst erhalten.

Per Voreinstellung verwendet Hugo für tags in der URL “tags”, WordPress jedoch “tag”. Bei Kategorien verwendet Hugo “categories” und WordPress “category”.

Das kann man in der config.toml anpassen mit:

[taxonomies]
  category = 'category'
  tag = 'tag'

In meinem ausgewählten Theme funktioniert das jedoch leider nicht, da zwingend “tags” und “categories” notwendig sind. Kann man sicher anpassen, ich aber nicht. Also bleibt es bei den Voreinstellungen. Ich werde es dann einfach mit dem Webserver weiterleiten lassen.

In Nginx z. B. mit:

rewrite ^/tag/(.*)$ /tags/$1 redirect;
rewrite ^/category/(.*)$ /categories/$1 redirect;

Wenn das gut funktioniert, kann man das später auf permanent umschreiben.

Beiträge nicht gelistet

Auf der Startseite des Blogs wurden die Beiträge nicht gelistet. Mit Herumprobieren konnte ich herausfinden, dass das an dem Eintrag “type: post” im Front Matter (Metadaten eines Beitrags) lag. Daher habe ich mit dem folgenden Shell-Aufruf diese Zeile in allen md-Dateien gelöscht:

sed -i "/^type: post$/d" *.md

Sonstige Konfiguration

Hier noch ein paar weitere wichtige Dinge, die ich in der Konfiguration eingestellt habe.

[…]
baseURL = "/"
rssLimit = 15
[…]
[params]
comment = false
breadcrumb = true
palette = "blue"
dateFormat = "Mon, 02 Jan 2006 15:04"
mainSections = ["posts", "pages" ]
poweredBy = false
math = false
diagram = false
logo = false
description = " Verkehrswende, Fahrrad, CriticalMass, OpenBikeSensor, SimRa, Mumble, Open Source, Minimalist, OpenStreetMap, Müllsammeln"
recentPostCount = 5
relatedPostCount = 6
categoryCount = 200
tagCount = 150
searchBar = true
post.copyright = false
search.fuse.threshold = 0.0
countTaxonomyPosts = true
post.excerpt = "description"
viewer = false
showShare = false
socialShare = false

[outputs]
  home = ["HTML", "RSS", "JSON"]

Von absoluten URLs zu relativen URLs

Ich habe keine Ahnung von SEO und habe mich nie damit beschäftigt. Könnte es sein, dass WordPress aus SEO-Gründen absoulte URLs verwendet und nicht realtive? Ich habe dazu die Info auf einer Webseite gefunden, dass relative Links problematisch werden könnten, wenn der Server nicht richtig eingerichtet sei.

Hat man Bedenken, dann weiter zum nächsten Abschnitt.

Aber: Will man den neuen Blog auf dem eigenen PC anschauen, benötigt man ohne die Veränderungen der URLs eine Internetverbindung, damit eingebettete Inhalte wie z. B. Bilder vom Browser von der ursprünglichen Webseite heruntergeladen werden können. Oder aber man biegt das DNS temporär um, muss dann aber zumindest aus https http machen, und so weiter.

Absolute URLs auf hochgeladene Dateien

Alle Verlinkungen auf Fotos, Bilder und Videos sind in WordPress mit der absoulten URL angegeben, in meinem Fall mit natenom.de/wp-content/uploads/.... Und das wird so auch in die md-Dateien exportiert.

Deshalb kann man die URLs mit dem Streameditor sed umschreiben lassen:

sed -i -E -e 's#/wp-content/uploads/#/wp-content/uploads/#g' *.md

(Ich habe das aktuell erstmal noch nicht getan.)

Das Kommando führt man in allen Verzeichnissen aus, in denen md-Dateien liegen. Man könnte das auch so umschreiben, dass es ausgehend vom neuen Blogverzeichnis alle md-Dateien findet und so alle erfasst. Aber so reicht es mir.

Absolute URLs auf Blogbeiträge

Das selbe gilt auch für Verlinkungen im Blogbeiträgen auf andere Beiträg im eigenen Blog. Auch diese URLs lasse ich umschreiben:

sed -i -E -e 's#/#/#g' *.md

(Ich habe das aktuell erstmal noch nicht getan.)

Aus dem absoulten Link / wird dadurch /.

Umlaute in URLs von Kategorien und Tags

Ich verwende im Blog das Tag “Müllsammeln” und die Kategorie “Mobilität”. Wordpress hat dabei automatisch die Umlaute in den dafür genutzten URLs in die alternativen Schreibweisen “muellsammeln” und “mobilitaet” umgewandelt. Hugo macht das nicht, weshalb dort das Tag auch “müllsammeln” lautet.

Es gibt mehrere Lösungen:

1. Es dabei belassen, denn mittlerweile sind diese Zeichen kein Problem mehr. Es sieht nur nicht sonderlich schön aus, wenn man statt mobilität das hier sieht mobilit%C3%A4t
2. Ohne Veränderungen an den Beiträgen wäre die Option removePathAccents von Hugo möglich, die aus “mobilität” “mobilitat” macht.
3. Hugo selbst zu verändern, siehe hier.
4. Alle Vorkommen der Tags in den Beiträgen mit sed umschreiben und ö durch oe ersetzen usw.
5. Weiterleitungen durch den Webserver, siehe unten.

Einen Issue mit vielen Informationen zu diesem Theme gibt es auf Github, siehe hier. Ein weitere Issue zu dem Thema ist seit November 2021 noch offen, siehe hier.

Ich habe mich entschieden, das so zu belassen das erst einmal mit Weiterleitungen zu “fixen” und zu schauen, was sich bei dem Issue tut.

In Nginx sind diese:

rewrite ^/tag/muellsammeln/(.*)$ /tags/müllsammeln/$1 redirect;
rewrite ^/category/mobilitaet/(.*)$ /categories/mobilität/$1 redirect;
rewrite ^/tag/(.*)$ /tags/$1 redirect;
rewrite ^/category/(.*)$ /categories/$1 redirect;

Ich nutze bei solchen Dingen am Anfang immer erst redirect, was dem HTTP Status 302 entspricht und ändere das dann irgendwann zu permanent (Status 301) um.

Fehlerseite für 404

Falls doch mal eine Seite nicht gefunden wird, habe ich die 404.html in Nginx eingerichtet:

error_page 404 /404.html;

Hier kann man die Seite mal ansehen: Dieser Link zeigt auf eine nicht vorhandene Seite.

Damit erstmal keine Inhalte fehlen

Würde man jetzt schon Hugo starten, würden vermutlich viele Inhalte in verschiedenen Beiträgen fehlen. Das liegt daran, dass das oben genannte Export-Tool viele HTML Tags nicht in Markdown konvertieren kann und dann an diesen Stellen den HTML-Quelltext in die exportierten md-Dateien schreibt. Doch Hugo filtert diesen HTML-Quelltext beim Rendern der Website heraus.

Damit ich nicht erst alle 2560 Blogbeiträge manuell überprüfen und korrigieren muss, bevor ich den neuen Blog öffentlich machen kann, habe ich mich entschieden, dieses Verhalten von Hugo umzustellen und Hugo anzuweisen, den HTML-Quelltext nicht herauszufiltern. Das ist zwar nicht im Sinne des Erfinders aber so habe ich die Möglichkeit, die Arbeit auf irgendwann später zu verschieben.

Details dazu findet man hier. Suche nach unsafe.

In die config.toml fügt man dazu Folgendes ein:

[markup]
  [markup.goldmark]
    [markup.goldmark.renderer]
      unsafe = true

Run Hugo, Run

Jetzt kann man Hugo veranlassen, den neuen Blog das erste Mal zu rendern und dann lokal zur Verfügung zu stellen. Per Voreinstellung ist er unter localhost:1313 erreichbar.

Dazu wechselt man auf der Kommandozeile in das Verzeichnis des neuen Blogs und führt aus:

hugo server --renderToDisk -D -E -F -v

Jetzt werden alle gerenderten Dateien und auch die aus dem static-Verzeichnis in das Verzeichnis public kopiert, welches Hugo automatisch erstellt, wenn es noch nicht existiert.

Sobald alles bereit ist, gibt es eine Meldung wie etwa:

                   |  DE   
-------------------+-------
  Pages            | 4350  
  Paginator pages  | 1694  
  Non-page files   |    1  
  Static files     |   88  
  Processed images |    0  
  Aliases          |  889  
  Sitemaps         |    1  
  Cleaned          |    0  

Built in 45228 ms
Watching for changes in /home/natenom-web-hugo/{assets,content,layouts,static,themes}
Watching for config changes in /home/natenom-web-hugo/config.toml, […]
Environment: "development"
Serving pages from /home/natenom-web-hugo/public
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

Erstmal fertig

Das reicht dann auch wieder für diesen Beitrag. Man kann jetzt schon im eigenen Blog offline umgucken und wird hier und da noch unschöne Dinge finden, wie falsch dargestellte Bilder.

In Teil 2 geht es darum, für die Übergangszeit das übrig gebliebene HTML, das nicht zu Markdown konvertiert werden konnte, automatisiert so zu verändern, dass der Blog trotzdem ansehnlich ist, wenn auch noch nicht perfekt.

Diese kann man entweder manuell löschen oder mit einem WordPress-Plugin, wie z. B. diesem hier.

Von einst 134 Dateien im Verzeichnis von MySQL sind nach dem Cleanup noch 18 übrig geblieben.

https://wiki.natenom.de/docs/sammelsurium/wordpress/datenbank_aufraeumen

Ich habe ein lokales Wiki, für das ich meist nur dann den lokalen Webserver anwerfe, wenn ich eine Seite z. B. als PDF exportieren möchte oder die Informationen etwas „schöner“ angezeigt bekommen möchte.

Für alles andere starte ich einfach nur einen Texteditor, der mir die Verzeichnisstruktur anzeigen kann, und mit dem ich Zugriff auf alle Wikiseiten habe.

Dazu gesellt sich noch ein Dateimanager, damit ich auch Dateien in den entsprechenden Unterverzeichnisse im Wiki ablegen kann. Mit dem richtigen Pfad kann man diese auch in Wikiseiten einbetten.

Somit habe ich einen gut struktierten Ort für Notizen, Bookmarks, Erlebnisse und sonstige Informationen.

Vor vielen Jahren habe ich dafür übrigens basket von KDE benutzt. Dieses gibt es mittlerweile nicht mehr bzw. es wird nicht mehr entwickelt.

Aus Datenschutzgründen möchte ich einige dieser Daten entweder gar nicht erst in der Datenbank haben oder nachträglich löschen.

Das sind alle Felder der Tabelle wp_comments:

comment_ID 
comment_post_ID 
comment_author 
comment_author_email 
comment_author_url 
comment_author_IP 
comment_date 
comment_date_gmt 
comment_content 
comment_karma 
comment_approved 
comment_agent 
comment_type 
comment_parent 
user_id 
comment_subscribe_optin 
comment_subscribe_optin_verified
comment_subscribe_optin_mailed

Bei den letzten dreien bin ich nicht sicher, ob sie in einer Standard-Installation von WordPress enthalten sind oder von einem installierten Plugin stammen.

Damit die IP gar nicht erst in der Datenbank landet, könnte man sich noch ein WordPress-Plugin installieren. Oder aber man löscht die Daten nach einem Zeitraum X direkt über SQL aus der Datenbank.

Ich habe mich für Letzeres entschieden. In meinem Wiki gibt es dazu eine Beschreibung, siehe hier.

Die Beschreibung findet sich im Wiki von Etherpad-lite.