Front Matter on Natenoms Blog

Und wieder ein neues Helferlein, um einfacher bloggen zu können

Sat, 20 Jan 2024 22:22:07 +0100

Ich hatte bereits vor kurzem ein Helferlein beschrieben, siehe hier, das mir die “Arbeit” im Blog erleichtert. Doch ich hatte immer noch einige Dinge, die ich von Hand machen musste und die mich immer wieder genervt hatten. Und wenn genervt ist von Dingen, dann macht man sie weniger wahrscheinlich. Daher habe ich meinen Hugo Helper noch etwas erweitert, um noch weniger manuell machen zu müssen.

Angenommen, ich wollte ein paar Bilder in einem Blogbeitrag unterbringen. Die Bilder, die ich ins Page Bundle kopiert hatte, konnte ich über einen Rechtsklick über ein eigenes Script verkleinern. Über ein weiteres Script musste ich auch wieder per Rechtsklick alle Metadaten entfernen und dabei entscheiden, ob ich das Script nutze, das alle Daten entfernt oder das Script, das nur die entfernt, die nicht relevant für Fotos sind. Im Fall von 360 ° Fotos müssen bestimmte Metadaten nämlich erhalten bleiben, da sonst der Betrachter hier im Blog nicht funktioniert, siehe hier.

Hugo Helper erweitert

Diese beschriebenen Schritte erledigt jetzt mein Hugo Helper automatisch. Ich muss nur weiterhin die Bilder in das Page Bundle (ein Verzeichnis, das den Blogbeitrag und alle zugehörigen Dateien beinhaltet), benennen und führe irgendwann nur noch meinen Hugo Helper aus, der die folgenden Dinge macht:

Alle Bilder in 4000x4000 Pixel herunterskalieren, wenn sie größer sind.
Beinhaltet der Dateiname die Zeichenkette 2k, dann wird auf 2000x2000 Pixel herunterskaliert. Das hat den Hintergrund, dass nicht alle Fotos die volle Auflösung haben müssen, wenn es z. B. nicht um Fotografie geht.
Enthält der Dateiname den String “pano” oder “sphere” (360°-Foto) wird die Auflösung nicht verringert.
Alle Bilder werden nach .webp konvertiert.
Die alten Bilder werden in ein temporäres Verzeichnis außerhalb des Blog-Verzeichnisses verschoben, statt direkt gelöscht zu werden, falls etwas schiefgehen sollte.
Die Exifdaten aller Fotos und Videos werden gelöscht bis auf für Fotografie relevante Daten.
Enthält der Dateiname den String sphere, dann werden auch die dafür relevanten Exifdaten in der Datei belassen (siehe oben).

Neuer Workflow für Blogbeiträge

Somit ergibt sich für neue Blogbeiträge der folgende, sehr einfache Ablauf:

hgb -cpb "Ich habe eine neue Idee für einen Blogbeitrag"
NeoVimm starten und Verzeichnis des neuen Blogbeitrags öffnen
Mit nd (eigenes Keybinding) das Verzeichnis in Dolphin öffnen.
In Dolphin die Dateien reinwerfen, die ich gerne verewenden möchte, richtig benennen, ggf auf oben genannte Substrings achten und im Blogbeitrag mit einem eigenen Shortcode figure einbetten.
Blogbeitrag schreiben.
Wenn ich fertig bin, hgb -hs aufrufen und im Browser http://localhost:1313 aufrufen, Ergebnis überprüfen.
Wenn das Ergebnis mir gefällt, dann kann ich noch im FrontMatter das aktuelle Datum einfügen, das Tag draft auf false setzen oder die ganze Zeile löschen und in NeoVim gg drücken und damit LazyGit aufrufen, commiten und pushen.

Fertig. ☺️

Und hier noch ein Screenshot dieses Blogbeitrags im Zen-Mode:

Mein Hugo Helper Python Script und was es tun kann

Tue, 09 Jan 2024 21:51:16 +0100

Alle meine Webseiten werden mit Hilfe von Hugo statisch generiert. Für die Arbeit mit Hugo nutze ich schon länger ein eigenes Python-Script, das mir einige Arbeit abnimmt.

Vor ein paar Tagen hat mich jemand gefragt, ob ich das Script nicht öffentlich machen könnte und ich habe das zum Anlass genommen, da mal einige Dinge zu verschönern, damit auch andere Menschen damit etwas anfangen können.

Warnung

Ich bin kein Programmierer und das Script hat vermutlich eine eher schlechte Qualität. Aber das stört mich nicht, denn es funktioniert (für mich).

Wenn es andere Menschen für sich nutzen können, dann ist das großartig. Wenn nicht, dann ist es auch okay.

Zur Installation des Scripts bitte in die README.md des Projekts schauen.

Konfiguration

In der Konfigurationsdatei ~/.config/hgh/hgh.json gibt es einen Abschnitt für allgemeine Einstellungen und dann je einen Abschnitt pro Website, die mit hgh verwaltet werden soll.

Hier ist hinterlegt, welcher Editor verwendet werden soll, wo die Basisverzeichnisse der Websites liegen, wo die content-Verzeichnisse, welcher Benutzernamen für rsync verwendet werden soll, usw.

Ein Alias macht das Leben einfacher

Damit ich nicht dauernd hgh.py --site blog tippen muss, habe ich für jede meiner Websites in der .bashrc einen Alias erstellt:

alias hgb=`hgh.py --site blog`
alias hgw=`hgh.py --site wiki`

Somit kann ich z. B. mittels hgb -cdb ins Basisverzeichnis des Blogs wechseln.

Was der Hugo Helper (hgh) für mich macht

Allgemeine Infos

Mit --help gibt es eine hoffentlich hilfreiche Hilfe. 😁

Mit hgh.py --sites bekomme ich eine Liste aller Websites und der zugehörigen Basisverzeichnisse. Mit --printconfig wird die ganze Konfiguration ausgegeben.

Verzeichniswechsel

Mit -cdb kann ich ins Basisverzeichnis einer Website wechseln, mit -cdc ins normale Content-Verzeichnis und mit -cdl in ein alternatives Content-Verzeichnis.

Letzeres nutze ich für verschiedene Blogbeiträge im Entwurfsmodus. Denn mein Blog besteht aus mehreren tausend Blogbeiträgen und das Bauen dauert sehr lange. Zum Schreiben von längeren Blogbeiträgen nutze ich dieses Verzeichnis und das Bauen dauert dann nur wenige Sekunden.

Kommentar-Datei

Für Kommentare im Blog nutze mittlerweile eine eigene Implementation, bei der die Kommentare im Page Bundle innerhalb der Datei comments.json stehen.

Mit hgh.py --site blog --create-comments-file wird im aktuellen Verzeichnis eine comments.json-Datei erstellt, die bereits ein Skelett für einen Kommentar enthält. Dazu wird die Info ausgegeben, dass man noch im Front Matter jsoncomments: true eintragen muss. Da es hier im Blog nur sehr selten Kommentare gibt, vergesse ich das sonst und will auch nicht jedes Mal nachschauen, wie die Syntax eines Kommentars ist.

Neuer Blogbeitrag

Diese Funktion nutze ich nur für meinen Blog und kann mit einem kurzen hgb --create "Ein neuer Blogbeitrag bla blub" gleich mehrere Aufgaben automatisieren:

benötigte Verzeichnisse erstellen
Slug aus dem angegebenen Titel erzeugen
Page Bundle erstellen
Markdown-Datei für den Blogbeitrag erstellen und mit einem Template befüllen

Details dazu, was alles gemacht wird, gibt es in diesem Blogbeitrag.

In der aktuellen Version des Scripts kann ich auch noch mit --template angeben, welches Template verwendet werden soll.

Mit hgh.py --list-templates wird eine Liste aller vorhandenen Templates angezeigt.

Wer das benutzen will, muss den Code dafür im Script anpassen, um alle notwendigen Variablen auch zu befüllen.

Tmux

Bevor ich VSCode für die Bearbeitung meiner Websites nutzte, habe ich dafür den micro-Editor auf der Kommandozeile benutzt. Aus dieser Zeit stammt --tmux, das ein bestimmtes Layout in Tmux startet. Das habe ich aber schon länger nicht mehr verwendet und man müsste es für sich anpassen.

