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.

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:

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

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 …").

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;

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.

http://regexr.com/

Da ich mir nicht unbedingt die Zeit nehmen möchte, jeden Artikel einzeln zu ändern und dieser „Weiterlesen“-Link letztlich nur ein ausgewerteter HTML-Kommentar ist, wurde das Plugin Search Regex genutzt. Damit kann man in Artikeln alle Vorkommen von Zeichenkette A durch Zeichenkette B ersetzen lassen; in unserem Fall „<!–more–>“ durch „<!–offmore–>“:

[][3]

Es ist übrigens egal, was man vor „more“ einfügt.  Etwas dahinter anzufügen funktioniert nicht.

Man kann die Zeichenkette auch komplett durch „“ (nichts) ersetzen, aber ich wollte die Möglichkeit haben, wieder zurück zu wechseln, so als Backup.

Für eine Vorschau der Änderungen klickt man auf „Replace“. Sieht alles in Ordnung aus, klickt man auf „Replace & Save“, kurz danach wird die Anzahl der Ersetzungen oben angezeigt:

[][4]

Fertig.