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.

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.

Habe das damals lokal aufgesetzt und nutze es seitdem unverändert für Twitter, Google und Youtube.

Vor einiger Zeit habe ich RSS-Bridge auf die neuste Version aktualisiert und es gibt Unmengen mehr an Bridges, z. B. für:

Die vollständige Liste der Bridges gibt es auf der Projektseite, siehe hier.

Doch obwohl ich im Wiki nichts mehr gemacht hatte, musste ich mich doch immer wieder um Sicherheitsupdates für MediaWiki kümmern, auf dem dieses Wiki basiert.

Deshalb wollte ich schon mehrmals dieses Wiki mit Hilfe von wget herunterladen und dann als statische Version nur mit HTML-Dateien wieder hosten. Bei meinen letzten beiden Versuchen, das zu tun, bin ich immer an etwas gescheitert. Heute habe ich es endlich geschafft nach mehreren Stunden Arbeit und daher soll der Ablauf hier hinterlegt sein.

Ausgangspunkt war dieser Blogbeitrag. Jedoch musste ich den Aufruf für mein Wiki etwas anpassen und noch weitere Arbeiten erledigen.

Weiterleitungen temporär deaktivieren

Wichtig bezüglich meines Wikis ist hier der Punkt, dass ich früher bereits viele Seiten manuell in mein Dokuwiki verschoben und auch entsprechende 301-Weiterleitungen gesetzt habe. Deshalb habe ich diese Weiterleitungen temporär entfernt und dann erst die Seite heruntergeladen.

Man könnte sie auch aktiv lassen und stattdessen noch bei wget diesen Parameter nutzen:

--max-redirect 0

Damit würden Weiterleitungen generell ignoriert werden. Mir war es aber wichtig, alle Seiten des Wikis im Archiv zu haben.

wget

Los gehts mit wget:

wget --recursive --domains=wiki.natenom.com --html-extension --page-requisites --convert-links --no-parent -R "*action=*" -R "*printable=*" -R "*oldid=*" -R "*title=Talk:*" -R "*limit=*" "https://wiki.natenom.de/w/Main_Page"

Erklärung der Parameter:

--recursive

Das ganze Wiki soll heruntergeladen werden.

--domains=wiki.natenom.com

Es sollen nur URLs von der Domain des Wikis heruntergeladen werden.

--html-extension

Alle URLs werden in Dateien mit .html am Ende lokal abgespeichert, aus „https://wiki.natenom.de/w/Blaseite“ wird w/Blaseite.html

--convert-links

Alle internen Links werden so konvertiert, dass auf die jeweiligen relativen .html-Dateien verlinkt wird, statt auf Originalwebseite.

-R ...

Überspringt URLs, die bestimmte Strings enthalten, z. B. den Namensraum Talk und weitere.

-erobots=off

Ein Archiv mit der ganzen Webseite

Nach dem Herunterladen des Wikis gibt es im aktuellen Verzeichnis ein neues Verzeichnis mit dem Namen „wiki.natenom.com“.

Dieses wird gepackt und dann auf den Server hochgeladen und ersetzt in Zukunft die dynamische Variante des Wikis.

Für mein Wiki ist das komplette Archiv gerade mal ~60MiB groß.

Weiterleitungen einrichten, damit Links von draußen weiterhin funktionieren

wget hat im erstellen Archiv bereits alle heruntergeladenen URLs in Dateien mit der Endung .html umbenannt und alle vorhandenen Wiki-internen Verlinkungen angepasst. D. h. im fertigen, statischen Wiki enden alle URLs (außer Bilder) auf „.html“.

Wenn jedoch jemand von „außen“ über einen Link auf mein Wiki kommt, würde er ohne die Endung .html keine URL mehr abrufen können, daher muss man sich selbst darum kümmern, dass solche URLs weitergeleitet werden.

Dafür benötigt man eine RewriteRule:

Options +FollowSymlinks

RewriteEngine On RewriteBase / RewriteCond %{REQUEST_URI} !.html$ RewriteRule w/(.*) w/$1.html [R=302,L]