Lokale Vorschau einer Website

Mittels --hugo-server wird der Blog lokal gebaut und auf dem einstellbaren Port zugänglich gemacht. Für das alternative Content-Verzeichnis gibt es --hugo-server-light.

Dazu kann man noch --hugo-server-env angeben, mit dem sich einstellen lässt, welche Umgebung Hugo verwendet. Default hier ist development. Ich nutze diese Funktion, um den umfangreichen Blog testweise so zu bauen, dass nur die Blogbeiträge der letzten Monate enthalten sind, was dann statt 35 Sekunden (für den gesamten Blog) nur ca. 3 Sekunden dauert.

Tags, Kategorien und deren Häufigkeit

Was mir am Anfang bei Hugo im Vergleich zu WordPress sehr gefehlt hat, waren die Vorschläge für zu verwendende Tags und Kategorien in einem neuen Blogbeitrag.

Hierfür muss man mit dem Hugo Helper eine kleine “Datenbank” erstellen lassen. Dazu wird mit Hilfe von find und dem Tool yq je eine Liste aller bisher verwendeten Tags und Kategorien erstellt und dazu auch die Häufigkeit der Verwendung angegeben.

Diese “Datenbank” erstellt man mit hgh.py --site blog --create-tags-categories-caches und das dauert ein paar Sekunden. Im Ergebnis werden innerhalb von ~/.cache/hgh/ für jede Website zwei Dateien erzeugt:

> ls -1 .cache/hgh/
natenom.de_categories.list
natenom.de_tags.list

Ein Auszug aus den Tags:

[…]
8:F-Droid
1:FLAC
4:Facebook
1:Fahrbahn
556:Fahrrad
52:Fahrradanhänger
1:Fahrradbubble
22:Fahrradcomputer
6:Fahrradmordor
6:Fahrradparkplätze
2:Fahrradstaffel
1:Fahrräder
10:Falschparker
[…]

Um nicht manuell in den “Datenbanken” herumstöbern zu müssen, gibt es --find-tags xyz und --find-categories xyz bzw. die Kurzformen -ft xyz und -fc xyz. Man kann reguläre Ausdrücke verwenden.

Führt man diese aus, wird das Tool fzf (Fuzzy Find) benutzt, um die Liste anzuzeigen und darin suchen zu können:

Your browser does not seem to support video.

Mittels fzf kann man in der Liste der Tags suchen. Die Anzahl der Verwendung wird auch angezeigt. (Link zum Video)

Hinweis

Ab und zu muss man die Datenbanken neu erstellen lassen, da sonst Tags und Kategorien neuer Blogbeiträge nicht enthalten sind.

Hinweis

Ich weiß, dass es für VSCode z. B. das Plugin FrontMatter gibt, das genau diese Funktionialität liefert. Ich möchte jedoch kein riesiges Plugin mit tausenden anderen Funktionen nutzen, wenn es auch einfacher geht. Und wer weiß, ob ich in x Zeit immer noch mit VSCode arbeiten werde.

Alles andere finden

Mittlerweile nutze ich zum Auffinden von Blogbeitragen die Tastenkombination Strg + Shift + f in VSCode. Aber früher brauchte ich dafür etwas Eigenes.

Hierfür gibt es zwei Varianten.

Einfache Variante

Mittels --find xyz bzw. der Kurzform -f xyz wird einfach nur rekursiv nach xyz im Content-Verzeichnis der angegebenen Website gegrept und es gibt eine farbige Ausgabe mit Dateinamen und der zum Suchbegriff passenden Zeile. Groß- und Kleinschreibung werden dabei nicht ignoriert.

Hier z. B. das Ergebnis für die Suche nach ^hugo. Das ist ein Regulärer Ausdruck, der nur auf Zeilen passt, in denen hugo am Anfang der Zeile steht:

posts/2022/2022-02-18-mein-workflow-mit-hugo/index.md:130:1:hugo server -E -D -F -v -c /home/hugo-light/content/
posts/2022/2022-02-27-hugo-theme-optimiert-zeit-zum-rendern-massiv-verringert.md:24:1:hugo --templateMetrics --templateMetricsHints --gc --minify > hugo-metric_0.txt
posts/2022/2022-02-06-ich-mache-wieder-einen-linkdump-woechentlich/index.md:64:1:hugo new -k linkdump posts/2022-02-linkdump-kw-6-2022
posts/2022/2022-03-19-umzug-dokuwiki-hugo-3-einrichtung/index.md:29:1:hugo new site wiki.natenom.com
posts/2022/2022-02-03-umzug-von-wordpress-zu-hugo-1/index.md:310:1:hugo server --renderToDisk -D -E -F -v
posts/2022/2022-02-13-weiterleitungen-auf-umlaut-urls/index.md:55:1:hugo-search-tags -E "(ä|ö|ü|ß)" | cut -d':' -f2 > /tmp/umlaut-urls-hugo.txt

So kann ich z. B. sehr einfach alle Blogbeiträge anzeigen lassen, die ein bestimmtes Tag oder eine Kategorie verwenden, hier z. B. “Linux”, in dem ich den Regulären Ausdruck hgb -f "^\W+- Linux" nutze, der auf Zeilen passt, die am Zeilenanfang beliebig viele Leerzeichen enthalten, gefolgt von - Linux:

[…]
posts/2013/2013-06-27-alle-videos-eines-youtube-kanals-auf-einmal-herunterladen-mit-youtube-dl.md:7:1:  - Linux
posts/2018/2018-11-12-mit-fensterregeln-in-plasma5-kde-bestimmte-fenster-beim-task-switcher-und-anderen-effekten-ignorieren.md:13:1:  - Linux
posts/2013/2013-08-15-neuer-versuch-mit-kde-sc.md:11:1:  - Linux
[…]

Erweiterte Variante

Mittels --find-fuzzy xyz bzw. der Kurzform -ff xyz wird die Ausgabe der oben gezeigten einfachen Variante zusätzlich an fzf übergeben, sodass man darin suchen kann, eine Vorschau der Datei angezeigt bekommt und durch Drücken von F4 die Datei direkt im Editor öffnen kann, den man in der Konfiguration in bin_editor eingestellt hat.

Auch hier kann man reguläre Ausdürcke verwenden, z. B. -ff "Markdown.*kate"

Website bauen und hochladen

Mit hgh.py --site blog --build wird mein Blog lokal gebaut, sodass ich ihn nach einer kurzen Prüfung mit hgh.py --site blog --upload hochladen kann.

Wenn ich mir sicher bin, kann ich auch beide Schritte vereinen mit hgh.py --site blog --deploy.

Hugo Helper herunterladen

Das Hugo Helper Script gibt es hier.

Viel Spaß damit. Oder eben nicht. ☺️

Neues Helferlein für Hugo erleichtert das Bloggen

Fri, 05 Jan 2024 20:36:47 +0100

Ich habe hier seit Anfang Dezember nichts mehr im Blog geschrieben und das liegt unter anderem daran, dass der Start eines Blogbeitrags immer etwas umständlich war.

Das habe ich jetzt mit einem Script automatisiert und kann direkt mit dem Schreiben beginnen, statt die verschiedenen Dinge im Voraus manuell machen zu müssen.

Das Script rufe ich z. B. so auf:

hgb --create "Neues Helferlein für Hugo erleichtert das Bloggen"

Das Script

Das Script macht folgende Arbeiten für mich:

Verzeichnisse erstellen

Innerhalb des content Verzeichnisses von Hugo legt es, wenn noch nicht vorhanden, alle Überverzeichnisse für Jahr und Monat an.

Da dies der erste Beitrag in diesem Jahr ist, hat das Script die Verzeichnisstruktur in …/content/posts/ erstellt:

2024/
    01/

Slug erzeugen

Der Slug ist ein Teil der späteren URL. Bei mir im Blog besteht die endgültige URL eines Blogbeitrags z. B. aus https://natenom.de/JAHR/MONAT/SLUG/.

Das Script erzeugt den Slug automatisch aus dem angegebenen Titel für den neuen Blogbeitrag. Dabei werden folgende Aufgaben erledigt:

