Nginx on Natenoms Blog

Verbesserter Shortcode für die Einbindung von 360°-Fotos in meinem Blog (1 Update)

Mon, 27 Mar 2023 13:20:12 +0200

Da die Erstellung der 360°-Fotos relativ gut funktioniert und ich davon in Zukunft mehr erstellen werde, habe ich meinen Shortcode sphere erweitert.

Der Shortcode sorgt dafür, dass ein zusammengefügtes 360°-Foto in einem virtuellen Raum angezeigt wird, Details hier.

Ich habe den Shortcode nun erweitert und zusätzlich zum Bildbetrachter gibt weitere Informationen:

Ein Link zur Markierung auf einer Karte bei OpenStreetMap, an dem das “Foto” ¹ entstanden ist.
Ein Link zum Originalfoto mit der Angabe der Dateigröße. Im Gegenzug habe ich den Download-Button aus den Bedienelementen entfernt.
Eine Karte kann unter dem Foto nachgeladen werden, jedoch erst nach einem Klick auf “Karte von OpenStreetMap nachladen …”, zuvor werden Infos zum Datenschutz angezeigt, da die Karte von einer externen Website nachgeladen wird.

Update

Update 1 (2023-09-11): Es gibt eine neue Variante des Shortcodes, der auch mit mehreren Einbindungen pro Blogbeitrag umgehen kann (bis auf die Karte), siehe hier.

iframe via Webserver erlauben

Damit das neue iframe geladen wird, musste ich in meiner nginx-Konfiguration im Bereich add_header Content-Security-Policy hinzufügen:

frame-src https://www.openstreetmap.org/export/embed.html

Der erweiterte Shortcode

Hugo-Shortcode

Hier der Quelltext der erweiterten Shortcodes sphere.html:

{{- $img := (.Page.Resources.ByType "image").GetMatch (printf "*%s" (.Get "src")) -}}
{{- $caption := "" -}}{{ if isset .Params "caption" }}{{ $caption = (.Get "caption" | markdownify ) }}{{ end }}
{{- $osmurl := "" -}}{{ if isset .Params "osmurl" }}{{ $osmurl = (.Get "osmurl" ) }}{{ end }}
{{- $osmembedurl := "" -}}{{ if isset .Params "osmembedurl" }}{{ $osmembedurl = (.Get "osmembedurl" ) }}{{ end }}
{{- $imgsize := "" -}}{{ if isset .Params "imgsize" }}{{ $imgsize = (.Get "imgsize" ) }}{{ end }}
<head>
    
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />

    <link rel="stylesheet" href="/my_css/sphere/index.min.css" />
head>
<script src="/my_js/sphere/three.min.js">script>
<script src="/my_js/sphere/index.min.js">script>


<div id="viewer" style="width: 100%; height: 60vh;">div>

<script>
    const viewer = new PhotoSphereViewer.Viewer({
        container: document.querySelector('#viewer'),
        panorama: '{{- $img -}}',
        caption: '{{- $caption -}}',
        fisheye: true,
        lang: {
            zoom: 'Zoomen',
            zoomOut: 'Heraus zommen',
            zoomIn: 'Hinein zoomen',
            moveUp: 'Nach oben',
            moveDown: 'Nach unten',
            moveLeft: 'Nach links',
            moveRight: 'Nach rechts',
            download: 'Herunterladen',
            fullscreen: 'Vollbild',
            menu: 'Menü',
            close: 'Schließen',
            twoFingers: 'Benutze 2 Finger zum Navigieren.',
            ctrlZoom: 'Benutze Strg und das Mausrad, um im Bild zu zoomen.',
            loadError: 'Das Panorama kann nicht geladen werden.',
          }

    });
    viewer.navbar.getButton('download').hide();
script>

<div class="shortcode-sphere">
<p class="untertitel">{{- if ( $osmurl ) -}}<a href="{{ $osmurl }}">Standorta> (bei OpenStreetMap), {{ end -}}<a href="{{- $img -}}">Originalfotoa>{{- if ( $imgsize ) }} ({{ $imgsize }} MiB){{- end -}}p>








{{- if ( $osmembedurl ) }}
<div id="osmiframe" data-osmembedurl="{{ $osmembedurl }}">
  <div id="iframe-content">
    <p>Es gibt die Möglichkeit, eine Karte von OpenStreetMap mit dem Standort, an dem das Foto entstanden ist, hier anzuzeigen. Dabei werden Daten an OpenStreetMap.org übertragen. Informationen zum Datenschutz des Anbieters siehe <a href="https://wiki.osmfoundation.org/wiki/Privacy_Policy">https://wiki.osmfoundation.org/wiki/Privacy_Policya>.p>
    <button id="load-iframe" class="btn btn-sm btn-primary">Karte von OpenStreetMap.org nachladen …button>
  div>
  <noscript><p>Du benötigst JavaScript, um das iframe mit der Karte nachzuladen.p>noscript>
  <script src="/my_js/sphere/iframe.js">script>
div>
div>
{{- end -}}

JavaScript

Das JavaScript habe ich per Copy&Paste von einem anderen Script umgemodelt und nach vielen Versuchen hat es dann funktioniert. Ich habe ja von solchen Dingen keine Ahnung.

Hier das iframe.js:

document.getElementById('load-iframe').addEventListener('click', init);

function init() {
    const iframeWrapper = document.getElementById('osmiframe');
    const osmembedurl = iframeWrapper.dataset.osmembedurl;

    loadComment(osmembedurl);
}

function loadComment(osmembedurl) {
    var iframe = " + osmembedurl + "' style='border: 1px solid black'>";

    document.getElementById('iframe-content').innerHTML = iframe;
};

SCSS