Da es unterhalb von /w/ nur Seiten gibt und keine Grafiken, gibt es auch keine Probleme, dass versehentlich Bilder nach .html umgeleitet werden.

Alle anderen RewriteRules werden aus der alten Konfiguration gelöscht.

Für die anfangs erwähnten 301-Weiterleitungen bereits früher verschobener Inhalte musste ich jetzt noch die URLs anpassen, damit diese auf .html reagieren und diese entsprechend in die neue .htaccess-Datei des statischen Wikis übernehmen.

Z. B. wurde aus:

RedirectMatch permanent ^/w/Android$ https://wikiarchiv.natenom.de/en/android

dieses hier:

RedirectMatch permanent ^/w/Android\.html$ https://wikiarchiv.natenom.de/en/android

Startseite des Wikis verfügbar machen

Jetzt sollte man noch einrichten, dass man die Startseite des Wikis auch dann erhält, wenn man auf die Hauptseite aufruft. Dies erledigt man am besten per Weiterleitung, weil die Startseite sonst mehrfach existiert mit gleichem Content. Jedoch würden dann die relativen URLs nicht passen, weil das /w/ am Anfang fehlen würde.

Daher trägt man in die .htaccess noch ein:

RedirectMatch ^/$ /w/Main_Page.html

CSS verfügbar machen

cd /xxx/htdocs/

cp load.php?debug=false&lang=en&modules=ext.cite.styles%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.sectionAnchor%7Cmediawiki.skinning.interface%7Cskins.vector.styles&only=styles&skin=vector.css “load.php%3Fdebug=false&lang=en&modules=ext.cite.styles%257Cmediawiki.legacy.commonPrint%252Cshared%257Cmediawiki.sectionAnchor%257Cmediawiki.skinning.interface%257Cskins.vector.styles&only=styles&skin=vector.css”

Sitemaps

In meinem Fall musste auch noch das Verzeichnis mit den Sitemaps kopiert werden.

Was nicht funktioniert

Bis auf wenige Seiten sieht alles aus, wie es soll. Hier ist die Liste aller Seiten im Wiki, falls jemand etwas bestimmtes sucht. Die Suche selbst funktioniert natürlich nicht mehr, so wie auch alles andere, was dynamisch generiert wurde, wie z. B. der Namensraum Talk.

Die richtigen Seiten mit Inhalten sind aber alle verfügbar und das war mein Ziel.

Informieren

Für mögliche 404 Fehler im jetzt statischen Wiki habe ich ein eigenes ErrorDocument für den Webserver erstellt, das kurz die Situation erklärt, damit der Besucher weiss, wieso es viele URLs nicht mehr gibt.

Die Datei heißt 404.html und über diese Direktive kann man sie aktivieren:

ErrorDocument 404 /404.html

Navigiert man zu einer URL, die es nicht mehr gibt, dann sieht man das Folgende:

Das lässt sich auch in schön machen, aber mir reicht es aus.

Das wars dann mit MediaWiki

Jetzt muss ich mich nicht mehr um unregelmäßige Updates meines nicht weiter geführten Wikis auf MediaWiki Basis kümmern und muss mir auch keine Sorgen machen, dass es irgendwann eine Sicherheitslücke geben könnte.

Nochmal zur Klarstellung: MediaWiki ist eine tolle Software und man kann sehr viel damit machen. Aus meiner Sicht ist es für einen einzelnen Menschen administrativ aber zu komplex. Deshalb habe ich mich lieber wieder auf mein DokuWiki  unter [wiki.natenom.de][2] konzentriert.

Perfekt :)

Ich habe 2010 eine eigene Piwik-Installation aufgesetzt und nutze es seitdem auf allen meinen Webseiten.

Anfänglich war es für mich ein sehr gutes Werkzeug, weil man damals noch sehen konnte, welche Suchbegriffe ein Besucher bei Google verwendet hat, um auf meinem Webseiten herauszukommen. Seit Google https als Voreinstellung verwendet sieht man diese Begriffe jedoch nicht mehr.

Piwik ist immer noch ein tolles Werkzeug und man kann viele andere Daten sehen, z. B. die meist verwendete Auflösung, Gerätetypen und vieles mehr.