Der Slug wird auf xx Zeichen verkürzt.
Großschreibung wird in Kleinschreibung umgewandelt.
Leerzeichen werden durch Bindestriche ersetzt.
Umlaute werden durch Entsprechungen wie z. B. ae oder ss ersetzt.
Alle verbleibenden Zeichen, die nicht alphanumerisch und keine Bindestriche sind, werden entfernt.

Page Bundle

Innerhalb der bereits erstellten Verzeichnisstruktur für Jahr und Monat (siehe oben) wird nun ein Page Bundle erstellt. Der Verzeichnisname besteht aus dem aktuellen Datum und dem Slug. Hier z. B.:

2024-01-05-neues-helferlein-fuer-hugo-erleichtert-das-bloggen/

Datei index.md

In dem erstellten Page Bundle wird nun die Datei index.md aus einem eigenen Template generiert, in welchem die Metadaten title, slug und date im Front Matter eingefügt werden. Die anderen Metadaten wie Kategorien und Tags fülle ich manuell aus.

---
title: "Neues Helferlein für Hugo erleichtert das Bloggen"
slug: neues-helferlein-fuer-hugo-erleichtert-das-bloggen
author: Natenom
date: 2024-01-05T20:25:55+01:00
categories:
  -
tags:
  -
---

Nächster Schritt

Das Script zeigt nun ein paar Infos an und auch, wie ich die Datei direkt in VSCode öffnen kann, weil ich das fürs Schreiben in Markdown verwende:

Page Bundle erfolgreich erstellt:
        Template: default
        Slug: neues-helferlein-fuer-hugo-erleichtert-das-bloggen
        Verzeichnis: /…/content/posts/2024/01/2024-01-05-neues-helferlein-fuer-hugo-erleichtert-das-bloggen
Hinweise:
        Pfad zur Datei in Zwischenablage eingefügt. In VSCodium öffnen mit 'Strg + o' und einfügen, Leerzeichen am Ende entfernen. (Das Leerzeichen am Ende kommt von VSCode.)

Blogbeitrag schreiben

Nun kann ich im bereits geöffneten VSCode die Tastenkombinatin Strg + o drücken, gefolgt von Strg + v, muss noch das Leerzeichen entfernen, das VSCode ans Ende angefügt hat, drücke Enter und kann anfangen, den Blogbeitrag zu schreiben.

Passt

So soll das sein. Wenn ich in Zukunft eine Idee habe, kann ich sofort anfangen, zu schreiben und bin nicht erst noch abgelenkt von den vielen verschiedenen Aufgaben, um die Datei für den Blogbeitrag erst noch erstellen zu müssen.

Das hat jetzt auch sehr gut funktioniert.

Kommentarfunktion via Isso für meinen Blog

Sat, 12 Aug 2023 20:38:03 +0200

Dank Isso ist es nun möglich, Kommentare hier im Blog zu schreiben. Zur Installation von Isso schreibe ich hier nichts, da gibt es eine gute Anleitung auf der Projektseite, aber ich schreibe etwas zur Motivation und zur Benutzung.

Vor einiger Zeit hatte ich hier schon einmal die Möglichkeit erläutert, Kommentare zu schreiben, obwohl das hier eine statische Website ist, die mit Hugo betrieben wird.

Wozu überhaupt Kommentare?

Wenn ich einen Blogbeitrag auf Social Media verlinke, bekomme ich dort Rückmeldungen dazu. Diese sind aber nur im Kontext Social Media zu finden und nicht, wenn man Blogbeiträge im Browser liest.

Nicht gut – Kommentare via Fediverse/Mastodon

Letztes Jahr hatte ich bereits Kommentare via Mastodon bzw. dem Fediverse ermöglicht, was jedoch ein paar Nachteile hatte. Hauptsächlich war es umständlich, denn ich musste für jeden Blogbeitrag, für den Kommentare möglich sein sollten, einen Toot auf Mastodon erstellen und darin den Blogbeitrag verlinken. Dann im Front Matter (Header des Blogbeitrags) die URL zum Toot eintragen und den Blog neu generieren. Das hatte ich dann auch nur ein paar Mal gemacht.

Weitere Nachteile:

Keine Moderation.
Nicht wirklich transparent für Menschen, die im Fediverse kommentieren. Dazu hatte ich mein Setup dann noch etwas komplizierter gestaltet, siehe hier.
Dass ich meine Toots immer mal wieder lösche, war nicht gerade hilfreich.

Besser – Kommentare via Isso

Hingegen gibt es bei Isso, das ich jetzt verwende, einige Vorteile:

Vorteile für Benutzer:

Für einen einstellbaren Zeitraum lassen sich bereits gesendete Kommentare vom Absender ändern. Derzeit sind das 5 Minuten.
Wenn die entsprechenden Cookies im Browser des Benutzers noch vorhanden sind, kann er eigene Kommentare wieder gelöscht werden.
Man kann auf andere Kommentare Bezug nehmen und dies ist später auch in der Struktur erkennbar.
Markdown kann verwendet werden.

Vorteile für mich als Betreiber:

Die Daten liegen auf meinem Server und ich kann sie jederzeit einfach vom Netz nehmen.
Die Daten liegen in einer Sqlite-Datenbank, die man einfach sichern kann.
Die Sqlite-Datenbank kann man direkt bearbeiten, entweder mit sqlite3 oder mit litecli.
Es gibt keine Metadaten, die in Blogbeiträgen enthalten sind. D. h. aus Sicht von Hugo muss nur das Script zum Laden/Schreiben von Kommentaren eingebunden werden. Dadurch kann man Kommentare auch nicht über die Suche finden.
Es gibt eine Moderation für Kommentare. Ich kann einen Kommentar vor dem Freischalten bearbeiten.
Isso kann auf einem anderen Server laufen und beherrscht auch Multisite, also das Bereitstellen der Kommentarfunktion für verschiedene Websites.

Hinweis

Ein Nachteil ist für mich, dass jetzt wieder eine dynamische Komponente auf dem Server läuft, die für den Betrieb von comments.natenom.de zuständig ist und hinter einem Nginx-Proxy läuft.

Die kann ich aber jederzeit abschalten und es würden keine Probleme daraus entstehen.

Local Storage, Cookies und IP-Adresse

Sobald man einen Kommentar abschickt, speichert der Browser für weitere Kommentare den angegebenen Namen, die E-Mail-Adresse und die URL im LocalStorage des Browsers. Diese Daten können später clientseitig vom Script ausgelesen und verwendet werden.

Des weiteren wird für jeden abgesendeten Kommentar ein Cookie gesetzt. Dieses wird auch nur vom JavaScript clientseitig ausgewertet und nur zur Authentifizierung an den Server geschickt, wenn man einen abgesendeten Kommentar ändern oder löschen möchte.

Serverseitig werden vom Benutzer die offensichtlichen Daten des Kommentars gespeichert und zusätzlich auch die IP-Adresse, wobei der letzte Teil auf Null gesetzt wird.

Ich habe für die neue Kommentarfunktion die Datenschutzerklärung im Blog entsprechend angepasst.

An die URL des Blogbeitrags gebunden