Und das zugehörige SCSS:

.shortcode-sphere {
	#iframe-content {
		border-style: dotted;
		margin: 0.5em;
		padding: 0.5em;
	}
	
	.untertitel {
	    margin-top: 0.5em;
    	margin-bottom: 1em;
    	margin-right: 0.5em;
    	text-align: right;
    	font-style: italic;
    	font-size: smaller;
	}

    .btn a {
		color: white;
    }
}

Beispiel

Im Blogbeitrag 360°-Foto: Neuhausen (Enzkreis) wird z. B. dieser Shortcode verwendet:

{{< sphere src="2023-02-24-neuhausen-1-small.webp" caption="Landschaft nördlich von Neuhausen (Enzkreis)" osmurl="https://www.openstreetmap.org/?mlat=48.80035&mlon=8.77323#map=15/48.8010/8.7731" imgsize="8,6" osmembedurl="https://www.openstreetmap.org/export/embed.html?bbox=8.755288124084474%2C48.79391687059584%2C8.79112243652344%2C48.8067645369292&layer=mapnik&marker=48.800341115118435%2C8.773205280303955" >}}

Das Ergebnis sieht so aus (ohne geladene Karte):

Mit geladener Karte:

Es sind ja eigentlich sehr viele Einzelfotos, gemeint ist hier aber das Ergebnis. ↩︎

Weiterleitungen von meiner alten Domain natenom.name entfernt

Wed, 25 Jan 2023 02:53:32 +0100

Es ist nun schon mindestens 10 Jahre her (eher deutlich länger), dass ich meine Websites von der Domain natenom.name auf andere Domains umgezogen hatte. Bis heute gab es trotzdem noch Weiterleitungen, sodass man im mittlerweile alten (und archivierten) Wiki und im Blog heraus kam, wenn man einen Link auf die alte Domain auf irgend einer Website angeklickt hat.

Nun ist es aber irgendwann auch mal gut. Wer die Links bisher nicht angepasst hat, wird es vermutlich auch in Zukunft nicht mehr machen.

Falls doch, sollte er/sie/es URLs zu http(s)://natenom.name/ oder http(s)://wiki.natenom.name/ nach https://natenom.de/ respektive https://wiki.natenom.de ändern.

Heute habe ich die beiden Weiterleitungen entfernt und auf der Domain und der Subdomain nur noch einen entsprechenden Hinweis hinterlegt. Die Weiterleitungen waren schon viele Jahre auf den HTTP-Status-Code 301 (permanent) eingestellt gewesen.

Hinweistext beim Aufruf der alten Domain.

Ab dem 11. April 2022 wird dann auch diese Info entfallen und die Domain nicht mehr vom Webserver bedient werden und danach werde ich dann auch die Domain aus dem DNS entfernen und noch später dann auch mal kündigen.

Auch die Weiterleitungen von natenom.de und www.natenom.de nach natenom.com und von www.natenom.com und natenom.com nach natenom.de habe ich entfernt, da es dort sowieso nie relevante Inhalte gab.

Insgesamt wird somit das Setup deutlich einfacher, sollte ich mal mit den Websites woandershin umziehen müssen.

Weiterleitungen für den neuen Foto-Blog

Thu, 12 Jan 2023 20:59:37 +0100

Habe heute für die über 300 Blogbeiträge, die ich nach ~~fotos.natenom.com~~ verschoben hatte, Weiterleitungen eingerichtet.

Als Basis dafür habe ich die Sitemap des Foto-Blogs verwendet.

Zu meinem Erstaunen habe ich dieses Mal nicht irgend ein Gefrickel aus cat, sed, grep und co verwendet, sondern nur kate, den KDE Advanced Editor.

Zuerst rief ich die sitemap.xml in Firefox auf, weil der Browser die Datei so anzeigt, dass nicht alles in einer Zeile ist.

Das habe ich dann in ein neues Dokument in kate eingefügt. Dann ging es weiter mit:

Manuell alle Zeilen gelöscht, die nicht für einen Blogbeitrag standen, z. B. .../categories/...
Alle Vorkommen von und entfernt und das sah dann so aus:

…
https://fotos.natenom.com/2022/05/der-tag-23-05-2022/
https://fotos.natenom.com/2022/05/flugtier-beim-abbremsen/
https://fotos.natenom.com/2022/05/fotos-der-letzten-tage-2/
https://fotos.natenom.com/2022/05/fotos-der-tour-am-14-05-2022-fotorahmen-und-selfie/
https://fotos.natenom.com/2022/05/fotos-der-letzten-tage/
…

Mit “Suchen und Ersetzen” im Modus “Regular Expression” nach ^ gesucht (Anfang der Zeile) und durch ein Leerzeichen ersetzt, sodass am Anfang jeder Zeile ein Leerzeichen steht.
Mit “Block selection mode” alles ab dem Ende der Domain bis zum Ende jeder Zeile markiert, z. B. /2022/05/fotos-der-tour-am-14-05-2022-fotorahmen-und-selfie/.

Weiter im “Block selection mode” in die erste Zeile in die erste Spalte geklickt und die Auswahl eingefügt. Es wird automatisch jede Zeile passend eingefügt.
Den “Block selection mode” wieder deaktiviert.
Mit “Suchen und Ersetzen” im Modus “Regular Expression” nach /$ gesucht und durch / redirect; ersetzt.
Um an den Anfang der Zeile noch das notwendige rewrite einzufügen, mit “Suchen und Ersetzen” nach ^/ im Modus “Regular Expression” suchen und mit rewrite / ersetzen.

Im Ergebnis sieht die Textdatei nun so aus:

…
rewrite /2022/05/der-tag-23-05-2022/ https://fotos.natenom.com/2022/05/der-tag-23-05-2022/ redirect;
rewrite /2022/05/flugtier-beim-abbremsen/ https://fotos.natenom.com/2022/05/flugtier-beim-abbremsen/ redirect;
rewrite /2022/05/fotos-der-letzten-tage-2/ https://fotos.natenom.com/2022/05/fotos-der-letzten-tage-2/ redirect;
rewrite /2022/05/fotos-der-tour-am-14-05-2022-fotorahmen-und-selfie/ https://fotos.natenom.com/2022/05/fotos-der-tour-am-14-05-2022-fotorahmen-und-selfie/ redirect;
rewrite /2022/05/fotos-der-letzten-tage/ https://fotos.natenom.com/2022/05/fotos-der-letzten-tage/ redirect;
…

Hinweis

Ich habe erst einmal redirect verwendet, was dem HTTP Status Code 302 entspricht, da ich noch nicht sicher bin, ob alle verschobenen Beiträge auch dort bleiben. Sobald das fest steht, werde ich das durch permanent ersetzen, das dem Status Code 301 entspricht.

Insgesamt habe ich auf diese Weise 369 Weiterleitungen eingerichtet.

Diese 369 Zeilen habe ich in eine eigene Datei eingefügt und mittels include an die passende Stelle in der Nginx-Konfiguration des Blogs eingefügt.

Dann einmal kurz getestet, ob die Syntax passt mit:

nginx -t

Und den Webserver neugestartet, da alles okay war.

Fertig. 😊

Altes, archiviertes wiki.natenom.de verbessert

Thu, 27 Oct 2022 18:00:45 +0200

Ich habe Anfang des Jahres mein altes Wiki (wikiarchiv.natenom.de), das mit DokuWiki betrieben wurde, in eine statische Website umgewandelt und somit archiviert. Die meisten Bereiche habe ich in mein neues Wiki (wiki.natenom.de) migriert.

Jedoch waren der Einfachheit halber bis heute auch die migrierten Bereiche weiterhin im alten Wiki auf Dateiebene hinterlegt, aber wegen der Weiterleitungen nicht abrufbar.

Die Weiterleitungen führten für migrierte Inhalte via HTTP Status Code 301 zum neuen Wiki.

Heute war es endlich an der Zeit, die alten Inhalte aus dem archivierten, alten Wiki restlos zu löschen.

Damit ich auch in Zukunft noch nachlesen kann, wie ich das gemacht hatte oder falls jemand das selbst für ein eigenes Wiki machen möchte, habe ich hier die Anleitung dazu bereit gestellt.

Überlegungen zum Entfernen der migrierten Bereiche aus dem archivierten Wiki

Ein paar Gedanken dazu, ob es sinnvoll ist, die migrierten Bereiche zu entfernen:

Im Seitenindex im Wiki und in der Sitemap fehlen die migrierten URLs. Diese wurden aber sowieso schon seit Monaten mit 301 weitergeleitet aufs neue Wiki und bleiben weiterhin via nginx-Konfiguration im Webserver, sodass auch alte Verlinkungen auf migrierte Inhalte weiterhin richtig zum neuen Wiki auflösen.
Man kann jetzt nur nicht mehr im alten Wiki stöbern sondern muss dazu ins neue Wiki.
Für Suchmaschinen ist es vermutlich besser, weil die meisten migrierten Inhalte nicht mehr nur aus Weiterleitungen bestehen. Zudem gucken Suchmaschinen dank 301 sowieso seit Langem nur noch im neuen Wiki.

Wenn jemand hierzu Gedanken hat, bitte anschreiben. 😊

Was wird in dieser Anleitung gemacht?

Auf dem lokalen Rechner wird:

der Webserver Nginx installiert.
eine temporäre lokale Domain eingerichtet und verwendet.
das Wiki konfiguriert.
das Wiki via wget heruntergeladen und das Ergebnis modifiziert.

Schließlich wird das Ergebnis auf den öffentlichen Webserver (wiki.natenom.de) hochgeladen und bleibt dort auf ewig liegen und wird nie wieder angetastet.

Vorbereitungen

Als Basis habe ich meine damalige Dokumentation verwendet, die beschreibt, wie man ein DokuWiki in eine statische Website umwandelt, siehe hier.

Installation der benötigen Debian-Pakete

apt install nginx php8.1 php-fpm php8.1-xml

Lokale Domain fürs Wiki

Man kann zwar auch die richtige Domain verwenden und diese auf den lokal Rechner verweisen lassen aber das birgt Probleme, falls man z. B. HSTS verwendet. Dann wird man jedes Mal auf https weitergeleitet, was hier in dieser Anleitung aber nicht eingerichtet wird.

Die lokale Domain habe ich einfach mal auf wiki.natenom.me festgelegt und verwende sie hier in allen Shell-Kommandos entsprechend.

In die Datei /etc/hosts trägt man dazu ein:

127.0.0.1 wiki.natenom.me

Lokalen Webserver konfigurieren

Hier die Konfiguration für den lokalen Nginx-Server:

Datei /etc/nginx/sites-enabled/default

Umzug von DokuWiki nach Hugo – Teil 4 – Einrichten und fertig

Sun, 20 Mar 2022 15:09:47 +0100

Heute geht es weiter mit der Einrichtung meines neuen Wikis, das seit heute nachmittag bereits online ist.

Zugriff auf Informationen von Git

Das Theme docsy, das ich für mein neues Wiki verwende, zeigt auf Wunsch und mit Hilfe von Git Zusatzinformationen an.

Zur Aktivierung trägt man die folgende Zeile in den Hauptbereich der Konfiguration in der config.toml ein:

enableGitInfo = true