Aber seit der genannten Änderung von Google konnte ich aus Piwik keine wirklich relevanten Dinge mehr für mich herauslesen.

Ich habe es aber weiterhin laufen lassen, weil es zur Befriedigung der eigenen Neugierde oder für ein paar Zahlenspiele immer mal wieder schön ist. Aber wirklich aussagekräftige Daten sind das alles nicht. Schließlich weiss man nie, wie groß der Anteil der Besucher ist, die Piwik blockieren.

Ich habe mich in der letzten Zeit immer mal wieder mit dem Thema und ob der Notwendigkeit von Piwik für mich auseinandergesetzt und mich heute letztlich dazu entschieden, die Piwik-Einbindung von allen meinen Webseiten zu entfernen.

Auf Dauer war ich aber nicht davon überzeugt PHP für eine Webseite zu verwenden, die nur aus statischen Inhalten besteht.

Daher wird www.natenom.com jetzt offline auf meinem Rechner mittels Hugo erzeugt und anschließend hochgeladen. Man kann diesen Vorgang auch direkt auf dem Server ausführen, aber das ist in meinem Fall nicht notwendig; es ändert sich dort so gut wie niemals etwas :)

Es wird das Thema hyde-x verwendet.

So sieht die Seite auf dem Desktop aus:

Das Design ist responsive und erscheint so auf einem Android-Gerät:

Ein Kontaktformular gibt es daher nicht mehr, aber es gibt ja andere Kontaktmöglichkeiten.

Man benötigt keine Datenbank und die Bearbeitung der Inhalte geschieht per WYSIWYG direkt innerhalb der Webseite.

Auf der Projektseite gibt es viele verschiedene Themes und auch Plugins.

Habe das verwendet, um meine Startseite auf www.natenom.com endlich ordentlich zu gestalten; vorher war das selbst geschriebenes HTML.

Aktuell verwende ich auf meiner Seite  das Thema namens Slate.

Hier ein Screenshot vom WYSIWYG-Editor:

Passt :)

Formate

Es werden verschiedene Feeds (Atom, RSS, HTML, JSON, Plaintext) angeboten. Wird ein solcher Feed abgerufen, arbeitet im Hintergrund eine sogenannte Brücke, die die Suchfunktion der entsprechenden Webseite abruft.

Installation

Zum Installieren entpackt man das Projektarchiv auf dem eigenen Webserver, fertig. Es werden PHP 5.4 und OpenSSL benötigt.

Einen Feed generieren lassen

Ruft man die URL des abgelegten Projektverzeichnisses auf, so erhält man eine Liste mit Forumlaren aller aktivierten Brücken:

Hier gibt man die notwendigen Daten ein, klickt auf das gewünschte Format und wird dann direkt zum eigenen Feed weitergeleitet, den man so in seinen News-Reader eintragen kann.

Für mich interessante Brücken sind:

• Bandcamp
• DuckDuckGo
• GooglePlus
• SoundCloud
• Twitter
• Youtube

Gerade letzteres kann ich seit längerem nicht mehr nutzen, seit Youtube die alte API deaktiviert hat.

Insgesamt gibt es aktuell ca. 100 verschiedene Brücken.

\o/

Ein sehr schönes Projekt :)

Die Projektseite findet sich hier.

Die Direktive ServerSignature von Apache war mir bekannt und bereits auf Off gestellt; dadurch sendet der Server nicht seine Version bei z.B. Verzeichnislisten oder Fehlerseiten.

Es werden aber auch im HTTP-Header Versionsinformationen von Apache (Server: xxx) und PHP (X-Powered-By: xxx) gesendet.
Mit folgenden Änderungen erreicht man, dass Apache im Header nur noch „Server: Apache“ einträgt und „X-Powered-By“ ganz weglässt:

1. „ServerTokens ProductOnly“ in die Apache-Config eintragen
2. „expose_php = Off“ in die entsprechende php.ini eintragen, z.B. /etc/php5/apache2/php.ini unter Debian.
3. Apache neustarten mit: apache2ctl graceful

Fertig.