Für jeden Kommentar wird die URL des Blogbeitrags (ohne https://natenom.de am Anfang) gespeichert. Wenn man also nachträglich den Slug eines Beitrags ändert, dann werden Kommentare nicht mehr sichtbar sein, wenn man nicht auch in der Datenbank von Isso diese URL in den entsprechenden Kommentaren ändert.

Kommentarfunktion in einzelnen Beiträgen deaktivieren

Dank des Themes, das ich hier im Blog verwende (siehe unten im Footer), kann ich für einzelne Blogbeitrag Kommentare deaktivieren. Dazu füge ich im Front Matter eines Beitrags comment: false ein.

Man kann natürlich trotzdem über die API Kommentare für solche Beiträge abgeben. Aber erstens sind Kommentare im Blog moderiert und zweitens werden sie in solchen Beiträgen gar nicht erst durch den Browser abgerufen/geladen.

Recht auf Vergessen

Da ich das Recht auf Vergessen gut finde, werde ich noch etwas einrichten, um alle Kommentare zu löschen, die älter sind als x. Wie lange x sein wird, habe ich noch nicht entschieden.

Gespannt

Da es auch schon in der Vergangenheit, als der Blog noch mit WordPress betrieben wurde, nur selten Kommentare gab, bin ich gespannt, ob jetzt jemand diese Möglichkeit nutzen wird. Und vor allem, ob ich irgendwann von Spam oder sonst etwas genervt sein werde, und Kommentare wieder abschalten werde.

Es kann jedoch im Zweifel etwas dauern, bis ich Kommentare freigebe.

Projektseite

Hier die Projektseite von Isso.

Speziell die Clientkonfiguation fand ich hilfreich, siehe hier.

JavaScript für Kommentarfunktion in eigene Datei ausgelagert

Sun, 06 Nov 2022 17:25:07 +0100

Vri hat heute das System für Kommentare hier im Blog verbessert.

Vielen Dank dafür. ☺️

Sie hat das ganze JavaScript-Zeugs in eine eigene Datei ausgelagert und den Code angepasst. Dieser wird natürlich nur eingebunden, wenn im Front Matter die Kommentarfunktion aktiviert ist.

JavaScript

Hier die Datei mastodon-comments.js.

Hugo-Template

Das Template (layouts/partials/post/comments/custom.html) für Hugo sieht jetzt so aus:

{{ with .Params.comments }}
<div class="masto-comments datenschutz">
<p><a href="/ueber/datenschutz/#kommentare">(Datenschutzinformationen zu Kommentaren via Mastodon)a>p>
div>
<div id="mastodon-comments-wrapper" data-mastodon-host="{{ .host }}" data-mastodon-username="{{ .username }}" data-mastodon-id="{{ .id }}">
  <div id="mastodon-comments-buttons">
    <a class="btn btn-sm btn-outline-primary" href="https://{{ .host }}/interact/{{ .id }}?type=reply" target="_blank">Kommentar schreibena>
    <a class="btn btn-sm btn-outline-primary" href="https://{{ .host }}/@{{ .username }}/{{ .id }}" target="_blank">Tröt öffnena>
  div>
  <div id="mastodon-comments-list">
    <button id="load-comments" class="btn btn-sm btn-primary">Kommentare anzeigen (via Mastodon)button>
  div>
  <noscript><p>Du benötigst JavaScript, um die Kommentare hier anzeigen zu lassen.p>noscript>
  <script src="/my_js/purify.min.js">script>
  <script src="/my_js/mastodon-comments.js">script>
div>
{{ else }}
<p class="mastodon-comments nocomment">Kommentare sind für diesen Blogbeitrag (noch) nicht aktiviert. Nach der Veröffentlichung eines Blogbeitrags dauert das in der Regel noch ein paar Minuten.p>
{{ end }}
<p><details class="mastodon-comments email">
  <summary class="mastodon-comments email-summary">Alternative: Anmerkung per E-Mailsummary>
  <div class="mastodon-comments emailcontent">
    <p>Du kannst mir Anmerkungen zum Blogbeitrag per E-Mail schicken, <a href='mailto:user@tld.org?subject=Anmerkung zum Blog&body=Hallo Natenom. Zum Blogbeitrag "{{ $.Page.Permalink }}" habe ich eine Anmerkung:'>wenn du hier klicksta>. Der Inhalt davon bleibt privat und wird nicht hier im Kommentarbereich veröffentlicht.p>
  div>
details>p>

CSS

Beim CSS hat sich nichts geändert und das gibt es hier.

Kommentare in meinem statischen Blog via Mastodon

Tue, 01 Nov 2022 20:01:42 +0100

Seit dem Umzug meines Blogs von WordPress hin zu einer statischen Website Anfang des Jahres hatte ich ganz leicht, aber wirklich nur ganz bisschen die Kommentarfunktion vermisst. Es gab hier sowieso nur selten Kommentare. Eine Interaktionsmöglichkeit ist aber trotzdem schön.

Deshalb haben wir heute die Möglichkeit im Blog integriert, in dafür freigeschalteten Blogbeiträgen per Mastodon zu kommentieren.

Vielen Dank an die Menschen, die mir auf Mastodon auf meine Frage hin antworteten. Darüber konnte ich diesen Blogbeitrag finden, der das Vorgehen für Hugo erklärt.

Update

2022-11-06: Die Einbindung von Kommentaren aus Mastodon erfolgt jetzt transparent, siehe hier.

Was ist Mastodon?

Mastodon ist ein Teil vom Fediverse. Jeder Mensch kann dort einen Account bei einem beliebigen Anbieter einer Instanz erstellen.

Man kann sich das vorstellen wie bei E-Mails. Jeder Mensch hat einen anderen E-Mail-Anbieter und kann trotzdem mit jedem anderen Menschen auf der Welt kommunizieren.

Vorab: Wie es funktioniert

Für Menschen, die kommentieren

Entweder nach unten scrollen oder rechts auf die Sprechblase (rechts oben im Blogbeitrag) klicken. Dann landet man hier:

Dann “Kommentare anzeigen (via Mastodon)” anklicken:

Oder einen der oberen Links anklicken, um zu kommentieren oder den Tröt in einem neuen Tab zu öffnen.

Um zu kommentieren, benötigt man entweder einen Mastodon-Account, einen Friendica-Account oder irgend einen anderen Account eines Dienstes des Fediverse.

Für mich als Betreiber des Blogs

Blogbeitrag veröffentlichen.
Link zum Blogbeitrag auf Mastodon tröten.
Im veröffentlichen Blogbeitrag im Front Matter einfügen:

comments:
  host: social.anoxinon.de
  username: natenom
  id: 123456789…

Blogbeitrag erneut veröffentlichen mit dem geänderten Front Matter.

Die ID ist die lange Zahl am Ende des Links eines Tröts (Toots).

Ich habe bewusst entschieden, den Host immer im Front Matter des Blogbeitrag zu hinterlegen, statt ihn global in der Konfiguration von Hugo zu hinterlegen. Denn es könnte sein, dass ich zukünftig eine andere Instanz verwenden werde und dann sollten bisherige Kommentare weiterhin zugreifbar bleiben.

Der Nachteil dieser Lösung ist, dass es immer etwas dauert (da der Blog neu generiert wird), bis Kommentare im Blog eingebunden werden können, obwohl es bereits einen Tröt auf Mastodon gibt. Das macht aber nichts, da man trotzdem bereits auf Mastodon antworten kann und diese Antworten später auch über den Blog sichtbar sind.

(Man könnte auch kurz vor dem Veröffentlichen des Beitrags bereits einen Mastodon-Tröt zum Blogbeitrag schreiben, müsste dann aber das Vorschaubild und den Titel manuell eintragen und würde nur wenig Zeit sparen.)

Umsetzung für meinen Blog

Hier die Anleitung, wie wir das mit dem hier verwendeten Theme “Hugo Theme Bootstrap” umgesetzt haben.

Wir haben den Quelltext des oben bereits genannten Blogbeitrags an den Blog angepasst.

Info

Vielen Dank an Vri, die dafür gesorgt hat, dass das Ergebnis schön aussieht.

Template

Dieser Quelltext kommt in die Datei layouts/partials/post/comments/custom.html:

Quelltext der Datei

Wie man im Blog (Hugo) ein eigenes Bild für die Suchseite einstellt

Tue, 27 Sep 2022 02:50:03 +0200

Wenn man früher einen Link zur Suchseite hier im Blog auf Social Media geteilt hatte, wurde immer nur das Natenom-Logo im Twitter-Card angezeigt, denn das war der Default fürs “Beitragsbild”.

Ich wollt jedoch nur für die Suche ein eigenes Bild haben. Einen kleinen Elefanten, der so aussieht, als ob er was suchen würde.

Ich fragte den Entwickler und er erklärte, dass die Suchseite letztlich eine normale Seite ist und man dort im Front Matter Dinge angeben kann, so wie z. B. das Beitragsbild.

Der Quelltext der Suchseite blog/content/search/_index.md sieht jetzt so aus:

---
title: "Suche"
layout: "search"
images:
  - /images/search.webp
---

Und das Bild liegt in blog/static/images/.

Teilt man nun einen Link zur Suchseite mit einem beliebigen Suchbegriff, dann wird nicht mehr das Natenom-Logo verwendet sondern dieses schöne Bild vom kleinen Elefanten (später dann eines mit einer Lupe, das ich noch machen muss):

Jetzt steht unter dem Bild aber noch der Standardtext über den Blog. Mit description: im Front Matter kann man hier einen anderen Text hinterlegen:

description: 'Der kleine Elefant ist so nett und durchsucht den Blog für dich nach verschiedenen Begriffen…'

Ergebnis:

Wechsel von Kate zu VSCodium für Markdown

Sun, 11 Sep 2022 17:01:07 +0200

In dem Zeitraum, als ich meinen Blog und mein Wiki auf Hugo umgestellt hatte, suchte ich lange nach einem guten Editor für Markdown und probierte viele Editoren aus und bin letztlich beim bis dahin sonst immer verwendeten Editor Kate geblieben. Denn die meisten getesteten Editoren hatten keine Snippets-Funktion und andere Editoren waren mir zu überladen (z. B. solche, die auf Electron basieren).

Doch nach mehreren Monaten und vielen geschriebenen Blogbeiträgen fehlen mir ein paar Funktionen in Kate, die Zeit und Nerven fressen oder umständliche “Lösungen” brauchen.

Was mir in Kate besonders fehlt:

Live-Vorschau (wenn auch nicht alle Shortcodes gerendert werden können).
Ordentlich funktionierende Snippets mit Zusatzfunktionen (die in Kate sind nur rudimentär und zudem buggy).
Inhaltsverzeichnis mit der Möglichkeit, zu einem Eintrag zu springen.
Distraction free writing (oder zumindest einigermaßen ordentliche Vorschau). Hierfür habe ich in VSCodium noch keine Lösung gefunden.

Ich probierte einige der bereits getesteten Editoren noch einmal aus und am besten gefiel mir MarkText, doch das kann leider keine Snippets.

Deshalb habe ich mich für VSCodium entschieden, einer etwas freieren Variante von Visual Studio Code. Die basiert zwar auf Electron, aber ich jetzt bereit, diesen Kompromiss einzugehen, um dafür viele schöne Funktionen zu bekommen.

In VSCodium gibt es – im Unterschied zu Kate – einige Funktionen, die ich folgend beschreibe.

Hinweis

Eine ältere Liste nützlicher Erweiterungen speziell für Hugo gibt es auf der Hugo-Projektseite.

Und hier ist die Dokumentation für VSCodium für den Umgang mit Markdown.

Erweiterungen

Für VSCodium gibt es extrem viele Erweiterungen (die ich bisher nicht benötige, aber vielleicht finde ich doch noch hilfreiche Dinge).

Für Kate gibt es Plugins, aber nicht annähernd so viele.

Live-Vorschau

An der Live-Vorschau gefällt mir besonders, dass

sie automatisch mit scrollt.
es links immer einen Indikator gibt, der anzeige, in welcher Zeile der Cursor gerade ist.
man optional trotzdem unabhängig vom Code in der Vorschau scrollen kann, diese aber wieder synchron läuft, sobald man im Quelltext scrollt.
der Cursor bei einem Doppelklick auf einen Bereich in der Vorschau automatisch auf diese Zeile im Quelltext gesetzt wird.

Die Vorschaufunktion gibt zwar nicht genau wieder, wie es später im Blog oder im Wiki aussehen wird, aber es ist ausreichend, sodass ich während des Schreibens den Hugo-Server gar nicht erst anwerfen muss, außer zum Schluss mal wegen Shortcodes, die nicht dargestellt werden, wie figure.

Die Vorschau öffent man mit der Tastenkombination Ctrl + k gefolgt von v.

Inhaltsverzeichnis

Es gibt drei Möglichkeiten, ein Inhaltsverzeichnis des aktuellen Dokuments zu sehen:

Mit der Tastenkombination Strg + Shift + o öffnet man das Inhaltsverzeichnis und kann zu einer bestimmten Überschrift springen.
Die aktuelle Überschrift wird auch immer oben in den Breadcrumbs angezeigt. Dort kann man drauf klicken und kann auch wieder zu den Bereichen springen.
In der Leiste links öffnet man den Explorer oder drück die Tastenkombination Ctrl + Shift + e und öffnet unten den Bereich OUTLINE.

Snippets

In VSCodium kann man tolle Dinge mit Snippets machen, die ich teilweise auch schon vom Editor Micro kenne.

Die Dokumentation für Snippets in VSCodium gibt es hier.

Hier einige der Möglichkeiten.

Eigene Snippets trägt man in eine selbst gewählte Datei ein, die man über Ctrl + Shift + p gefolgt von Snippets: Configure User Snippets definieren und öffnen kann.

Tabstops

In Snippet kann man Positionen definieren, zu denen man nach dem Einfügen mit der Tab-Taste springen kann, sodass man notwendige Eingaben schneller erledigen kann, also mit den Cursor-Tasten zu navigieren. Das nutze ich z. B. in meinem Front Matter-Snippet.

Vorauswahl

Hier bekommt man ein kleines Popup-Fenster und kann einen der Einträge auswählen:

Das Snippet dazu sieht so aus:

"notice": {
		"scope": "markdown",
		 "prefix": "md-notice",
		 "body": [
			"{{< notice ${1|hinweis,tipp,info,warnung,update|} >}}",
			"$0",
			"{{< /notice >}}"
		 ],
		 "description": "Notice, tip, info, …"
	}

Snippets auf markierte Bereiche anwenden

Um einen aktuell im Editor markieren Bereich innerhalb eines Snippets nutzen zu können, gibt es die Variable ${TM_SELECTED_TEXT} und weitere (siehe hier). Diese Möglichkeit bietet sich an, wenn man z. B. nachträglich einen Bereich als Codeblock oder Zitat formatieren will.

Hat man so ein Snippet geschrieben, markiert man zuerst den benötigen Bereich, drückt Alt + Leertaste, und wählt anschließend das Snippet mit den Cursor-Tasten aus.

Seltsam wird es, wenn man den Eintrag nicht per Cursor-Taste auswählt, sondern, wie sonst auch, den Namen des Snippets tippt. Dann überschreibt man nämlich den markieren Bereich. Doch das macht nichts. Sobald man den passenden Eintrag ausgewählt hat und sofern das Snippet die genannte Variable nutzt, wird beim Bestätigen mit Enter das komplette Snippet inklusive dem überschrieben geglaubten Bereich eingefügt.

Datum fürs Front Matter direkt statt über Shell

Beim Einfügen meines eigenen Snippets frontmatter ist jetzt direkt das aktuelle Datum enthalten. Bisher musste ich das immer erst über ein Shellkommando machen und dann ins Front Matter einfügen. Theoretisch ginge das auch mit Kate und JavaScript, aber das habe ich bisher nicht geschafft.

So sieht dann das Front Matter nach dem Einfügen aus:

---
title:
slug:
date: 2022-09-11T12:40:57+02:00
draft: false
author: Natenom
#description:
categories:
  -
tags:
  -
---

Und das ist das zugehörige Snippet:

"md-frontmatter": {
  "scope": "markdown",
    "prefix": "md",
    "body": [
    "---",
    "title: $1",
    "slug: $2",
    "date: $CURRENT_YEAR-$CURRENT_MONTH-${CURRENT_DATE}T${CURRENT_HOUR}:$CURRENT_MINUTE:$CURRENT_SECOND+02:00",
    "draft: false",
    "author: Natenom",
    "#description: ",
    "categories:"
    "  - $3",
    "tags:",
    "  - $4",
    "---"
    ],
    "description": "Front Matter Blog"
}

Tastenkombinationen

Eine Liste der Tastenkombinationen für VSCodium.

Merk dir was

Besonders gut gefällt mir, dass man ein “Verzeichnis” mit Ctrl + k gefolgt von Ctrl + o öffnen kann und der Editor sich dafür dann die geöffneten Dateien und Ansichten merkt.

So kann ich zwischen Blog und Wiki sehr einfach wechseln und die bearbeiteten Dateien sind weiterhin geföffnet. Das erleichtert die Arbeit.

Alternativ nutzt man die Tastenkombination Ctrl + r und kann dann bisher geöffnete Dateien und oben genannte Verzeichnisse wieder öffnen. Hält man Ctrl dabei gedrückt, werden diese in einem neuen Fenster geöffnet.

Hier z. B. die Ansicht für die Arbeit im Wiki, wo gerade die Selfies vom kleinen Elefanten geöffnet sind:

Meine Anpassungen und installierte Erweiterungen

Ich habe ein paar kleine Anpassungen für VSCode, die ich hier aufliste, falls ich das irgendwann mal wieder brauche.

Weniger ist mehr

Ich habe die “Status bar” (View -> Appearence -> Status bar) unten und die “Menu bar” (View -> Appearence -> Menu bar) oben ausgeblendet.

Falls man die “Status Bar” wieder benötigt, kann man sie mit Ctrl + Shift + p und der Eingabe von View: Toggle Status Bar Visibility oder Teilen davon wieder aktivieren.

Für die “Menu bar” gibt man View: Toggle Menu bar ein. Oder man drückt die Alt-Taste, dann erscheint die Menübar, wird direkt fokusiert, und verschwindet dann wieder, sobald man einen Eintrag gewählt hat oder erneut die Alt-Taste drückt.

Hervorhebung der aktuellen Zeile

Die Hervorhebung der aktuellen Zeile gefällt mir bei VSCodium gar nicht, deshalb habe ich das so angepasst, wie ich es von Kate gewohnt bin.

Dazu öffnet man die Datei settings.json via Strg + Shift + p und der Eingabe von Preferences: Open User Settings (JSON) und trägt ein:

"workbench.colorCustomizations": {
    "[Default Dark+]": {
        "editor.lineHighlightBackground": "#4587de2a",
        "editor.lineHighlightBorder": "#4587de2a"
    },
    "[Default Light+]": {
        "editor.lineHighlightBackground": "#4587de2a",
        "editor.lineHighlightBorder": "#4587de2a"
    }
}

Zeilenhervorhebung ohne Anpassung im Dark Theme mit kaum sichtbarer Umrandung:

Und mit Anpassung:

Damit zusätzlich auch noch die Zeilennummer hervorgehoben wird, fügt man hinzu:

"editor.renderLineHighlight": "all",

Installierte Erweiterungen

streetsidesoftware.code-spell-checker-german für Rechtschreibüberprüfung

Fazit

Ich habe diesen Blogbeitrag schon mit VSCodium geschrieben und währenddessen hier dokumentiert und ausprobiert.

Mein Fazit bisher ist, dass ich mich mit diesem Editor besser auf Inhalte fokussieren kann, da ich nicht ständig andere Tools benutzen muss. Wie z. B. eine Konsole für das aktuelle Datum und die Uhrzeit fürs Front-Matter, weil man auch Bilder (zumindest in der Markdown-Standard-Syntax) über den Dateiexplorer von VSCodium direkt einfügen kann.

Desweiteren brauche ich kein laufendes Hugo und keinen Browser, in dem die Vorschau angezeigt wird. Diese zeigt zwar genau das Ergebnis, wie es auch später online aussehen wird, aber das ist für meine Sachen meist nur zur Endkontrolle vor dem Veröffentlichen notwendig.

Ich kann mir vorstellen, dass man das Bauen mit Hugo auch noch in VSCodium einrichten könnte, aber ich mache das lieber extern. Ich brauche einen guten Editor zum Bearbeiten, aber keine eierlegende Wollmilchsau für alles zusammen.

Ein Python-Script für die Arbeit mit Hugo (Update 2024-01-09)

Thu, 24 Mar 2022 05:35:39 +0100

Bei der Umstellung meines Blogs auf Hugo hatte ich mehrere Shell-Aliase in der .bashrc erstellt, um die Arbeit einfacher zu gestalten, wie z. B. eine tmux-Session im Verzeichnis der Website starten, nach Seitennamen, Kategorien und Tags zu suchen und einiges mehr. Es wurden immer mehr Aliase und es war nicht wirklich flexibel sondern nur richtig hacky.

Update

Update (2024-01-09): Ich habe eine ganz neue Version des Python-Scripts veröffentlicht, das deutlich mehr kann, siehe in diesem Blogbeitrag.

Spätestens seitdem ich auch mein neues Wiki mit Hugo nutze, funktionieren die vielen Aliase nicht mehr, denn ich bräuchte alles doppelt, um auch die Arbeit mit meinem Wiki damit bewerkstelligen zu können. Flexibel ist anders.

Und weil auch Vri in Zukunft in der Lage sein soll, sowohl im Wiki als auch im Blog Dinge zu tun, musste ich da was Schönes bauen. Denn meine vorherige Frickellösung könnte ich guten Gewissens niemandem zumuten.

Also habe ich heute Nacht ohne Ahnung und viel $Suchmaschine ein Python-Script erstellt, das die ganzen Shell-Aliase ersetzt und jetzt für beliebig viele Webseiten funktioniert. Und dabei habe ich sogar einen fiesen Bug in der Plasmashell gefunden.

Was kann das Script?

Mit dem neuen Script kann ich sehr einfach:

Eine Website generieren lassen.
Eine Website hochladen (mit rsync synchronisieren).
Die beiden oberen Dinge in einem Aufruf.
Eine Website lokal zur Verfügung stellen (hugo server).
Eine tmux-Session innerhalb des lokalen Verzeichnisses starten, um dort z. B. git zu verwenden.
(Nur im Blog) nach verwendeten Tags und nach Kategorien suchen. Dabei funktionieren sowohl einfache Strings als auch Reguläre Ausdrücke.
Mittels grep -r suchen.
Aktuelle Uhrzeit inklusive Datum und Zeitzone erhalten. Für das Front Matter (Metadaten einer einzelnen Seite).

Hier z. B. die Suche nach allen Seiten im Blog, in denen der String hugo vorkommt:

[…]
content/posts/2016/2016-12-02-hugo-kann-mehrsprachig.md,,Hugo kann mehrsprachig :),2016-12-02T13:29:05Z,0001-01-01T00:00:00Z,2016-12-02T13:29:05Z,false,/2016/12/hugo-kann-mehrsprachig/