Ich werde das für meinen Blog erst aktivieren, wenn es ein öffentliches Repo für mein Wiki gibt.

Letzte Bearbeitung und Beschreibung

Wenn Git aktiviert ist, wird automatisch unter jeder Seite das Datum der letzten Bearbeitung angezeigt, dazu die Commit-ID und die Commit-Beschreibung.

Links zum Git-Repo

Dann trägt man noch im Bereich [params] in der config.toml die Variable github_repo = "https://github.com//" ein.

Dann werden auch Links generiert, die auf den letzten Commit einer Seite verlinken.

Hinweis

Ich überlege noch, ob ich das Wiki in Zukunft in ein öffentliches Repo auf Github oder eine andere Plattform legen werde. Es könnte aber auch ein privates Repo sein, damit man zumindest Pull Requests und Issues erstellen könnte. Hat dazu jemand Erfahrungen, würde mich gerne dazu austauschen.

Feeds

Man kann noch den Atom Feed für die Website aktivieren mit:

[outputs]
section = [ "HTML", "RSS" ]

Warnung

Meine Seiten im Wiki haben bisher kein Datum im Front Matter und es wird leider nicht das letzte Änderungsdatum mit Git ausgelesen, sodass die Datumsangaben im Feed mit Mon, 01 Jan 0001 00:00:00 +0000 angegeben werden.

In der Sitemap sind dagegen valide Datumsangaben enthalten, die scheinbar von Git kommen. Ich werde mir das genauer anschauen und versuchen, das auch für den Feed so hinzubiegen.

Deshalb habe ich den Feed für mein Wiki noch nicht aktiviert.

Druckansicht

Es gibt im Theme auch die Möglichkeit, eine Druckansicht hinzufügen (rechts oben), die dann z. B. den gesamten Hauptbereich Fahrrad in einer einzigen Seite anzeigt. Das werde ich vielleicht später aktivieren.

Dazu muss man in der config.toml noch im Bereich outputs hinzufügen:

[outputs]
section = [ "HTML", "RSS", "print" ]

Dokumentation

Startseite meines neuen Wikis

Ich kann ja nix bei so Websachen, das weiß man ja. Deshalb versuche ich immer, das irgendwie zu nutzen, war mir das System vorgibt, wie zum Beispiel die Möglichkeit des Themes Docsy, ein Cover auf der Startseite zu nutzen. Dessen Beschreibung gibt es hier.

Die Themenbereiche darunter wurden mit dem Shortcode Card Pane erstellt. Hier die Dokumentation dazu.

Dafür ist die Datei content/de/_index.md zuständig. Dieser Inhalt wird immer angezeigt, wenn man auf das Document Root der Webseite geht (also /).

So sieht die Startseite aktuell aus:

Hinweis

Per Voreinstellung landet man immer auf / des Wikis. Ich habe keine Möglichkeit gefunden, das zu ändern. Auch würde die Verlinkung des Namens des Wikis links oben gerne so ändern, dass auf /docs verlinkt wird.

Ich habe das erst einmal mit der Startseite gelöst.

Tipp

Es wäre zwar auch möglich, dass man /docs zum Document Root der Webseite macht, aber dadurch würde ich Flexibilität verlieren, die ich später vielleicht noch benutzen können möchte. (Hier steht, wie man das machen könnte).

Twitter Cards und Open Graph

Über das Partial docsy/assets/vendor/bootstrap/site/layouts/partials/social.html werden Twitter Cards und Open Graph Metadaten im Docsy-Theme in eine Seite eingefügt. Dort sind auch twitter:image und og:image enthalten, z. B. für twitter:image:

Für die Startseite des Wikis wird somit das Logo aus dem Bereich params in der Variable social_image_path verwendet und für alle anderen Seiten das aus der Variable social_logo_pathim Front Matter der einzelnen Seite. Glaube ich. Es hat leider nicht funktioniert.

Update

10.04.2022: Ich habe mich heute erneut mit dem Theme beschäftigt und es funktioniert ganz anders. Die Lösung ist in diesem Blogbeitrag beschrieben.

Weiterleitungen

Damit man auch über das alte Wiki noch zu den Inhalten des neuen Wikis kommt, habe ich alles entsprechend weitergeleitet.

Ich habe jeden Hauptbereich des alten wikis einzeln weitergeleitet mit:

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

Somit kann ich links das Navigationsmenü im alten Wiki stehen lassen und man kommt auch bei Unterseiten im neuen Wiki an. Und auch Menschen, die auf irgend einer fremden Website auf einen Links zum alten Wiki klicken, landen im neuen Wiki.

Tipp

Ein paar Bereiche habe ich im neuen Wiki umstrukturiert. So liegt z. B. die “Radfahrer FAQ” im neuen Wiki unterhalb von “Fahrrad” (/fahrrad/faq/), während sie im alten Wiki unterhalb von “Mobilität” (/verkehr/projekte/radfahrer_faq/) lag.

Doch auch in solchen Fällen kann man das einfach weiterleiten, da in der Konfiguration von Nginx immer die erste passende Weiterleitung gilt, auf die Nginx stößt. D. h. zuerst leitet man den kleinen, verschobenen Bereich um und dann erst den Rest:

rewrite ^/verkehr/projekte/radfahrer_faq(.*)$ https://wiki.natenom.de/docs/fahrrad/faq$1 redirect;
rewrite ^/verkehr(.*)$ https://wiki.natenom.de/docs/mobilitaet$1 redirect;

Informationen für Menschen – So wichtig

Für diejenigen Menschen, die in der Seitennavigation (links) im neuen Wiki die Themen vermissen, die nicht im neuen Wiki sind, habe ich für diese dort trotzdem Einträge erstellt. Klickt man diese an, bekommt man die Information, dass sie noch im alten Wiki zu finden sind.

Das betrifft die Bereiche Minecraft, Mumble und Sauerbraten.

Auf der Startseite des neuen Wikis sind diese Bereiche natürlich auch verlinkt.

Altes Wiki – “keine Änderungen”

Das alte Wiki bleibt erst einmal so bestehen. Mit der Zeit werde ich dann vermutlich die weitergeleiteten Bereiche in der Seitennavigation ausblenden und vielleicht sogar ganz entfernen. Natürlich mit vorherigem Backup.

Dann könnte ich irgendwann einmal die alten Bereiche in eine statische Seite umwandeln und dann DokuWiki selbst entfernen. Dann bräuchte ich kein PHP mehr auf meinem Server.

Todo

Von den Todos aus dem letzten Blogbeitrag habe ich das Favicon umgesetzt. Wie das geht, steht hier.

Das mit der Nummerierung der Überschriften habe ich angefangen, aber es funktioniert bisher leider noch nicht.

Hinzu kommende Aufgaben:

Alle Verlinkungen im Blog auf die umgezogenen Bereiche aufs neue Wiki umschreiben. Es gibt zwar Weiterleitungen, aber auf die will ich mich nicht dauerhaft verlassen.
Bilder für Twitter Cards und Open Graph siehe oben.
Feed mit Änderungsdatum aus Git füttern.

Passt 🙂

Das passt so erst einmal für mich. Ich hatte damit extrem viel Arbeit in den letzten Tagen (und Wochen?) und bin froh, dass es jetzt fertig ist.

Und so sieht mein neues Wiki jetzt aus:

Screenshot meines neuen Wikis

Nginx Konfiguration meines Blogs aufgeräumt

Tue, 15 Feb 2022 00:38:55 +0100

Mit dem Einsatz von Hugo, das ausschließlich statischen Dateien generiert, konnte ich die Konfiguration von Nginx für meinen Blog sehr einfach gestalten. Vielleicht hilft das anderen Menschen, die Hugo nutzen möchten.

Dazu gekommen sind die Weiterleitungen für Umlaute in URLs, wie ich hier beschrieben habe.
Die am ersten Tag des Umzugs etwas unglück eingerichteten Weiterleitungen der in WordPress verfügbaren Feeds auf die von Hugo habe ich jetzt in schön geschrieben. (Eine gute Beschreibung der Feeds und deren URLs, die in WordPress automatisch erstellt werden, gibt es hier.)

Somit ist die ganze Konfiguration für den Blog in Nginx relativ einfach geworden.

Hinweis

Ich bin kein Profi für die Konfiguration von Nginx. Es funktioniert so bei mir, es gibt aber keine Garantie, dass ich da nicht irgendwelchen Blödsinn veranstaltet habe.

Es könnte z. B. sein, dass es nicht sinnvoll ist, die URLs der Feeds der anderen Formate stumpf nach rss (index.xml) weiterzuleiten. Etwas anderes erzeugt Hugo per Voreinstellung aber nicht und ich will das auch nicht ändern.

Falls ich etwas Dummes getan habe, würde ich mich über einen Hinweis freuen. Danke.

Hinweis

Es ist bei solchen Angelegenheiten immer gut, wenn man die Logs des Webservers im Blick hat, vor allem Status 404. Dann fällt auf, wenn etwas nicht funktioniert. Zum Testen von Weiterleitungen nutze ich immer curl, denn es merkt sich keine Zustände zu Weiterleitungen, wie das Browser machen.

server.conf

Die Anmerkungen von mir sind inline, da das besser zum Lesen ist:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69


server {
    […]

    # Das ganze drumherum an Konfiguration des Blogs in Nginx (TLS,
    # Header, Rootverzeichnis, Logs, …) ist in andere Dateien
    # ausgegliedert. Hier ist nur der relevante Teil für alle
    # Verzeichnisse und Weiterleitungen.



    # Weiterleiten der alten Sitemap URLs auf die neue.
    # Es steht zwar auch schon in der robots.txt, man
    # kann es aber trotzdem machen.
    rewrite ^/sitemap.xml.gz[/]?$ /sitemap.xml permanent;
    rewrite ^/wp-sitemap-posts-post-2.xml$ /sitemap.xml permanent;
    rewrite ^/wp-sitemap-posts-post-1.xml$ /sitemap.xml permanent;



    # Bei neu eingerichteten Weiterleitungen der alten Feeds
    # zu den Feeds von Hugo verwende ich den HTTP Status
    # Code 302 "Found", sobald es sich als gut herausgestellt
    # hat, werde ich es auf 301 "Moved permanently" ändern.
    rewrite ^/feed/(rss|rss2|rdf|atom)[/]?$ /index.xml redirect;
    rewrite ^/category/(.*)/feed/(rss|rss2|rdf|atom)[/]?$ /categories/$1/index.xml redirect;
    rewrite ^/tag/(.*)/feed/(rss|rss2|rdf|atom)[/]?$ /tags/$1/index.xml redirect;

    rewrite ^/(feed|rss|rss2|rdf|atom)[/]?$ /index.xml redirect;
    rewrite ^/category/(.*)/(feed|rss|rss2|rdf|atom)[/]?$ /categories/$1/index.xml redirect;
    rewrite ^/tag/(.*)/(feed|rss|rss2|rdf|atom)[/]?$ /tags/$1/index.xml redirect;



    # Die Taxonomie ist in meinem Theme leicht anders als
    # in WordPress:
    rewrite ^/tag/(.*)$ /tags/$1 redirect;
    rewrite ^/category/(.*)$ /categories/$1 redirect;



    # Umleitungen zu Umlaut-URLs (siehe unten
    # im Blogbeitrag)
    rewrite ^/categories/mobilitaet(.*)$ /categories/mobilität$1 redirect;
    rewrite ^/tags/mobilitaet(.*)$ /tags/mobilität$1 redirect;
    rewrite ^/tags/muell(.*)$ /tags/müll$1 redirect;
    rewrite ^/tags/muellsammeln(.*)$ /tags/müllsammeln$1 redirect;
    […]



    # Habe das Verzeichnis der WordPress-Installation 1 zu 1
    # übernommen. Dort landen per Voreinstellung alle hochgeladenen
    # Dateien. Das Verzeichnis bleibt, da noch viele Beiträge
    # hier in Hugo das originale HTML von WordPress enthalten
    # und eingebettete Bilder von dort geladen werden und/oder
    # dorthin verweisen.
    location /wp-content/ {
        alias /pfad-zu/alten-wordpress-dateien/;
        include pfad-zu/static_files.conf;
    }



    # Alle Dateien bekommen eine maximal mögliche Lebenszeit.
    # Siehe nächster Abschnitt, wo die inkludierte Datei zu sehen ist.
    location / {
        include pfad-zu/static_files.conf;
    }
}