content/posts/2015/2015-12-10-gpeasy-php-durch-hugo-statisches-html-ersetzt.md,,gpEasy (PHP) durch Hugo (statisches HTML) ersetzt,2015-12-10T13:05:11Z,0001-01-01T00:00:00Z,2015-12-10T13:05:11Z,false,/2015/12/gpeasy-php-durch-hugo-statisches-html-ersetzt/

Format: path,slug,title,date,expiryDate,publishDate,draft,permalink
Results for 'hugo': 27

Externe Konfiguration

Die Konfigurationsdatei mit den Einstellungen für beliebig viele Websites liegt in ~/.config/hugo-noms.conf.

Hilfe

Da das Script argparse verwendet, gibt es automatisch eine schöne Hilfe: ¹

usage: hg.py [-h] [--site SITE_NAME | --time | --printconfig | --sites]
             [--cd | --build | --upload | --deploy | --tmux | --serve | --serve_light]
             [--searchpost SEARCHPOST | --searchgrep SEARCHGREP | --searchtag SEARCHTAG | --searchcat SEARCHCAT]

Handles hugo stuff.

optional arguments:
  -h, --help            show this help message and exit
  --site SITE_NAME      Name of the website to work on currently.
  --time                Copy current date and time to clipboard.
  --printconfig         Print the devices configuration.
  --sites               Print sites from configuration
  --cd                  Change directory to workdir of site.
  --build               Build a site.
  --upload              Build AND upload site to remote.
  --deploy              Deploy (build AND upload) a site.
  --tmux                Start the tmux session for --site.
  --serve               Serves site (full).
  --serve_light         Serves site (light).
  --searchpost SEARCHPOST
                        Find pages/posts containing search term in 'path, slug, title, date or permalink'.
                        Strings and Regular Expressions (regex) are allowed.
  --searchgrep SEARCHGREP
                        Find pages/posts containing search term in file content. Uses 'grep -r'. Strings and
                        Regular Expressions (regex) are allowed.
  --searchtag SEARCHTAG
                        Find tags containing search term. Strings and Regular Expressions (regex) are allowed.
  --searchcat SEARCHCAT
                        Find categories containing search term. Strings and Regular Expressions (regex) are
                        allowed.