Tipp: Hier ein Blogbeitrag zu Weiterleitungen zu Umlaut-URLs, die Hugo aus Tags mit Umlauten generiert.

static-files.conf

Auch hier sind Anmerkungen wegen der Lesbarkeit inline:

 1    if ($request_uri ~* ".(jpg|jpeg|gif|zip|gz|avi|png|mpeg|mpg|txt|mp4|woff|woff2|ttf|eot)$") {
 2            expires 90d;
 3    }
 4
 5
 6
 7    # Das sind die von Hugo erstellen kleinen Varianten
 8    # von Bildern für Thumbnails.
 9    if ($request_uri ~* ".*hu[a-z0-9]{32}.*resize.*$") {
10        expires 300d;
11        break;
12    }
13
14
15
16    # Das Verzeichnis, in dem JavaScript Assets landen.
17    # Sobald sich die Ursprungsdatei ändert, ändert sich
18    # auch der Hashwert im Namen, sodass man eine sehr
19    # lange Lebenszeit angeben kann.
20    if ($request_uri ~* "^/js/.*$") {
21        expires 300d;
22        break;
23    }
24
25
26
27    # Hier gilt das selbe wie auch für die JavaScript
28    # Assets oben drüber.
29    if ($request_uri ~* "^/css/.*$") {
30        expires 300d;
31        break;
32    }
33
34
35
36    # Eingebundenes CSS und JS für Dinge, die
37    # ich relativ oft verändern möchte. Auch Favicons
38    # möchte ich relativ schnell ändern können.
39    if ($request_uri ~* ".(css|ico|js)$") {
40        expires 48h;
41    }

Das wars. Für mich funktioniert das so gut. Anmerkungen bitte per E-Mail.

Danke :)

URL-Struktur in Hugo mit url, slug und title

Mon, 14 Feb 2022 14:23:51 +0100

Alles dank dem Export von WordPress

Ich habe mich etwas mit der URL-Struktur hier im Blog beschäftigt. Da ich anfänglich fast nur auf Basis der aus WordPress exportierten Blogbeiträgt gearbeitete hatte, gewöhnte ich mir an, im Front Matter immer die Option url: anzugeben. Diese enthält immer den vollen Pfad der URL ab der baseURL. Letztere besteht in meinem Blog aus dem Protokoll (https) und dem Domainnamen.

Für diesen Blogbeitrag hätte ich somit im Front Matter eingetragen:

url: /2022/02/url-struktur-hugo-url-slug-title

Nicht gut

Das ist nicht optimal, denn man verliert die Flexibilität. So kann man nicht einfach mal irgendwann die URL-Struktur anpassen, weil in jedem Blogbeitrag schon die am höchsten priorisierte Option url: angegeben ist.

Außerdem braucht man es auch gar nicht, da es in der Konfiguration von Hugo einen Abschnitt gibt, der festlegt, wie die URL (nach der BaseURL) generiert werden soll.

Gut

Ich habe die Konfiguration von Hugo umgestellt und werde in Zukunft nur noch slug: angeben. Der Slug ist der Teil der URL, der nur das Dokument des Blogbeitrags repräsentiert. Im oberen Beispiel wäre das "url-struktur-hugo-url-slug-title".

Damit die URL-Struktur im Blog weiterhin so bleibt wie bisher ("/jahr/monat/titel-des-beitrags/"), habe ich in die config.toml eingetragen:

[permalinks]
  posts = '/:year/:month/:slug/'

Die Voreinstellung, würde man das nicht einfügen, wäre:

'/:year/:month/:title/'

Die Voreinstellung will ich nicht, da ich teils lange Titel für Blogbeiträge habe, die URLs insgesamt aber relativ kurz halten möchte.

Jetzt verwende ich im Front Matter eines Blogbeitrags nur noch die Option slug: und habe im Endeffekt die selbe URL-Struktur und das ganze ist dadurch weniger fehleranfällig, falls man in der url bei Jahr oder Monat etwas Falsches einträgt.

Im Front Matter sah es früher so aus:

---

title: URL-Struktur in Hugo mit url, slug und title
url: /2022/02/url-struktur-hugo-url-slug-title
[…]

---

Und jetzt so:

title: URL-Struktur in Hugo mit url, slug und title
slug: url-struktur-hugo-url-slug-title
[…]

---

Erreichbar ist der Blogbeitrag in beiden Fällen unter:

natenom.de/2022/02/url-struktur-hugo-url-slug-title

Update: Ich wurde darauf hingewiesen, dass Hugo den Namen des Markdown-Dokuments bzw. den Verzeichnisnamen des Page Bundles automatisch als String für den Slug verwendet, wenn man die Option nicht explizit im Front Matter setzt.

Bestehende Blogbeiträge per Script ändern, irgendwann

Und wenn ich dann irgendwann mal alle Front Matter der Blogbeiträge automatisiert von url: nach slug: ändere, habe ich dann sogar die Möglichkeit, mit einer einzigen Änderung in der config.toml die URL-Struktur für alle Blogbeiträge auf einmal zu verändern. Natürlich sollte man in so einem Fall dann Weiterleitungen einrichten.

Bis dahin gibt es keine Probleme mit der bestehenden URL-Struktur, da die Option url: im Front Matter eines Beitrags immer die höchste Priorität hat.

Dokumentation

Die Dokumentation zu diesem Thema findet sich auf der Projektseite von Hugo.

Beim Umzug von WordPress nach Hugo die Kurzlinks nicht vergessen

Mon, 14 Feb 2022 01:13:29 +0100

Hätte ich das mal vorher gewusst :)

ID vs Fancy URL

WordPress hat für jeden Blogbeitrag eine eindeutige ID. Statt einer fancy URL mit ausgeschriebenem Titel wie natenom.de/2022/01/tschuess-wordpress-hallo-hugo kann man daher auch die ID verwenden wie z. B.: natenom.de/?p=12345.

Ich hatte das schon auf dem Schirm. Leider nur in Bezug auf Beitragsentwürfe, nicht auf Verlinkungen in meinem Wiki auf den Blog.

Viele Verlinkungen auf den Blog per ID

Erst heute ist mir aufgefallen, dass es in meinem Wiki ca. 70 solcher Verlinkungen gab, die ich alle per Hand in die fancy URL auflösen musste. Da war die Suchfunktion von Hugo sehr gut. Hätte ich das vor dem Abschalten von WordPress gemacht, hätte ich nur den Link im Browser eingeben müssen und WordPress hätte mich selbst zur fancy URL geleitet.

Man kann solche Links in einem DokuWiki sehr leicht finden. Zuerst wechselt man auf der Konsole in das Verzeichnis data/pages und fürt dann aus:

grep -i -r '\?p=' .

Möglicherweise Zuordnung automatisch erzeugen

Da ich noch den Export meines alten WordPress-Blogs habe, könnte ich sicher auch darin die IDs finden und dann basierend auf dem Export eine Zuordnung von ID zu URL erstellen. Das schaue ich mir später vielleicht noch an. Bis dahin laufen solche Verlinkungen auf meinen Blog ins Leere bzw. auf die Startseite. Das könnte ich dann vielleicht so erstellen wie die Weiterleitungen zu den URLs mit Umlauten.

Die ID steht drin und die URL sind im Export enthalten:

[…]
natenom.de/2010/11/mumble-server-lauft-wieder-rund/
[…]
123
[…]

Sinnvoll?

Ich kann mich also daran versuchen. Ob es aber Sinn hat, aktuell über 2580 URL-Weiterleitungen von ID nach Fancy URL in der Nginx Konfiguratin zu haben?

Außerdem hatte ich schon fast immer Fancy URLs aktiviert. D. h. wenn überhaupt, dann hat man von außen nur zur Anfangszeit diese URLs aus der Adresseleiste des Browsers kopiert. Später habe ich die dann nur noch selbst benutzt, um Beiträge zu verlinken, die noch nicht öffentlich waren.

Weiterleitungen von alten WordPress-URLs auf Umlaut-URLs, wie Hugo sie erzeugt

Sun, 13 Feb 2022 06:35:46 +0100

Wie ich hier schon beschrieben habe, ersetzt Hugo bei URLs Umlaute nicht durch ihre Entsprechungen wie “ae”, “oe” usw, sondern behält sie bei. Ganz im Gegensatz zu WordPress.

Das bedeutet, dass z. B. die alte URL vom WordPress-Blog “/tags/mobilitaet/” in Hugo “/tags/mobilität/” heißt.

Ich hatte bereits am ersten Tag der Umstellung in ganz wenigen Fällen manuell Weiterleitungen erstellt, insgesamt nur drei.

Heute habe ich mich dann etwas damit beschäftigt, geprüft und festgestellt, dass es neben der Kategorie “Mobilität” noch 88 Tags mit Umlauten oder “ß” gibt.

Ich hatte nicht wirklich Lust, das alles manuell einzugeben, und so habe ich ein bisschen Shell-Magic benutzt, um das zu automatisieren. Das will ich hier genau beschreiben.

Überlegungen

Nur am Anfang

Diese ganzen Weiterleitungen muss man natürlich nur am Anfang nach dem Umzug von WordPress nach Hugo bereitstellen. Irgendwann werden Suchmaschinen von selbst auf die neuen URLs mit Umlauten umspringen. Aber ich verstehe nix von SEO. Mir gehts darum, dass ich mal gelernt habe, dass URLs möglichst immer bestehen bleiben sollten.

Alle URLs umschreiben, nicht nur Tags

Es wäre auch möglich, zusätzlich noch alle URLs herauszufischen und die dann auch weiterzuleiten.

Nur je “Wort”, nicht allgemein möglich

Weiterleitungen, die Umlaute für sich umschreiben, wären wohl keine gute Idee, weil die Teilstrings “ae”, “oe”, “ue” und “ss” auch so in URLs vorkommen könnten. Deshalb muss man die einzelnen Begriffe rausfischen und die Weiterleitungen basierend auf diesen erstellen.

.*ss.* -> .*ß.*
.*oe.* -> .*ö.*