Wo gibts das Script?

Vielleicht kann das ja noch jemand gebrauchen. Ich weiß aktuell nicht, wo ich es hinschubsen könnte, daher liegt es jetzt erst einmal in meinem Wiki im neuen Bereich Hugo, siehe hier.

Nur noch zwei Aliase

Da ich ein extrem fauler Mensch bin, habe ich aber später trotzdem noch zwei Aliase in der .bashrc definiert:

alias hgb='/pfad/zu/hg.py --site blog'
alias hgw='/pfad/zu/hg.py --site wiki'

Somit kann ich z. B.

hg.py --site blog --tmux

abkürzen mit

hgb --tmux

🙂

Bug in Plasmashell

Ruft man ein Script mit diesen beiden Zeilen auf oder führt es in iPython aus, dann hängt sich die Plasmashell entweder für ein paar Sekunden, lange oder komplett auf. Der String landet trotzdem nicht in der Zwischenablage obwohl xclip als auch xsel installiert sind.

import pyperclip
pyperclip.copy("text")

Ich wollte diese Funktion nutzen, um einen generierten String mit Datum, Uhrzeit und Zeitzone in die Zwischenablage zu kopieren, um diesen dann im Front Matter eines Blogbeitrags manuell über die Zwischenablage einfügen zu können. Stattdessen nutze ich jetzt os.system("date … | xsel …").

schlechtes Englisch darf behalten werden 🙂 ↩︎

Umzug von DokuWiki nach Hugo – Teil 2 – Export mit Pandoc

Thu, 17 Mar 2022 00:56:09 +0100

Es gibt verschiedene Tools, um die Inhalte eines DokuWiki von dessen eigener Syntax nach Markdown zu konvertieren, welches in Hugo verwendet wird. Die Auswertung davon gibt es hier.

Ich habe mich für Pandoc entschieden.

Export mit Hilfe von Pandoc

Der grundsätzliche Aufruf für den Export via Pandoc ist:

find path/to/pages/ -iname "*.txt" -exec pandoc --wrap=none -s --from=dokuwiki --to=gfm -o "{}.md" '{}' \;

Der Parameter --wrap=none ist wichtig, weil sonst Zeilen immer nach 72 Zeichen einen Zeilenumbruch bekommen. Dokumentation hierzu siehe hier im Bereich “wrap”.

Die erstellten .md-Dateien liegen jetzt immer an der selben Stelle wo auch die .txt-Datien liegen.

Hinweis

Man benötigt eine Pandoc-Version ab mindestens 2.11.3, da sonst Interwiki-Links durch Links zu Google ersetzt werden. Siehe im Bereich “Dokuwiki reader” der Release Notes von Pandoc.

Da es in Debian selbst in Unstable nur Version 2.9 gibt, kann man manuell die neueste Version installieren, siehe hier.

.txt-Dateien löschen

Die alten .txt-Dateien können jetzt gelöscht werden mit:

find path/to/pages/ -name "*.txt" -execdir rm '{}' \;

Front Matter

Damit Dateien überhaupt in Hugo gerendert werden, müssen sie ein rudimentäres Front Matter haben, das zumindest z. B. den Titel enthält:

---
title: Müllsammeln
---

Für das Hinzufügen dieses rudimentären Front Matters (mit dem Dateinamen als Titel) habe ich das Script von hier angepasst und hinzugefügt, dass auch die erste H1-Überschrift in jeder Datei entfernt wird, da Hugo diese beim Rendern der Website automatisch aus dem titel: generiert. Zusätzlich wird noch das .txt aus den Dateinamen entfernt.

#!/bin/bash

filepath="$1" #path/to/filename.md
file_name=$(basename $filepath) #filename.md

md='.txt.md'
title=${file_name%$md} #filname
newname="${title}.md" #filename.md

TEMPLATE="---
title: $title
---

# Remove first line of file (with # Title)
sed -i '1d' "${filepath}"

echo "$TEMPLATE" | cat - "$filepath" > temp && mv temp "${filepath%$md}.md"
rm ${filepath}

Der Aufruf ist:

find pages/ -name "*.md" -print0 | xargs -0 -I file path/to/prepend.sh file

Fertig

Im Ergebnis erhält man die komplette Verzeichnisstruktur eines DokuWiki mit Dateien im Markdown-Format.

Zusätzlich benötigt man aber noch die Medien-Dateien (Fotos, Screenshots, Videos, usw.) aus dem DokuWiki.

Verzeichnisstruktur der .md-Dateien

Hier ein Auszug aus der Verzeichnisstruktur meines exportierten Wikis:

.
└── pages
    […]
    ├── sport
    │   ├── fahrrad
    │   │   ├── hunde.md
    │   │   ├── kleidung
    │   │   │   ├── armlinge_und_beinlinge.md
    │   │   │   ├── baselayer.md
    │   │   │   ├── handschuhe.md
    │   │   │   ├── hose.md
    │   │   │   ├── lenkerstulpen
    │   │   │   │   ├── 45nrth.md
    │   │   │   │   └── einfache_variante.md
    │   │   │   ├── lenkerstulpen.md
    │   │   │   ├── schuhe.md
    │   │   │   ├── sicherheitsweste.md
    […]

Verzeichnisstruktur der Medien-Dateien

Zusätzlich benötigt man natürlich noch die Dateien aus media/.

Auch hier ein Auszug aus den entsprechenden Verzeichnissen meines alten Wikis:

    […]
├─ sport
│   └── fahrrad
│       ├── 2019-06_kamera_befestigung_am_rueckspiegel_1.jpeg
│       ├── 2019-06_kamera_befestigung_am_rueckspiegel_2.jpeg
│       ├── 2020-07_kamera_setup_vorne_1.jpg
│       ├── 2020-07_kamera_setup_vorne_2.jpg
│       ├── 2020-07_kamera_setup_vorne_3.jpg
│       ├── 2020-12_kamerabefestigung_lenkertaschenhalter_01.jpg
        […]

Tools zum Export von DokuWiki nach Markdown (Hugo)

Wed, 16 Mar 2022 14:47:37 +0100

Da ich mein DokuWiki auf Lange Sicht nach Hugo umziehen möchte, habe ich mir verschiedene Möglichkeiten angesehen, die Daten zu exportieren und ins Format Markdown zu überführen, welches in Hugo verwendet wird.

DokuWiki-to-Markdown-Converter

Link zum Konverter

Aufruf:

find path/to/pages/ -name "*.txt" -exec php convert.php '{}' \;

Danach gibt es sowohl die alten .txt-Dateien als auch die neuen .md-Dateien in pages/. Jetzt können wir die alten Dateien löschen:

find path/to/pages/ -name "*.txt" -execdir rm '{}' \;

Das Ergebnis ist eine Verzeichnisstruktur von pages, die nur noch .md-Dateien ohne Front Matter enthält.

Pro und Kontra von DokuWiki-to-Markdown-Converter

Pro
- Konvertiert Tabellen
- Konvertiert ins Github flavored Markdown
- Konvertiert eingebettete Bilder, auch mit Bildbeschreibungen.
Kontra
- Das Tool erstellt kein Front Matter.
- Keine Konvertierung von Fußnoten.
- Leerzeile auch zwischen zusammen gehörigen Listen
- Hat Probleme bei Titeln von Tabellen (gibt es keine Überschrift, dann wird die erste Zeile zur Überschrift).

DokuWiki-to-Hugo

Link zum Konverter

Aufruf:

python src/main.py --dir='path/to/pages/'

Das Ergebnis ist eine neue Verzeichnisstruktur von pages, die nur noch .md-Dateien ohne Front Matter enthält.

Pro und Kontra von DokuWiki-to-Hugo

Pro
- Erzeugt Front Matter, allerdings im TOML-Format
Kontra
- Bei mir wurde nur das Front Matter zur exportierten Datei hinzugefügt, jedoch keinerlei Konvertierung der Dateiinhalte vorgenommen.
- Selbst wenn es funktionieren würde, so gibt es nur Konvertierungen für relativ wenige Elemente.