keine gute Idee:

essen -> eßen
oboe -> obö

Umgekehrt wäre das kein Problem.

Wie es geht

Datei 1 – Die aktuellen Tags aus Hugo auslesen

Ich verwende meinen hier beschriebenen Alias hugo-search-tags:

hugo-search-tags -E "(ä|ö|ü|ß)" | cut -d':' -f2 > /tmp/umlaut-urls-hugo.txt

Zum Verständis: Die Funktion hugo-search-tags gibt mir die Daten in diesem Format aus (Anzahl:Tag):

327:mobilität
88:müll
83:müllsammeln
64:wälder
51:landstraße
51:fahrradanhänger
33:überholen
24:sonnenuntergänge
[…]

Datei 2 – Die selben Tags in den WordPress-Stil umwandeln

hugo-search-tags -E "(ä|ö|ü|ß)" | cut -d':' -f2 | sed -e "s/ä/ae/g" -e "s/ö/oe/g" -e "s/ü/ue/g" -e "s/ß/ss/g" > /tmp/umlaut-urls-wordpress.txt

Beide Dateien vereinen

Jetzt kann man mit dem Shell Tool paste jede Zeile der einen Datei mit der selben Zeile der anderen Datei vereinen und als Trenner einen Doppelpunkt verwenden:

paste -d':' umlaut-urls-wordpress.txt umlaut-urls-hugo.txt

Das Ergebnis ist dann:

mobilitaet:mobilität
muell:müll
muellsammeln:müllsammeln
waelder:wälder
landstrasse:landstraße
fahrradanhaenger:fahrradanhänger
ueberholen:überholen
sonnenuntergaenge:sonnenuntergänge
fruehling:frühling
bussgeldstelle:bußgeldstelle
[…]

Links ist der String, wie er in WordPress verwendet wurde und rechts der von Hugo.

Konfiguration für Nginx erzeugen

Diese Ausgabe wird nun mittels sed so abgewandelt, dass man direkt die Ausgabe bekommt, die man in die Nginx-Konfiguration eintragen kann. Und das automatisch für alle Tags mit Umlauten.

Der gewünschte für “mobilität” ist zum Beispiel:

rewrite ^/tags/mobilitaet(.*)$ /tags/mobilit_t$1 redirect;

Update: Ich habe das Kommando angepasst, da die erste Version URLs von Blogbeiträgen zerstört hat, die den String eines Tags in der URL hatten, wie z. B. das Wort Frühling, für das es auch einen Tag gibt. Jetzt werden nur noch Tags erfasst.

Dies erreicht man mit diesem Kommando:

paste -d':' umlaut-urls-wordpress.txt umlaut-urls-hugo.txt | sed -E -e 's_(.*):(.*)_rewrite ^/tags/\1(.*)$ /tags/\2$1 redirect;_g'

Anmerkung zu den Unterstrichen bei sed: Man kann als Trenner in sed fast beliebige Trennzeichen verwenden, solange sie innerhalb eines Ausdrucks immer gleich sind. Meist sieht man hier einen Schrägstrich.

Die Ausgabe ist:

rewrite ^/tags/mobilitaet(.*)$ /tags/mobilität$1 redirect;
rewrite ^/tags/muell(.*)$ /tags/müll$1 redirect;
rewrite ^/tags/muellsammeln(.*)$ /tags/müllsammeln$1 redirect;
rewrite ^/tags/waelder(.*)$ /tags/wälder$1 redirect;
rewrite ^/tags/landstrasse(.*)$ /tags/landstraße$1 redirect;
rewrite ^/tags/fahrradanhaenger(.*)$ /tags/fahrradanhänger$1 redirect;
rewrite ^/tags/ueberholen(.*)$ /tags/überholen$1 redirect;
rewrite ^/tags/sonnenuntergaenge(.*)$ /tags/sonnenuntergänge$1 redirect;
rewrite ^/tags/fruehling(.*)$ /tags/frühling$1 redirect;
rewrite ^/tags/bussgeldstelle(.*)$ /tags/bußgeldstelle$1 redirect;
rewrite ^/tags/kaelte(.*)$ /tags/kälte$1 redirect;
rewrite ^/tags/mehrplatzfuersrad(.*)$ /tags/mehrplatzfürsrad$1 redirect;
[…]

Nginx neustarten

Das kann man nun in Nginx eintragen und schon funktionieren alte Links wieder richtig :)

Vorher vielleicht noch testen mit:

nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Und Nginx neustarten.

Fertig. Alle Tags und Kategorien werden nun von den alten URLs auf die neuen von Hugo weitergeleitet.

Umzug von WordPress zu Hugo – Teil 1 – Von den Gründen bis zum ersten funktionierenden Blog

Thu, 03 Feb 2022 07:30:33 +0100

Schon einige Male in den vergangenen Jahren habe ich versucht, meinen Blog von WordPress auf Hugo umzuziehen. Immer gab es dabei für mich unüberwindbare Hürden. Jetzt endlich hat es mal in einem neuen Anlauf funktioniert.

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.

Fenster eines Texteditors unter KDE/Plasma

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.*"

Update

Wenn es Probleme gibt und eine Meldung in der Form no follow attribute found, dann benötigt man zusätzlich noch diesen Parameter:

-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.

Export Tool von WordPress. Exportiert alles außer der hochgeladenen Dateien.

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:

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
Ohne Veränderungen an den Beiträgen wäre die Option removePathAccents von Hugo möglich, die aus “mobilität” “mobilitat” macht.
Hugo selbst zu verändern, siehe hier.
Alle Vorkommen der Tags in den Beiträgen mit sed umschreiben und ö durch oe ersetzen usw.
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.