Pandoc

Link zum Konverter

Aufruf:

find path/to/pages/ -iname "*.txt" -exec pandoc --wrap=none -s --from=dokuwiki --to=gfm -o "{}.md" '{}' \;

Der Parameter --wrap=none ist wichtig, da sonst in jeder Zeile nach 72 Zeichen ein Zeilenumbruch eingefügt wird. Dokumentation dazu gibt es hier im Bereich “wrap”.

Hinweis

Man benötigt eine Pandoc-Version ab mindestens 2.11.3, da sonst Interwiki-Links durch Links zu Google ersetzt werden. Siehe im Bereich “Dokuwiki reader” der Release Notes von Pandoc. Da es in Debian selbst in Unstable nur Version 2.9 gibt, kann man manuell die neueste Version installieren, siehe hier.

Pro und Kontra von Pandoc

Pro
- Konvertiert Fußnoten und viele andere Dinge.
Kontra
- Kein Front-Matter (natürlich nicht, ist ein Konverter, kein Hugo-Exporter). Der lässt sich aber rudimentär selbst einfügen.
- Konvertiert eingebettete Bilder in img-Tags statt in die Markdown-Syntax.

Fazit

Pandoc gefällt mir von den getesteten Möglichkeiten am besten. Wie ich das genau benutzt habe, um die Inhalte meines Wikis zu exportieren, schreibe ich in einem eigenen Blogbeitrag und werde diesen hier verlinken.

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.

Ein neues Helferlein für die Arbeit mit Hugo

Wed, 09 Feb 2022 20:14:06 +0100

Bevor ich einen Blogbeitrag veröffentliche, möchte ich meist das aktuelle Datum mit Uhrzeit im Front Matter eintragen. Dieser Wert bestimmt, wann laut Blog der Beitrag veröffentlicht wurde. Den benötigten String erstellt mir ein Alias in der .bashrc:

alias hugo-date-now='date +"%Y-%m-%dT%H:%M:%S%:z" | xsel -i -b ; echo "Check your clipboard :)"'

Da man in meinem Editor Kate direkt eine Konsole starten kann, tue ich das, gebe hugo-date-now ein und als Ergebnis befindet sich der benötigte String mit aktuellem Datum und Uhrzeig in der Zwischenablage. Den kann ich dann im Front Matter eintragen, z. B. für diesen Blogbeitrag hier:

2022-02-09T20:14:06+01:00

Twitter Cards, Open Graph und Artikelbilder im Hugo-Theme hugo-theme-bootstrap

Mon, 07 Feb 2022 10:41:13 +0100

Es gibt Neuerungen im Theme hugo-theme-bootstrap, das hier im Blog verwendet wird. Könnte interessant sein für Menschen, die das Theme auch verwenden.

Artikelbilder

Vor dem Update

Bisher wurde als Beitragsbild das erste Bild in der Liste der Bilder der Variable images: im Front Matter verwendet:

images:
  - relativer-pfad/bild.jpg

# Ergebnis: /blogbeitrag-titel/relativer-pfad/bild.jpg

Oder:

images:
  - /absoluter-pfad/bild.jpg

# Ergebnis: /absoluter-pfad/bild.jpg

Nach dem Update

Seit dem Update hat sich das verändert. Relative Pfade sind nicht mehr relativ zum aktuellen Beitrag bzw. Page Bundle sondern immer relativ zum static-Verzeichnis der Website:

images:
  - relativer-pfad/bild.jpg

# Ergebnis: /relativer-pfad/bild.jpg

Dann gibt es noch die Neuerungen, dass fürs Artikelbild automatisch das erste gefundene Bild eines Page Bundles verwendet wird, wenn folgender Dateiname passt (in dieser Reihenfolge) UND KEINE Variable images im Front Matter definiert ist:

*feature*
*cover*
*thumbnail*

Hierbei sollte ein Bild verwendet werden, das in den Breiten von 180 Pixel und um 500 Pixel noch gut aussieht, da die Artikelbilder in der normalen Ansicht sehr klein und in der mobilen Ansicht sehr groß angezeigt werden.

Vielleicht könnte man hier noch einen Feature Request stellen, damit für das verwendete Bild automatisch die benötigten Größen von Hugo generiert werden. Technisch ist das möglich.

Twitter Card und Open Graph

Für die Twitter Card und den Open Graph wird immer das Artikelbild verwendet. Gibt es kein Artikelbild, dann nutzen Twitter Card und Open Graph das in der config.toml eingestellte Bild der Variable logo=. Vor dem Update gab es in letzterem Fall gar kein Bild.

Die Lösung mit dem logo finde ich nicht gut. Denn normalerweise wird das Logo auf der Website oben nur in 30x30 Pixeln dargestellt, auf Twitter oder anderen Social-Media-Plattformen aber mit über 500 Pixeln. Auch hier wäre es meiner Ansicht nach möglich, automatisch die Größenvarianten des Logos von Hugo erstellen zu lassen.

Somit wurde die Handhabung im Theme an die Funktionsweise in Hugo selbst angeglichen.

Beispiel einer Twitter Card

Nextcloud Editor für Markdown-Dateien zerstört Front Matter von Hugo

Sun, 06 Feb 2022 17:19:55 +0100

Ich benutze Nextcloud, um die Markdown-Dateien für meinen Blog auf verschiedenen Geräte bearbeiten zu können. Der Blog wird mit Hugo generiert.

Dabei habe ich bemerkt, dass der Editor, der per Voreinstellung sowohl im Browser in Nextcloud als auch in der Android-App benutzt wird, das Front Matter der Dateien nach dem Bearbeiten zerstört.

Aus:

title: Linkdump KW FIXME/2022
url: /2022/xx-linkdump-kw-FIXME-2022
date: 2022-02-06T14:16:09+01:00
author: Natenom
description: Linkdump für Kalenderwoche FIXME/2022
#disable_lightbox: true
images:

- featured.png
  categories:
- Linkdump
  tags:
- FIXME

---

wird:

---

title: Linkdump KW FIXME/2022 url: /2022/xx-linkdump-kw-FIXME-2022 date: 2022-02-06T14:16:09+01:00 author: Natenom description: Linkdump für Kalenderwoche FIXME/2022 #disable_lightbox: true images:

- featured.png categories:
- Linkdump tags:
- FIXME

---

Bei Verwendung der Nextcloud-App sollte man also besser eine eigene App zur Bearbeitung verwenden. Ich nutze auf Android den Editor Markor.

Möchte man Markdown-Dateien auch im Browser bearbeiten, so kann man zusätzlich zum Standardeditor auch einen anderen installieren. Z. B. files_markdown.

Über die drei Punkte rechts wählt man ihn zum Öffnen der Datei aus:

Öffnen mit Dialog in Nextcloud

Der Editor zeigt wahlweise nur den Quelltext an, Quelltext und Vorschau oder nur die Vorschau.

Alternativer Editor mit Vorschaufunktion

Für mich passt das. So kann ich auch mal im Browser meine Blogbeiträge bearbeiten.

Schön wäre, wenn man in Nextcloud einstellen könnte, dass Dateien immer mit dem neuen Editor geöffnet werden, damit man nicht versehentlich doch mal eine Datei kaputt macht. Weiß jemand, wie das geht? Falls ja, bitte unten bei “Kommentar” eine E-Mail schicken :) Danke.

Umzug von WordPress zu Hugo – Teil 2 – Bestandsaufnahme und Korrekturen

Thu, 03 Feb 2022 10:10:33 +0100

Im ersten Teil ging um die Gründe meines Wechsels von WordPres zu Hugo und wie man den Wechsel technisch umsetzt und am Ende einen lauffähigen Blog mit Hugo hat, dem man im Browser lokal anschauen kann.

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.

Unscharfes Bild

So sah der Beitrag ursprünglich in WordPress aus:

Wie es in WordPress aussah

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:

Große Variante des Bildes wird in der Lightbox geladen

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:

Dank Eingettung des Originals ist es wieder scharf, verursacht aber auch mehr Traffic.

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.

Video hängt hinter der Seitenleiste

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.

Video ist wieder richtig

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.

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.