Web on Natenoms Blog

Hugo Shortcode kann per Einstellung aufs Original verlinken

Sun, 21 Jan 2024 01:56:20 +0100

Wenn ich hier im Blog Fotos/Bilder/Grafiken einbinde, dann sind sie fast immer auf das Original des Bildes verlinkt. Im Blog selbst werden nur kleine, automatisch erstellte Varianten in geringerer Auflösung eingebunden.

Das hat den Nachteil, dass man unnötig viel Schreibarbeit hat bzw. den Dateinamen zweimal einfügen muss.

Es stand schon lange auf meiner Todo-Liste, das endlich mal anzugehen. Heute habe ich das sehr einfach gelöst.

Und das geht so:

Ich verwende im Blog und auch im Wiki einen eigenen Shortcode, den ich wie folgt aufrufe:

{{< figure src="deckel-vorne-2.webp" link="deckel-vorne-2.webp" >}}

Im obigen Beispiel wird die Datei im Blogbeitrag angezeigt und auf das Original verlinkt.

Seit heute gibt es dafür die vereinfachte Variante:

{{< figure src="deckel-vorne-2.webp" link="_self" >}}

Wenn der Wert von link= den Wert _self hat, dann verlinkt der Shortcode automatisch das Originalfoto bei der Einbindung.

Wenn sich in Zukunft der Dateiname ändert, muss man weniger ändern. Und auch beim Schreiben des Shortcodes muss man das selbe nicht zweimal eingeben.

Im Quellcode des Shortcodes habe ich dafür nur diese eine Zeile hinzugefügt:

{{- if (eq $link "_self") -}}{{- $link = $original_img.RelPermalink -}}{{- end -}}

Verlinkungen alter Blogbeiträge funktionieren weiterhin.

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

Verbessertes Script für Häufigkeit von Kategorien und Tags in einem Hugo Blog (Update 2024-01-09)

Sat, 06 Jan 2024 07:57:13 +0100

Vor langer Zeit hatte ich mal eine sehr umständliche Möglichkeit geschaffen, um in der Shell anzuzeigen, welche Tags und Kategorien in meinem Blog wie häufig verwendet wurden.

Das habe ich nun deutlich vereinfacht.

Update

2024-01-09: Das Script ist jetzt in meinem veröffentlichten Hugo Helper enthalten, siehe hier.

Alte Lösung mit Hugo und sehr umständlich

Früher hatte ich das mit Hilfe von Hugo gemacht, das lokal eine eigene Seite im Blog erstellt hat. Die HTML-Ausgabe davon habe ich dann durch diverse Shell-Kommandos gefiltert und heraus kamen Tags und deren Häufigkeit. Das musste man dann ab und zu mal neu generieren lassen und war alles andere als einfach zu benutzen. Details siehe hier.

Jetzt ohne Hugo

Jetzt habe ich das außerhalb von Hugo mit einem Python-Script und einem Shell-Script umgesetzt.

Ich habe ein Shell-Script erstellt, das alle Tags und Kategorien aller Blogbeiträge mit Hilfe von yq ausliest und in eine Datei schreibt, die von einem Python-Script eingelesen wird und Häufigkeit der Tags und Kategorien bestimmt und das Ergebnis in einer endgültigen Datei speichert.

Man könnte das auch alles in einem einzigen Python-Script unterbringen, doch ich kann das nicht. Ich habe es versucht, es aber nicht geschafft.

Detaillierter Ablauf

Im ersten Schritt werden im content-Verzeichnis des Blogs mit find und mit Hilfe von yq alle Tags jedes Blogbeitrags ausgelesen und ein eine Datei geschrieben:

find -iname "*.md" -exec yq --front-matter=extract ".tags" '{}' >> "/tmp/tmp_tags.list" \;

Für diesen Blogbeitrag hier würde die Ausführung dieser Zeile ergeben:

- Web
- Hugo
- Bash
- Python
- Shell

Das Ergebnis ist eine Datei mit ca. 9000 unsortierten und sehr vielen Zeilen und doppelt vorkommenden Tags, weil für jeden Blogbeitrag die Liste aller dort verwendeten Tags in die Datei eingefügt wird.

Im nächsten Schritt wird das Python-Script aufgerufen, das diese Datei Zeile für Zeile einliest, für jedes neue Wort einen eigenen Zähler in einem Dictionary erstellt und für bereits vorgekommene Wörter den Zähler um 1 erhöht. Ich habe dafür hier ein passendes Script gefunden und es für meine Zwecke angepasst.

Am Ende des Python-Scripts wird das Dictionary sortiert ausgegeben und in eine finale Datei umgeleitet.

Ein Auszug der finalen Datei mit nur noch 819 Zeilen mit je einem Tag pro Zeile und dessen Häufigkeit im Blog:

[…]
Aussicht 5
Auswertungen 5
Autobahn 7
Autofahrer 9
Autos 129
Avatar 1
BNN 2
BOA 2
[…]
Zebrastreifen 4
Zeichnen 2
Zeit Online 4
Zeitraffer 2
Zeitungen 8
Zeitzonen 1
Zertifikate 4
Zuständigkeiten 1
ZweiRat 3
[…]

Mit Hilfe des Tools fzf (Fuzzy Finder) kann ich nun sehr einfach in dieser Datei nach Tags suchen, die im Blog verwendet wurden und sehe auch gleich die Häufigkeit.

Und hier ein Video von der Benutzung mittels fzf:

Your browser does not seem to support video.

(Link zum Video)

Update der Daten

Um die Daten zu aktualisieren, muss ich nur ab und zu das Script ausführen und die Ausführung dauert nur ein paar Sekunden.

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.

Kommentare können jetzt via JSON hinterlegt werden – und mir sonstwie zugeschickt werden

Fri, 08 Dec 2023 23:15:10 +0100

Es ist soweit und hat nicht so lange gedauert, wie ich gedacht hatte. Man kann nu wieder Kommentare im Blog hinterlegen, aber nur sehr rudimentär.

Früher mit Isso

Bisher konnte man dank Isso sehr einfach einen Kommentar unter einen freigegebenen Blogbeitrag schreiben. Daraufhin wurde eine E-Mail an mich verschickt, die den Text enthielt und ich konnte mittels Aufruf zweier URLs bestimmen, ob der Kommentar freigeschaltet wird oder gelöscht. Das ganze war unabhängig von Hugo.

Jetzt mit json-Datei

Der jetzige Ablauf ist: Wenn jemand einen Kommentar hinterlassen möchte, klickt er/sie/es im Kommentarbereich auf den Link und daraufhin öffnet sich der lokal installierte E-Mail-Client mit einer vordefinierten E-Mail, in der man den Kommentar schreiben und mir zusenden kann. Dort ist die URL des Blogbeitrags bereits enthalten. Sobald ich Zeit und Lust habe (wie bisher auch schon), werde ich den Kommentar und ein paar Zusatzinformationen in eine .json-Datei innerhalb des Page Bundles des Blogbeitrags eintragen.

Die zusätzlichen Daten sind aktuell:

Eine innerhalb des Blogbeitrags eindeutige ID
Name
Website
Datum
Uhrzeit

Dabei liegen alle Kommentare eines Blogbeitrags immer im Page Bundle. Sollte ich später einen Blogbeitrag depublizieren wollen, so muss ich nicht gesondert an die Kommentare denken, da alles in einem Verzeichnis enthalten ist. So gefällt mir das.

json-Datei nicht veröffentlichen

Man muss aber noch dafür sorgen, dass die json-Datei mit den Kommentaren nicht in der fertigen, von Hugo gerenderten Website enthalten ist.

Dazu habe ich noch keinen guten Ansatz gefunden.

Es gibt z. B. excludeFiles (siehe hier), aber dann wird die json-Datei auch gar nicht mehr für die Verarbeitung im Template gefunden. Dann gibt es noch per Page Bundle die Option _build (siehe hier), aber ich hätte das gerne global.

Die “veraltete” Variante mit ignoreFiles (siehe hier), die aber gar nicht greift, weil ich auch hier nicht schlau genug bin.

D. h. derzeit wird die json-Datei noch immer mit veröffentlicht, enthält aber keine Daten, die nicht auf in der gerenderten html-Datei enthalten sind, außer vielleicht der ID.

Alternativ könnte ich nach dem Rendern der Website per find alle entsprechenden json-Dateien löschen lassen, aber das spare ich mir aktuell noch.

Noch sehr rudimentär

Bei Isso war es möglich, auf einen bestimmten Kommentar Bezug zu nehmen, das geht aktuell mit meiner eigenen Implementierung noch nicht, da ich dazu nicht schlau genug bin, noch nicht. 🤪

Es werden stumpf alle Kommentare in der Reihenfolge der Ankunft bei mir nacheinander gelistet.

Beispiel

Ich habe im Page Bundle dieses Blogbeitrags diese JSON-Datei hinterlegt:

[{
    "id": 0,
    "author": "Natenom",
    "text": "[…]",
    "website": "https://natenom.de/",
    "date": "2023-12-08",
    "time": "18:09"
},
{
    "id": 1,
    "author": "Vrifox",
    "text": "[…]",
    "date": "2023-12-08",
    "website": "https://vrifox.cc/",
    "time": "18:10"
}
]

Das Ergebnis kann man unten im Kommentarbereich sehen.

Nachtrag

Die alten 7 Kommentare aus der Zeit von Isso, werde ich später hier auf diese Art nachtragen. 😄

Keine Kommentare mehr im Blog, da fast nicht genutzt

Fri, 08 Dec 2023 18:42:15 +0100

Seit Anfang August 2023 gibt es hier im Blog wieder die Möglichkeit, Kommentare unter Blogbeiträgen zu schreiben.

Fast nicht genutzt

Die Nutzung davon ist ernüchternd. Wenn ich meine eigenen Kommentare und Antworten auf Kommentare aus der Zählung herausnehme und auch die Kommentare abziehe, die es im Blogbeitrag gab, das die Einführung dieser Möglichkeit beschrieb, dann gab es seitdem lediglich 8 Kommentare.

Davon gehen noch 2 Spamkommentare weg, das ergibt sechs Kommentare in ziemlich genau 4 Monaten.

Und fast alle davon hätte man mir genauso als E-Mail oder auf Mastodon schreiben können, da es mal ein Dankeschön für etwas war oder ein “schön, dass du dabei warst”. :)

Ich wusste von Anfang an, dass es nicht viel werden würde, da es auch zu Zeiten, als hier noch WordPress lief, nur sehr wenige Kommentare gab.

Keine Kommentare mehr

Deshalb habe ich die Möglichkeit wieder deaktiviert. Isso braucht zwar fast keine Ressourcen, ist aber letztlich Code, der auf dem Server läuft und potenziell eine Möglichkeit wäre, fiese Dinge zu tun, sollte es mal irgendwelche Lücken geben.

Seit heute ist hier wieder alles statisch, wie zu vor auch. Somit ruft der Browser auch nicht mehr für jeden Blogbeitrag zusätzlich Daten von der Domain comments.natenom.de ab.

Kommentare gelöscht

Keine Sorge, die bisher geschriebenen Kommentare sind nicht mehr zugänglich und ich werde die Datenbank zudem zeitnah löschen.

Nur noch Rückmeldungen auf anderen Wegen

Ich werde unter den Blogbeiträgen wieder Informationen hinterlegen, wie man mich für Rückmeldungen erreichen kann und dass ich diese bei Bedarf auch gerne im Blogbeitrag hinterlege. Ich werde versuchen, das dann aber über json-Dateien zu machen, die beim Rendern des Blobs diesen Bereich füllen, weil es mich interessiert, wie das funktioniert.

Und nu doch wieder

Nur wenige Stunden nach diesem Blogbeitrag hatte ich ein anderes System für Kommnetare in Hugo “implementiert”, siehe hier.

Suche im Wiki verbessert

Fri, 27 Oct 2023 22:52:53 +0200

Habe heute die Suche im Wiki verbessert. Bisher gab es in den Suchfeldern keine Vorgabetexte und nach der Ausführung der Suche verschwanden die Suchstrings.

Das habe ich jetzt beides behoben.

Als Text steht in beiden Suchfeldern jetzt “Diese Seite durchsuchen” und wenn die Suche ausgeführt wurde, wird in beiden Suchfeldern der verwendete Suchstring eingefügt, sodass man diesen nun einfach anpassen kann, statt alles neu eingeben zu müssen.

Früher mit verschwundenem Suchstring:

Jetzt mit Suchstring, der erhalten bleibt:

Da ich davon keine Ahnung habe und das nur auf Copy & Paste basiert, hat es ewig gedauert, dann aber im Ergebnis sehr einfach.

Ich habe in die Funktion populateResults in der Datei offsearch.js am Anfang nur diese beiden Zeilen einfügen müssen:

  $("#custom-searchbox").val(searchQuery);
  $("#search-query").val(searchQuery);

Hinweis

Es gibt übrigens sowohl einen Menüeintrag für “Suche” als auch das Eingabefeld, weil Letzteres auf mobilen Geräten nicht mehr angezeigt wird. Aber davon hab ich ja keine Ahnung, wie ihr wisst, daher bleibt das erstmal so.

Details zu der Suchfunktion mit fuse.js, die ich im Wiki statt der Defaultsuche vom Docsy-Theme verwende, gibt es hier.

Weitere Verbesserung für 360°-Fotos und Panoramen hier im Blog

Tue, 26 Sep 2023 21:42:42 +0200

Ich habe heute den Viewer für 360°-Fotos und Panoramen noch etwas erweitert.

So kann man nun in meinem eigenen Shortcode für den Viewer angeben, wo im Foto der Norden ist und dieser wird auch links oben auf einem Kompass und im Foto mit einer Markierung angezeigt.

Zudem ist es möglich, die initiale Blickrichtung anzugeben, sodass man z. B. anfangs auf den Sonnenuntergang schaut und nicht zufällig z. B. auf einen Baumstamm. Auf dem Kompass kann man auch sehr gut sehen, welchen Blickwinkel man gerade im Viewer sehen kann.

In diesem Blogbeitrag gibt es zwei 360°-Fotos, die beide Möglichkeiten bereits nutzen.

Hier ein Screenshot davon:

Interessant könnte das werden, wenn ich mal wieder Infrastruktur dokumentiere und dazu eine Karte zeige.

Viewer für 360°-Fotos im Blog verbessert

Mon, 25 Sep 2023 00:40:56 +0200

Gestern und heute habe ich mich viel mit dem Photo-Sphere-Viewer auseinander gesetzt, den ich hier im Blog verwende, um die 360°-Fotos darzustellen und dabei auch einige Dinge verbessern können.

Mit Hilfe der ausführlichen Dokumentation des Photo-Sphere-Viewer konnte ich den jetzt richtig im Blog einbinden, sodass ich auch die verschiedenen Plugins nutzen kann, was bisher nicht möglich war, da ich von dieser Thematik keine Ahnung habe.

Auch konnte ich meinen Shortcode zum Einbinden des Viewers verbessern.

Verbesserungen des 360°-Viewers

Es ist jetzt möglich, auch bei mehreren 360°-Fotos in einem Blogbeitrag jeweils eine OpenStreetMap-Karte mit dem Standort anzuzeigen, bisher war das nur einmal pro Blogbeitrag möglich. Hier ein Beispiel.
Dank des Gyroskop-Plugins kann man das Smartphone im Raum bewegen und sieht das, was vor Ort auch in dieser Richtung war. Das geht aber nur, wenn das Smartphone einen Lagesensor hat und der Browser das unterstützt. Dazu muss man unten rechts auf das Kompass-Symbol drücken.
Der Fischaugen-Effekt ist aus. Das Foto wird also beim Verändern der Ansicht nicht mehr verzerrt.
Der Photo-Sphere-Viewer wurde auf die neueste Version aktualisiert.

Weitere Möglichkeiten in Zukunft dank Plugins

In Zukunft kann ich mir vorstellen, auch noch mehr Funktionen der Plugins zu nutzen, wie z. B. die Möglichkeit für Markierungen innerhalb der 360°-Fotos. Oder auch das automatische scrollen der Fotos.

Metadaten – so wichtig für unvollständige Panoramen

Beim Testen ist mir aufgefallen, dass der Viewer Panorama-Fotos automatisch auf nur einen Teil der “Leinwand tapeziert”, wenn das Foto nicht 360° in der Horizontalen abdeckt, sondern nur einen Teil davon. In vor allem älteren Panorama-Fotos funktioniert das jedoch nicht.

Der Verdacht: Metadaten.

Und tatsächlich, es liegt an Metadaten. In älteren Panorama-Fotos gab es die nie und in aktuellen Panorama-Fotos entferne ich die Metadaten vor dem Veröffentlichen per Script. Sobald die Metadaten fehlen, gibt es bei teilweisen Panoramen harte Schnitte und keine unvollständigen Bereiche mehr.

Hier ein Vergleich, oben mit Metadaten, unten ohne:

Welche Metadaten eine Rolle spielen, ist hier dokumentiert. Auch auf der Projektseite von Photo-Sphere-Viewer gibt es dazu einen Abschnitt und es wird auch erklärt, wie man diese Daten angeben kann, ohne sie in die Metadaten zu schreiben, siehe hier. Dort gibt es ganz unten auch einen Bereich, wo man diese Angaben anhand eines lokalen Beispielfotos ausprobieren kann.

Das sind die relevanten Metadaten (aus exiftool) mit den Werten für das hier verwendete Beispiel:¹

Cropped Area Left Pixels        : 0
Cropped Area Top Pixels         : 1278
Cropped Area Image Width Pixels : 6774
Cropped Area Image Height Pixels: 1634
Full Pano Width Pixels          : 8330
Full Pano Height Pixels         : 4165

Man kann diese Metadaten auch mit Hilfe von exiftool wieder in Fotos hineinschreiben, falls man z. B. noch auf das unbearbeitete Originalfoto Zugriff hat:

exiftool -overwrite_original -CroppedAreaImageHeightPixels=1634 -CroppedAreaImageWidthPixels=6774 -CroppedAreaLeftPixels=0 -CroppedAreaTopPixels=1278 -FullPanoWidthPixels=8330 -FullPanoHeightPixels=4165 datei.webp

Statt die Tags manuell hinzuzufügen kann man sie beim Entfernen der anderen Metadaten in den Fotos belassen. Mein Script zum Entfernen von Metadaten habe ich nun so umgeschrieben, dass diese Daten erhalten bleiben:

preservetags="-aperturevalue -shuttervalue -iso -mime -exposuretime -focallength -orientation -exposurebias -flash -CroppedAreaImageHeightPixels -CroppedAreaImageWidthPixels -CroppedAreaLeftPixels -CroppedAreaTopPixels -FullPanoWidthPixels -FullPanoHeightPixels -InitialViewHeadingDegrees -InitialViewPitchDegrees -InitialViewRollDegrees -ProjectionType"

exiftool -all= -tagsfromfile @ ${preservetags} -overwrite_original datei.webp"

Sooo schön

Besonders die Funktion mit dem Gyroskop auf Smartphones gefällt mir sehr gut und auch, dass man jetzt auch bei mehreren 360°-Fotos pro Blogbeitrag zu jedem Foto jeweils eine eigene Karte mit dem Ort darstellen kann. Das sind wirklich schöne und einfach zu erstellende Erinnerungen.

Ich werde ab jetzt auch Panorama-Fotos mit diesem Viewer darstellen lassen.

Kleine, aber nicht mehr aktive Alternative – Pannellum

Es gibt eine Alternative zum Photo-Sphere-Viewer, nämlich Pannellum. Der Viewer ist nur 21 kB klein und hat einen ausreichenden Funktionsumfang, wenn ich davon ausgehe, was ich hier bisher im Blog benötigt hatte. Der Viewer wird aber schon seit 2019 nicht mehr groß weiterentwickelt. Man muss lediglich eine .js-Datei und eine .css-Datei einbinden, mehr nicht.

An Pannellum gefällt mir unter anderem, dass das Foto optional erst nach einem Klick auf einen Knopf geladen wird. Das spart Bandbreite.

Die Liste der aller für Panoramen relevanter Tags gibt es hier. ↩︎

Mehrere Spheres (360°-Fotos) in einem Blogbeitrag

Mon, 11 Sep 2023 00:17:50 +0200

Ich wollte heute einen Blogbeitrag erstellen, in dem mehrere 360°-Fotos (hier nur noch “Sphere” genannt) eingebunden werden und stellte fest, dass immer nur die erste Sphere angezeigt wurde. Vermutlich hatte ich damals beim “Implementieren” nicht an so etwas gedacht.

Das Problem ist, dass der Shortcode den folgenden Code beinhaltet:

<div id="viewer" style="width: 100%; height: 60vh;">div>
<script>
    const viewer = new PhotoSphereViewer.Viewer({
        container: document.querySelector('#viewer'),
[…]

Eindeutige ID mit .Ordinal

Ich habe jetzt nicht wirklich Ahnung von diesem ganzen Zeugs, aber eine ID innerhalb eines HTML-Dokuments muss eindeutig sein und sobald man mehrere Spheres einbindet, gibt es mindestens zwei id="viewer".

D. h. ich musste den Code ändern und sowohl die ID als auch die Konstante viewer für jedes eingebundene Sphere eindeutig machen. Mit Hilfe der Variable .Ordinal ist das einfach umsetzbar. Die Variable besagt, an wie vielter Stelle der aktuelle Shortcode im Kontext der aktuellen Seite steht.

Dabei stieß ich auf ein Problem, denn irgendwas in Hugo macht magische Dinge und fügt automatisch Anführungszeichen ein, sobald man eine Hugo Variable innerhalb eines

Einbindung per Shortcode

Und so sieht das im Ergebnis aus. Das verwendet Bild stammt von einem alten Blogbeitrag aus der Zeit, als das oben genannte WordPress-Plugin noch in meinem Blog verwendet wurde.

Ich hatte das damals mit der Foto-App eines Smartphones erstellt.

Die Einbindung in einem Blogbeitrag sieht so aus:

{{< sphere src="20171019_360_baustelle_perouse_heimsheim.jpg" caption="Eine Baustelle bei Perourse." >}}

Und das Ergebnis (Screenshot):

So sieht das Ergebnis aus.

Konfiguration von Nginx

Da die CSP-Header im Webserver relativ strikt gesetzt sind, hat das Nachladen der Fotos nicht funktioniert. Dazu musste ich im entsprechenden Bereich blob: erlauben:

img-src 'self' data: blob:;

Beispiele

Update

2023-02-24: Es gibt jetzt ein neues Tag 360 für solche 360°-Fotos.

Und hier die Links zu allen alten 360°-Fotos, die mit dem neuen Photo Sphere Viewer wieder angesehen werden können:

In Zukunft bessere Qualität

Früher hatte ich solche Fotos immer mit dem Smartphone und einer einfachen App gemacht. Da hatte man keinerlei Einfluss auf das Ergebnis. Dadurch ist die Qualität der Fotos sehr durchwachsen.

Aktuell scheint es keine freie Android-App für so etwas zu geben und die Foto-App meines Smartphones kann das leider nicht.

Daher habe ich mich entschieden, zukünftig die Fotos mit einem normalen Fotoapparat zu machen und diese mit der Software Hugin zu einem 360°-Panorama zu verbinden.

Was mir noch fehlt

Lagesensor

Ich erinnere mich daran, dass der Lagesensor des Smartphones bei dem alten Plugin in WordPress ausgewertet wurde. So konnte man das Smartphone vor sich halten und in alle Richtungen drehen und konnte entsprechend die Richtung im 360°-Foto im Smartphone sehen.

Das wäre noch eine schöne Funktion. Vielleicht gibt es sie auch bereits und ich habe sie noch nicht gefunden.

Update

Update (2023-10-17): Mit dem aktuellen 360-Grad-Viewer im Blog ist das möglich, es gibt dafür ein Plugin.

Link zum Originalbild

Es gibt zwar bereits einen Button, um das Panorama herunterzuladen, aber ich möchte irgendwo noch einen Link unter dem Betrachtungsfenster einfügen, sodass man das Originalbild im aktuellen Fenster öffnen kann, statt es herunterzuladen.

Weiterleitungen für den neuen Foto-Blog

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

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

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

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

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

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

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

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

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

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

Im Ergebnis sieht die Textdatei nun so aus:

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

Hinweis

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

Insgesamt habe ich auf diese Weise 369 Weiterleitungen eingerichtet.

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

Dann einmal kurz getestet, ob die Syntax passt mit:

nginx -t

Und den Webserver neugestartet, da alles okay war.

Fertig. 😊

Im Wiki aufgeräumt

Wed, 07 Dec 2022 03:32:31 +0100

Habe heute ein Vieles im neuen Wiki aufgeräumt.

Habe viele veraltete Bereiche komplett gelöscht, da die beschriebene Software zum Teil gar nicht mehr existiert.

Auch habe ich ein paar Hauptbereiche der obersten Ebene nach Sammelsurium verschoben, da sie auch nach mehreren Jahren noch recht klein geblieben sind, z. B. Android. Dazu natürlich Aliase eingerichtet, damit die alten URLs weiterhin nutzbar bleiben.

Und an ein paar anderen Stellen einige Verzeichnisstrukturen etwas entschlackt und Seiten zusammengefasst.

Die verbliebenen Hauptbereiche im neuen Wiki sind nun:

Ernährung
Fahrrad
Linux
Minimalismus
Mobilität
Müll sammeln
Mumble (nur eine Weiterleitung auf das alte, archivierte Wiki)
Sammelsurium
Sauerbraten

Das Wiki auf wiki.natenom.com, wie es aktuell aussieht.

Neuerungen in Blog und Wiki

Thu, 01 Dec 2022 19:21:04 +0100

Es gibt mal wieder einige Änderungen in Blog und Wiki, die ich hier auflisten möchte. Ein paar kommen vom aktualisierten Theme (im Blog) und andere hat Vri umgesetzt. Vielen Dank dafür. ☺️

Blog

Datenschutzkonformes iframe

Der Entwickler des Themes, das ich hier verwende, hat einen neuen Shortcode iframe implementiert. Der externe Inhalt wird erst geladen, nachdem der Benutzer auf “Laden” geklickt hat.

Es ist möglich, vorgegebene Texte für die Schaltfläche und auch für den Beschreibungstext anzupassen.

Hier ein Beispiel:

{{< iframe src="http://umap.openstreetmap.fr/en/map/natenoms-buros_642889#11/48.8503/8.9209" trigger="manual" loadButtonText="Externe Karte laden" loadInfo="Ein Klick hierdrauf lädt Daten von OpenStreetMap. Der Anbieter erhält dadurch deine IP-Adresse und weitere Daten von dir." >}}

So sieht das dann aus:

Noch wurde nichts geladen.

Der externe Inhalt wurde geladen. Copyright by OpenStreetMap Contributors

Seiten im Suchindex verstecken

Setzt man im Front Matter eines Blogbeitrags den Parameter index: false, so wird diese Seite nicht in den Suchindex aufgenommen und kann somit auch nicht über die Suche des Blogs gefunden werden.

Externe Suchmaschinen können die Seite natürlich trotzdem finden.

Unter der Haube

Vri hat eine zusätzliche Konfiguration zum Blog hinzugefügt, die nur greift, wenn man die Seite lokal mit hugo server baut. Dann werden nur die Blogbeiträge aus dem aktuellen Jahr gerendert, sodass das Rendern insgesamt nur noch 4 statt 20 Sekunden dauert.

Wenn man neue Blogbeiträge schreibt oder einfach nur etwas am Stil im Blog anpassen möchte, dann kann man so viel Zeit sparen.

Wiki

Navigationsleiste

Statt die aktuelle und hervorgehobene Seite in der Navigationsleiste komplett in Blau zu hinterlegen, hat Vri das jetzt mal ordentlich und schön gemacht. Das Blau hatte historische Gründe, denn die Navigation im alten Wiki sah genauso aus.

Vorher und nachher:

Zusätzlich habe ich den Navigationsbaum so umgestellt, dass er wieder dynamisch ist, d. h. man kann jederzeit alle Bereiche öffnen.

Da das Wiki eine statische Website ist, muss deshalb jedoch der gesamte Navigationsbaum in jeder einzelnen Seite des Wikis enthalten sein und somit wird jede Seite im Wiki um circa 4,8 kB größer. Im Fall von Müllsammeln z. B. 33,2 kB statt sonst 28,4 kB.

Die Unterschiede von Googles Pagespeed zwischen dynamischem und statischem Navigationsbaum sind zudem marginal bis gar nicht vorhanden. Für die Desktop-Ansicht kann man keine Unterschiede feststellen, nur in der mobilen Ansicht gibt es leichte Unterschiede. Hier zwei Screenshots von der Auswertung der mobilen Ansicht:

Ergebnisse für den statischen Navigationsbaum.

Ergebnisse für den interaktiven Navigationsbaum.

Die Größe des DOM (Document Object Model) wird von Pagespeed im Wiki generell moniert. Mit statischem Navigationsbaum sind es 1982 Elemente und mit dynamischem Navigationsbaum sind es 3094 Elemente.

Ein weiterer Nachteil des dynamischen Navigationsbaums ist, dass alle Seiten im Wiki nicht mehr so lange gecached werden können. Denn sobald sich irgendwo im Wiki der Titel einer Seite oder deren Anordnung ändert, muss jede Seite im Browser des Besuchers neu geladen werden, um den Navigationsbaum korrekt anzuzeigen.

Ich denke, mit den kleinen Nachteilen kann man leben und der dynamische Navigationsbaum ist meiner Ansicht nach ein großer Zugewinn für die Nutzbarkeit des Wikis. Außerdem ändere ich ja nicht ständig Seiten im Wiki.

Shortcodes

Vri hat das SCSS von Shortcodes umstrukturiert und konnte somit Shortcodes generell auf max-width: 80% einstellen, sodass sie nicht mehr breiter sind als der restliche Inhalt einer Seite.

Zudem werden Überschriften von Hinweisboxen (Update, Tipp, Warnung, …) im Feed jetzt groß geschrieben, wie auch auf der Website.

Suchfunktion

Auch hat Vri rechts oben im Wiki ein Formularfeld für die Suchfunktion des Wikis eingefügt, sodass man nicht mehr umständlich erst auf “Suche” klicken und dann den Suchbegriff auf der anschließend ladenden Seite eingeben muss.

Kein HTML-Quelltext mehr

Ich habe im Wiki unsafe=false eingestellt. Somit wird HTML-Quelltext innerhalb einer Seite generell nicht mehr gerendert, sondern nur entfernt. Im Zuge des Umzugs von Dokuwiki hatte ich das auf true gesetzt, damit erst einmal alle Inhalte sichtbar waren. Mittlerweile habe ich alle Inhalte ins Markdown-Format überführt, bis auf eine Liste mit (teils veralteter) Software. In der Hugo-Doku gibt es weitere Informationen zu den Einstellungen fürs Rendern in Hugo (nach unsafe suchen).

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.

Transparenz für Kommentare im Blog via Mastodon

Fri, 04 Nov 2022 15:22:56 +0100

Erst vor ein paar Tagen hatte ich hier im Blog ermöglicht, via Mastodon Kommentare zu schreiben.

Dabei werden hier im Blog alle Antworten auf einen bestimmten Tröt/Toot bei einem Klick auf einen Button von Mastodon nachgeladen.

Es sind alle Tröts sichtbar, die bei Mastodon bzw. im Fediverse auf einen ganz bestimmten, ausgewählten Tröt/Toot als Antwort geschrieben werden.

Sobald ich einen Blogbeitrag fertig und veröffentlicht habe, setze ich einen solchen Tröt ab und binde dann dessen Antworten für die Kommentarfunktion im Blogbeitrag ein.

Intransparent

Das Problem dabei: Kommentiert man ausgehend vom Blogbeitrag, dann ist klar ersichtlich, dass dabei Mastodon als Quelle dient. Doch Menschen, die nur auf Mastodon bzw. im Fediverse auf meinen Tröt zu einem Blogbeitrag reagieren, können nicht erkennen, dass ihre Antworten im Blog im Kommentarbereich zu sehen sein werden.

Dass das nicht optimal ist, war mir schon klar, als ich das umgesetzt hatte. Ich war jedoch erstm einmal froh, dass es überhaupt so funktioniert hatte und verschob alles weitere auf später.

Heute hat jemand diese Überlegungen auf meine heutige Todo-Liste gestellt, als er mir diesen Tröt schickte, der genau das Problem beschreibt. (Danke dafür.)

Der Autor äußert bei einer solchen Vorgehensweise Bedenken bezüglich des Datenschutzes und empfindet es zumindest als unhöflich. Letzerem stimme ich zu.

Wegen Datenschutz sehe ich keine Probleme, bin aber auch nur Laie. Das Fediverse besteht aus vielen verschiedenen Instanzen und sobald man dort etwas öffentlich schreibt, werden die Tröts auf unzählige Instanzen weitergeleitet und weiß letzlich nie, in welchem Kontext die eigenen Beiträge zu sehen sein werden.

Transparent

Deshalb werde ich die Kommentarfunktion via Mastodon ab jetzt leicht abgeändert umsetzen.

Es wird weiterhin für Blogbeiträge, die ich im Fediverse teilen möchte, einen eigenen Tröt geben. Als erste Antwort auf diesen Tröt werde ich einen weiteren Tröt schreiben, der erklärt, dass nur die Antworten auf diesen Tröt für die Kommentarfunktion des Blogs herangezogen werden.

Beispiel:

Tröt 1: Meine Fahrradstatistik für Oktober 2022
- Tröt 2 (als Antwort auf Tröt 1): Wenn du auf diesen Tröt hier antwortest, werden die Antworten im Kommentarbereich des oben verlinkten Blogbeitrags angezeigt. Antworten auf den Ursprungströt (der mit dem Link zum Blogbeitrag) sind nicht im Blog sichtbar. Es kann ein paar Minuten dauern, bis die Kommentarfunktion im Blog aktiviert ist. #blogcomments
  - Tröt 3 (als Antwort auf Tröt 2): abc -> erscheint im Kommentarbereich des Blogs.
    - Tröt 6 (als Antwort auf Tröt 3): bar -> erscheint im Kommentarbereich des Blogs.
  - Tröt 5 (als Antwort auf Tröt 2): foo -> erscheint im Kommentarbereich des Blogs.
- Tröt 4 (als Antwort auf Tröt 1): def -> erscheint nicht im Kommentarbereich des Blogs.

Tipp

Das Hashtag #blogcomments werde ich vorsorglich hinzufügen, da es z. B. mit Ephemetoot möglich ist, Tröts mit bestimmten Tags von der Löschung auszuschließen. Mastodon kann zwar auch selbst alte Tröts löschen, bietet aber nur sehr wenige Möglichkeiten, bestimmte Tröts von der Löschung auszuschließen.

In Zukunft könnte ich statt der in Mastodon eingebauten Funktion wieder Ephemetoot nutzen, um alte Tröts zu löschen und dabei Tröts behalten, die das Tag #blogcomments beinhalten.

Daten sind live, es gibt keine Kopien

Die Antworten auf den “Kommentar”-Tröt werden übrigens nicht in meinen Blog “hineinkopiert” sondern immer via JavaScript live über den Browser des Besuchers nachgeladen.

Das bedeutet, dass jeder seinen “Kommentar” auch jederzeit löschen kann.

Passt

Das hier ist der erste Blogbeitrag, bei dem transparent ist, dass Kommentare im Blog landen.

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

Altes, archiviertes wiki.natenom.de verbessert

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

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

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

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

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

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

Überlegungen zum Entfernen der migrierten Bereiche aus dem archivierten Wiki

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

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

Wenn jemand hierzu Gedanken hat, bitte anschreiben. 😊

Was wird in dieser Anleitung gemacht?

Auf dem lokalen Rechner wird:

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

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

Vorbereitungen

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

Installation der benötigen Debian-Pakete

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

Lokale Domain fürs Wiki

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

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

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

127.0.0.1 wiki.natenom.me

Lokalen Webserver konfigurieren

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

Datei /etc/nginx/sites-enabled/default

Verbesserte Suchfunktion im Blog

Tue, 27 Sep 2022 20:56:56 +0200

Es gab wieder ein Update für das hier verwendete Hugo-Theme Bootstrap, das die Suchfunktion verbessert hat.

Optionen

Es gibt ein paar neue Optionen für die Suche. Die vollständige Liste gibt es hier.

Die Beschreibung der Optionen gibt es auf der Website von fuse.js.

Index und Meta

Statt einer großen Indexdatei mit allen Blogbeiträgen (hier immerhin um 2500) gibt es jetzt mehrere davon. Jede enthält per Voreinstellung 1000 Blogbeiträge, es sind als insgesamt 3 Dateien (index1.json, index2.json, …).

Die Option dazu ist search.indexPaginate.

Dazu gibt es eine weitere Datei meta.json, die alle Kategorien und alle Tags enthält, die im Blog verwendet werden.

Preload

Neu ist z. B. search.indexPreload, das per Voreinstellung auf true gesetzt ist. Ich habe das auf false gesetzt. Nach meinem Verständnis werden die Indexdateien dann nicht geladen, wenn JavaScript nicht ausgeführt wird und man die Suchseite aufruft.

Auf true gesetzt werden die Indexdateien direkt in der Suchseite eingebunden und auch ohne JavaScript vorgeladen. Das sind insgesamt aber stattliche 1,6 MiB. Bei einer langsamen Internetverbindung ist das viel.

Erst buggy und jetzt schneller

Nachdem der Theme-Entwickler die neue Suchfunktion implementiert hatte und ich das Theme meines Blogs aktualisiert hatte, bemerkte ich, dass die Suche in Firefox sehr viel CPU-Last verursachte und Firefox anbot, das Script im Tab zu beenden. Die Suchseite war gar nicht mehr benutzbar.

Ich stellte dem Entwickler mein Repo des Blogs zur Verfügung und so konnte er schließlich das Problem reproduzieren.

Er deaktivierte daraufhin im Theme etwas für Font Awesome (siehe hier), das ich eh nicht verstehe und danach war die Suchfunktion auch in Firefox genauso schnell wie zuvor nur in Chromium.

Vor der Neuerung der Suche war diese in Firefox immer einige Sekunden langsamer als in Chromium.

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:

Falsch gedrehte Bilder in Hugo durch Verwendung von Funktionen zur Bildbearbeitung

Sun, 11 Sep 2022 20:11:13 +0200

Mir ist er vor ein paar Tagen aufgefallen, dass die im Blog generierten kleinen Varianten der Bilder manchmal liegend dargestellt werden, obwohl sie hochkant dargestellt werden müssten, wohingegen die Originalbilder richtig dargestellt werden. So wie in diesem Screenshot im zweiten Bild der Galerie zu sehen ist:

Blogbeitrag mit falsch gedrehtem Bild. Hier der Blogbeitrag.

Das liegt scheinbar daran, dass in den Metadaten (Exif) mancher Fotos die Rotation hinterlegt ist, das Bild selbst jedoch nicht “richtig” ausgerichtet gespeichert wurde.

Update

2022-09-30: Ich habe ein Script geschrieben, das solche Dateien findet und die Ausrichtung korrigiert, siehe hier.

Hintergrund

Hugo beachtet vorhandene Exif-Daten nicht und erstellt deshalb mit z. B. der .Resize-Funktion Bilder mit falscher Ausrichtung. Diese Funktion wird in meinem Blog und auch in meinem Wiki genutzt, um automatisch kleine Varianten großer Bilder zu erstellen, siehe hier. Vermutlich passiert das selbe auch bei Verwendung von Fit, Fill, Crop und Filter. (Hier die Dokumentation dieser Funktionen.)

Das ist ein bekanntes “Problem” in Hugo. Details siehe hier.

Einen offenen Issue gibt es hier.

Nicht alle Bilder im Blog sind davon betroffen. Kommt vermutlich auf die verarbeitende Software oder auf das Kameramodell usw. an.

Zwei Lösungen

Lösung 1 – Anpassung in Hugo

Eine Lösung ist, viel Arbeit in meinen render-image-Hook als auch in den figure-Shortcode zu stecken, sodass dort die Rotation ausgewertet und beachtet wird. Für beides verwende ich nicht die Originale sondern eigenen Varianten.

In hugo-shortcode-gallery wird das z. B. so gemacht, siehe hier.

Lösung 2 – Bilddateien entsprechend rotieren

Eine weit einfachere Lösung ist, die Dateien direkt entsprechend der enthaltenen Metadaten zu rotieren und so abzuspeichern.

Das kann man z. B. mit mogrify (ImageMagick) machen.

Für entsprechende Dateien führe ich also das hier aus, wobei die Originaldatei überschrieben wird:

mogrify -auto-orient pausenbaum.jpg

Damit wird die Info zur Rotation aus den Metadaten entfernt und das Bild “richtig” gedreht abgespeichert. Die Dokumentation dazu findet sich hier.

Man könnte noch ein Script schreiben, das alle Bilder findet, die Infos zur Rotation enthalten und diese dann in einem Schritt entsprechend drehen. Das spare ich mir, da ich das manuell mache, wenn ich mal wieder solche Fotos im Blog sehe.

Passt

Und dann ist das Foto im Blog wieder richtig gedreht:

Blogbeitrag mit richtig gedrehtem Bild. Hier der Blogbeitrag.

Falls jemand einen Blogbeitrag mit falsch gedrehten Bildern findet, würde ich mich über einen Hinweis darauf freuen. Danke.

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.

Updates für Bootstrap Theme für Hugo

Thu, 08 Sep 2022 18:12:02 +0200

Es gab wieder ein paar Neuerungen für das hier verwendete Theme Bootstrap, das hier im Blog verwendet wird.

Allgemein

Der DarkMode funktioniert wieder richtig und der Hintergrund dabei ist wieder dunkel.
Per Voreinstellung gibt es jetzt eine Umrandung für Tabellen und einen Hover-Effekt. Details siehe hier.

Weiterlesen

Auf meine Anfrage hin hat der Theme-Entwickler implementiert, dass der Link hinter dem Button “Weiterlesen” nicht mehr an den Anfang des Beitrags zeigt, sondern auf den Anker, den man manuell mit an beliebiger Stelle im Blogbeitrag setzen kann.

Das hat den Vorteil, dass man bei längeren Auszügen diese nicht nochmal lesen muss, sondern im Lesefluss bleibt. Ich kenne das so noch von WordPress und fand es immer angenehm.

Der Titel des Blogbeitrags in der Liste der Beiträge verlinkt weiterhin auf den Anfang.

Die Funktion ist per Voreinstellung deaktiviert. Zum Aktivieren fügt man in der config.toml im Bereich [params] hinzu:

post.readMoreFromContent = true

Neuer Feed

Es ist nun einstellbar, ob im Feed nur die Auszüge des Blogbeiträge enthalten sind oder der gesamte Blogbeitrag.

Zudem wurde die Struktur des Feeds verbessert.

D. h. in der neuen Variante sind jetzt die Beitragsbeschreibung/Auszug/Excerpt getrennt vom Inhalt angegeben und der Inhalt wird innerhalb CDATA angegeben.

Hier der Hintergrund der Änderung.

Möchte man einstellen, dass die ganzen Blogbeiträge im Feed enthalten sind, statt nur der Auszüge, dann muss man in der config.toml im Bereich [params] hinzufügen:

feeds.content = true

So sah der Feed bisher aus:


    </span>Ein Titel<span style="color:#f92672">
    url zum Blogbeitrag
    Tue, 06 Sep 2022 03:42:05 +0200
    eine guid
    Kompletter Blogbeitrag stand hier drin

Und so sieht der Feed jetzt aus:


    </span>Ein Titel<span style="color:#f92672">
    url zum Blogbeitrag
    Tue, 06 Sep 2022 03:42:05 +0200
    eine guid
    Auszug/Beschreibung des Blogbeitrags

Eigene Pseudo-Galerie für Hugo als Ersatz für Hugo-Shortcode-Gallery

Tue, 06 Sep 2022 03:42:05 +0200

Als ich Anfang des Jahres diesen Blog hier von WordPress zu Hugo umzog, war mir die Funktion einer Bildergalerie sehr wichtig. Schließlich gab es in meinem Blog sehr viele Bildergalerien.

Hugo-Shortcode-Gallery

Dafür verwendete ich hugo-shortcode-gallery. Hierbei werden die von Hugo generierten Vorschaubilder per JavaScript geladen und bei einem Klick darauf werden in einer Lightbox die Originale angezeigt. Letzteres war zuletzt in Firefox ziemlich lahm.

Eine Galerie fügt man mit diesem Shortcode ein:

{{< gallery match="images/*" >}}

Damit werden alle Bilder im Unterverzeichnis images/ des Page Bundle zur Galerie hinzugefügt. So kann man auch mehrere Galerien in einem Blogbeitrag mittels verschiedenen Unterverzeichnissen erstellen lassen.

Einzelbilder statt Galerie

Über die Zeit hat sich jedoch für mich herauskristallisiert, dass ich Galerien gar nicht benötige. Stattdessen finde ich es jetzt besser, Bilder einzeln einzubinden, sodass man auch zu jedem Bild eine Beschreibung und einen Alt-Text hinterlegen kann. Und auch eine Lightbox will ich nicht mehr haben, Bilder werden per Klick direkt geöffnet.

Schon seit längerem nutze ich daher gar keine Galerien mehr.

Da aber in circa 90 Blogbeiträgen bereits die anfangs genutzten Galerien enthalten sind, wollte ich mir die Arbeit ersparen, diese manuell umschreiben zu müssen.

Eigene Pseudogalerie statt Hugo-Shortcode-Gallery

Deshalb habe ich die Hugo-Shortcode-Gallery aus dem Projekt entfernt und einen gleichnamigen eigenen Shortcode erstellt, der die Bilder per Markdown einfügt und mit dem Original verlinkt, so wie hier beschrieben.

Man kann somit die alte Form weiterverwenden und für

{{< gallery match="images/*" >}}

wird durch alle passenden Bilder iteriert und dann wird das hier eingefügt:

[![](images/bild1.jpg)](images/bild1.jpg)
[![](images/bild2.jpg)](images/bild2.jpg)
…

Das nächste Rendern des Blogs dauerte nach der Änderung sehr lange, schließlich mussten für hunderte Bilder in insgesamt 90 Galerien verschiedene Bildgrößen generiert werden. Für meinen Blog waren das so zusätzlich 1,6 GB an neuen Bildateien.

Diese Änderung ist jetzt im Blog und auch im Wiki implementiert. Ich musste in der config.toml des Wikis den timeout etwas erhöhen, da es dort Galerien mit extrem vielen Bildern gibt.

Alt und neu im Vergleich

Links die alte Galerie und rechts die neue.

Alte Galerie.

Neue Pseudo-Galerie.

Hier der Link zum Blogbeitrag mit den schönen Minecraft-Bauten.

Passt

Das passt so für mich. Es gibt eine Abhängigkeit weniger, um die man sich ganz selten mal kümmern muss und die eigene Lösung benötigt auch kein JavaScript mehr.

Und falls ich mal in einen Blogbeitrag ganz viele Bilder als reinen Bilddump werfen möchte, dann kann ich das weiterhin mit dem entsprechenden Shortcode machen. Bevorzugt sind aber weiterhin Bilder mit Bildbeschreibung im Alt-Text.

Änderungen im Blog

Thu, 28 Jul 2022 10:33:26 +0200

Wegen einiger Updates des verwendeten Themes HBS (Hugo Bootstrap) habe ich auch gleich ein paar weitere Änderungen im Blog vorgenommen.

Kopfbereich von Blogbeiträgen

Der Entwickler des Themes hat zur Unterscheidbarkeit von Kategorien und Tags im Header des Beitrags den Kategorien ein Verzeichnis-Icon vorangestellt. Daher habe ich die Hashtags vor den Tags entfernt.
Die Schriftgröße der Beitragsüberschriften ist jetzt immer gleich groß. Vorher war sie in der Liste der Blogbeiträge immer deutlich kleiner als im geöffneten Beitrag.

Alt: Kopfbereich eines Blogbeitrags.

Neu: Kopfbereich eines Blogbeitrags.

In der Sidebar rechts gibt es jetzt ein neues Widget “Empfohlene Beiträge”. Um dort einen Beitrag hinzuzufügen, muss man im Front Matter hinzufügen:

    featured: true

Auch die Überschriften der Widgets sind nun deutlich größer.

Font-Awesome statt Octicons

Ich hatte irgendwann einmal einige der Font-Awesome-Icons durch welche von Octicons ersetzt. Das habe ich jetzt sein lassen, da es nur deshalb schon 7 Dateien in layouts/partials/ gab, die ich bei jedem Update im Theme überprüfen musste. Und es gab trotzdem noch viele Font-Awesome-Icons an diversen Stellen, die ich nöch hätte ersetzen müssen. Das ist mir auf Dauer zu viel Aufwand.

Deshalb habe ich die Octicons überall entfernt und werden die voreingestellten Font-Awesome-Icons des Themes verwendet.

Serien

Dank der Hilfe des Theme-Entwicklers habe ich es geschafft, endlich sogenannte Serien (engl. “series”) im Blog einzufügen. Statt der “normalen” Seite /reiseberichte gibt es jetzt “Reiseberichte” als Serie.

Um einen Blogbeitrag in eine Serie aufzunehmen, die dann automatisch darin gelistet wird, fügt man im Front Matter ein:

    series:
      - Reiseberichte

Mit einem Alias habe ich auch gleich eine Weiterleitung eingerichtet:

    aliases: /reiseberichte/

In der oberen Leiste gibt es jetzt deutlich mehr Icons, die es biser nur auf der “Über Natenom” Seite gab. Hier sind jetzt E-Mail, Github, Mastodon, Reddit, Twitter und ein Videokanal verlinkt.

Auch die Serien sind dort verlinkt.

Alt und neu im Vergleich

Alt: Ganzer Blog.

Neu: Ganzer Blog.

Farben

Bisher konnte man oben rechts verschiedene Farbpaletten auswählen. Jetzt ist immer mein Blau aktiv und die Farbe nicht mehr umschaltbar.

Mobile Ansicht

In der mobilen Ansicht werden jetzt die Widgets angezeigt, jedoch sind diese immer eingeklappt. Das sieht interessant aus und könnte sogar gut sein, ist aber auch irgendwie seltsam. Der zweite Screenshot zeigt das Menü auf mobilen Geräten und das sieht schon etwas länger so aus.

Passt

Mir gefällt, was der Entwickler des Themes seit langem so macht. Ein schönes Theme für meinen Blog. Danke. 😊

Änderungen im Blog und im Wiki

Tue, 24 May 2022 02:56:03 +0200

Es haben sich wieder ein paar Änderungen angesammelt.

Blog

Untermenü in der oberen Leiste

Da das Untermenü für “Themen” in der oberen Leiste ohne JavaScript nicht erreichbar war, habe ich das zu einem Link verändert, der auf die Seite “Themen im Blog” verweist.

In der mobilen Ansicht funktioniert es leider trotzdem nicht, da dort das gesamte obere Menü nur per JavaScript geladen wird.

Wiki

Seitenhervorhebung

Dank Vri wird die aktuelle Seite im Wiki schöner hervorgehoben:

Den selben Effekt sieht man beim Hovern.

Vorher hatte ich das selbst gemacht und entsprechend sah das auch aus:

Inhaltsverzeichnis

Das Inhaltsverzeichnis wird jetzt immer angezeigt, nicht erst, wie per Voreinstellung, wenn der Blogbeitrag mindestens 280 Wörter hat.

Der zu ändernde Parameter hierfür ist tocWordCount im Bereich [params] in der config.toml. Ich habe den Wert auf 10 (Wörter) eingestellt, sodass man auch in relativ kurzen Blogbeiträgen eine Navigationsmöglichkeit per Inhaltsverzeichnis hat.

Vorher:

Ohne Inhaltsverzeichnis

Nachher:

Mit Inhaltsverzeichnis

Blog und Wiki

Externe Links

Das zusätzliche Icon, das bei externen Links angezeigt wird, ist jetzt nur dann sichtbar, wenn ein Link auf andere Websites als meine eigenen zeigt.

D. h. ein Link vom Blog zu meinem neuen Wiki wird nicht als extern markiert. Ein Link vom Blog zu Wikipedia schon.

Video Shortcode

Ich habe den Shortcode für die Einbindung von Videos verbessert:

Man kann jetzt ein Vorschaubild selbst definieren.
Man kann Markdown innherhalb von caption verwenden.
Der Vorgabetext Link to Video ist via linktext= änderbar oder in der config.toml via shortcode_video_linktext.
Enthält der Pfad zum Video einen bestimmten Teilstring, dann wird das Video nicht eingebunden und stattdessen ein Infotext angezeigt.

Statt das Video einzubinden, wird eine Meldung angezeigt.
Man kann type= selbst angeben für den MIME-Typ der eingebundenen Datei oder sich darauf verlassen, dass der Shortcode diesen selbst anhand der Dateiendung erkennt und ausgibt.

Prinzipiell kann man mit dem Shortcode Video auch reine Audiodateien einbinden. Das ist zwar vermutlich nicht so gut für irgendwas, aber es funktioniert trotzdem.

Alle Möglichkeiten werden auch in der Dokumentation zum “Mitmachen” aufgelistet, siehe hier.

Hugo sortiert jetzt richtig

Sat, 14 May 2022 09:30:18 +0200

Seit der Version 0.97.0 (vom 14. April 2022) sortiert Hugo auch bei Umlauten und Akzent-Zeichen richtig.

Bisher war die Sortierung für Umlaute kaputt, sodass z. B. die folgende Reihenfolge entstand:

Allgemein, Autos, Unfall, Zeit, ÖRR, Überholabstand

Seit Version 0.97 wurde das richtig gestellt, sodass entsteht:

Allgemein, Autos, ÖRR, Überholabstand, Unfall, Zeit

Kann man z. B. hier sehen, wo in der alten Version am Ende die ganzen Tags mit Ü am Anfang gelistet waren.

Für Debian gibt es .deb-Pakete für die normale und erweiterte Hugo-Variante auf der oben verlinkten Release-Seite.

Mal wieder Änderungen im Blog und im Wiki

Tue, 03 May 2022 22:19:53 +0200

Es haben sich wieder ein paar Änderungen im Blog und im Wiki angesammelt, die ich hier dokumentiere.

Suche beschleunigt

Die schönste Änderung ist die Suche, die jetzt sehr schnell Ergebnisse liefert. Zuvor dauerte die Suche je nach Stärke der Client-CPU von vielen Sekunden bis “Browser will Tab schließen” und die Suchergebnisse ließen auch zu Wünschen übrig.

Jetzt dauert es nur noch eine bis wenige Sekunden.

Ich habe dazu einen eigenen Blogbeitrag geschrieben, siehe hier.

Sortierte Tags und Kategorien

Die Listen der Kategorien und Tags in Blogbeiträgen ist jetzt alphabetisch sortiert. Das hat der Entwickler nach meiner Anfrage in sein Theme implementiert, da es ursprünglich unsortiert war bzw. in der selben Reihenfolge angezeigt wurde, wie es auch im Front Matter eingetragen war.

Alphabetisch sortiert ist jetzt die Voreinstellung. Man kann aber auch auch in der config.toml im Bereich [params] einstellen, sodass nach Häufigkeit sortiert wird:

taxonomySortingMethod = "popularity"

So sieht es jetzt aus (früher war es “unsortiert”):

Sortierte Taxonomie

WebP als Standard

Da jetzt immer automatisch Bildvarianten auch in JPG erstellt werden, habe ich meine Programme so eingestellt, dass Bilddateien immer im WebP-Format abgespeichert werden. Das betrifft Screenshots, ImagePipe auf Android und mein Script, das automatisch Bilder für den Blog aufbereitet.

Rand um Bilder

Vri hat den Rand um Bilder herum verschönert.

Früher:

Alter Rand für Bilder

Jetzt:

Neuer Rand für Bilder

Inhaltsverzeichnis inline

Das Inhaltsverzeichnis befindet sich nicht mehr rechts in der Sidebar sondern immer ganz oben im Blogbeitrag. Es wird ein details-Element verwendet, da aber per Voreinstellung offen ist. Hintergrund ist die Darstellung auf mobilen Geräten, da dort das Inhaltsverzeichnis innerhalb der Sidebar erst ganz am Ende der Seite dargestellt wird. Mit der Änderung hat man auch auf Mobilteräten einfachen Zugriff auf das Inhaltsverzeichnis.

Seit der Umstellung finde ich es auch angenehmer, dass man direkt am Anfang des Blogbeitrags kurz überblicken kann, um was es geht. Selbst auf einem großen Bildschirm auf dem Desktop war das bisher nicht gegeben, weil man eher nicht nach rechts in die Sidebar geschaut hat.

Inhaltsverzeichnis ist jetzt inline, hier am Beispiel eines anderen Beitrags.

Render Hook für Bilder angepasst

Keine automatische Verlinkung des Originals

Mein Render Hook für Bilder verlinkt nicht mehr automatisch zum Originalbild, falls dieses breiter ist als 1000 Pixel. Das war sowieso nie intuitiv und weit weg von dem, was Markdown normalerweise macht. Man will schließlich selbst entscheiden, ob etwas verlinkt werden soll und wohin.

Für eine einzelne Seite bekommt man das alte Verhalten zurück, indem man im Front Matter imageAutoLink: true einfügt. Das mache ich bei Blogbeiträgen, bei denen ich hoch aufgelöste Bilder eingefügt hatte und von diesem Verhalten ausging. Erst ab heute werde ich solche Bilder manuell verlinken.

Zudem es jetzt auch wieder möglich, mit der Markdown-Syntax ein Bild selbst irgendwohin zu verlinken, optional auch auf das hochaufgelöste Originalbild. Soll so Link auf das Originalbild eingefügt werden, so kann man diese Syntax verwenden:

[![](bild.jpg)](bild.jpg)

Das ist aber nur sinnvoll für Bilder ohne Beschreibungstext drunter, da dieser sonst auch als Link gerendert wird.

So langsam erschließt sich mir, weshalb die Leute von Hugo das so implementiert haben, dass alles, was mehr benötigt, als nur Bilder ganz einfach einzubinden, per figure-Shortcode gemacht wird.

Oder ein Bild mit Verlinkung auf eine URL

[![](bild.jpg)](/lala)

Angabe von Breite und Höhe

Mit dem Render Hook eingebundene erhalten jetzt auch eine passende Breiten- und Höhenangabe im HTML-Code, damit der Text dahinter beim Laden von Bildern mit einer langsamen Internetanbindung nicht mehr nach unten springt, sobald das Bild geladen wurde.

Bei Galerien passiert das aber noch immer, weil dafür ein Shortcode verwendet wird, der von einem größeren Projekt stammt und den ich nicht so einfach mal anpassen möchte.

Neuer figure Shortcode

Ich habe einen neuen Shortcode figure erstellt, der auf dem aktuellen Render Hook basiert (siehe oben).

Dadurch werden, wie auch im Render Hook, nur dann kleine Bildvarianten erstellt, wenn das Originalbild größer als 816 Pixel ist. So gibt es keine vermatschten Bilder mehr, die dadurch entstehen, dass ein kleines Bild vergrößert wird.

Zusätzlich erlaubt der Shortcode die Verwendung von Markdown für den Parameter caption (wie auch beim builtin Shortcode figure), sodass es z. B. möglich wird, einen Link auf eine Lizenz zu setzen, wie das von OpenStreetMap bei Einbindung deren Karten gefordert wird.

Beispiel mit einem Link in der Beschreibung (“caption”):

{{< figure src="2022-05-03-inline-inhaltsverzeichnis.webp" link=""
alt="" title="Ein Titel" width="350"
caption="Eine Caption mit URL wegen Copyright by [Natenom](/)" >}}

Ergebnis:

Eine Caption mit URL wegen Copyright by Natenom

Ich werde die anderen Parameter, die im builtin-Shortcode figure von Hugo möglich sind, in Zukunft auch noch implementieren, wenn ich sie benötige.

Auswirkungen der Dezentralität von Mastodon und Fediverse – Traffic und Last für Webserver

Tue, 03 May 2022 12:28:47 +0200

Wenn man z. B. auf Twitter einen Blogbeitrag teilt, dann prüft der Twitter-Bot, ob es Meta-Angaben wie twitter:image und twitter:description im HTML-Quelltext des Blogbeitrags gibt, um anhand dieser Information das genannte Coverbild vom Server abzurufen und auf der eigenen Plattform mit Vorschaubild und Textauszug darzustellen.

Twitter Cards nennt sich dieser Standard. Daneben gibt es noch den Standard “Open Graph” (og:image und og:description), den Facebook verwendet, aber auch Mastodon und Friendica.

Im Fall von Facebook und Twitter holt sich deren Bot das einmalig vom Webserver ab, auf dem der Blog ausgeliefert wird.

Und was passiert in einem Netzwerk aus hunderten und möglicherweise tausenden von Instanzen? Richtig, jede Instanz macht das selbe wie Twitter und Facebook.

Last für den Webserver

Nachdem ich heute einen Blogbeitrag auf Mastodon verlinkt hatte, habe ich danach die Logs des Webservers ausgewertet mit dem Befehl:

cat blog.log | cut -d'"' -f 6 | grep -E -i "friendica|mastodon" | grep -v Bot | sort | uniq

Ergebnis:

[…]
http.rb/5.0.4 (Mastodon/3.5.1; +https://floss.social/)
[…]
http.rb/5.0.4 (Mastodon/3.5.1; +https://freiburg.social/)
http.rb/5.0.4 (Mastodon/3.5.1; +https://graz.social/)
http.rb/5.0.4 (Mastodon/3.5.1; +https://hannover.social/)
[…]
http.rb/5.0.4 (Mastodon/3.5.1; +https://hessen.social/)
[…]

Insgesamt waren es 110 verschiedene Instanzen. Das bedeutet, dass 110 mal der Quelltext des Blogbeitrags und das Coverbild heruntergeladen wurden. Man sollte daher gut wählen, wie groß das Coverbild ist.

Skaliert nicht gut

Ich habe einen relativ kleinen Account auf Mastodon mit um 680 Followern. Was aber, wenn jemand viele Tausend oder gar Millionen Follower hat, die auf tausenden verschiedenen Instanzen sind? Das skaliert dann vermutlich irgendwann nicht mehr sehr gut.

Angenommen, ein Coverbild wäre 1 MB groß und es würden 3000 Instanzen abrufen, dann hätte man nur für das Verlinken eines Blogbeitrags schon 3 GB Traffic verursacht. Dazu kommt, dass die Bots der Instanzen ziemlich zur selben Zeit alles abrufen. Ich habe das live im Log des Webservers verfolgt und das ballert da ordentlich durch.

Lösung?

Eine Idee von jemandem auf Mastodon war, dass die Mastodon Instanz, auf dem man den Blogbeitrag zuerst teilt, selbst eine Vorschau und den Text dazu erstellt und die anderen Instanzen das dort abholen. Das würde die Last aber nur vom Webserver weg und hin zu der Instanz des Benutzers verschieben. Besser wäre es, wenn man das auf verschiedene Server verteilen könnte.

Suchfunktion im Blog massiv beschleunigt (und wie man Beiträge von der Suche ausschließen kann)

Sun, 01 May 2022 15:11:04 +0200

Obwohl im Blog als auch im Wiki dieselbe Suche (FuseJS) verwendet wird, dauert es im Blog deutlich länger bis die Ergebnisse angezeigt werden, als im Wiki, wo die Ergebnisse fast sofort zu sehen sind.

Meine erst Vermutung war, dass es unter anderem daran liegt, dass es im Blog um die 2600 Beiträge gibt, während es im Wiki “nur” 578 Seiten sind. Daraus ergibt sich für den Blog eine Dateigröße für die index.json-Datei von über 3,8 MiB, während es im Wiki 0,87 MiB sind.

Die genannte json-Datei muss der Client-Browser herunterladen, um darin dann per JavaScript lokal die Suche anzuwenden. Und bei einer Datei um 3,8 MiB dauert das dann sehr lange.

Erst später stellte ich fest, dass es weit mehr Optimierungspotential durch die Konfiguration der Suche via FuseJS gibt.

Es gibt also zwei Ansätze für die Optimierung der Suchfunktion im Blog.

FuseJS Einstellungen optimieren
Suchindex verkleinern durch Auschließen von Beiträgen

Letzteres kann man auch umsetzen, wenn man bestimmte Inhalte generell aus der Suche ausschließen möchte.

FuseJS optimieren (das größte Potential)

Es gibt viele Einstellungen für FuseJS. Die Wirkung der meisten Einstellungen verstehe ich nicht wirklich. Ich habe also erst einmal im Blog das selbe eingestellt wie auch in der Suche im Wiki:

shouldSort: true,
includeMatches: true,
threshold: 0.0,
tokenize:true,
location: 0,
distance: 100,
maxPatternLength: 32,
minMatchCharLength: 3,

(Die Syntax für die Einstellungen im Wiki ist eine andere als im Blog. Denn dort sind die Einstellunen nicht im Front Matter hinterlegt, sondern direkt im JavaScript, da ich die Originalsuchfunktion im Wiki selbst durch FuseJS ersetzt hatte)

Im Blog wird daraus in der Datein config.toml im Bereich params:

search.fuse.threshold = 0.0
search.fuse.location = 0
search.fuse.distance = 100
search.fuse.minMatchCharLength = 3

Hier die Hilfeseite zu FuseJS, wie es im Blog verwendet wird.

Hier die vollständige Liste der Einstellungen für FuseJS gibt es hier.

Ergebnis der vom Wiki übernommenen Einstellungen

Vor den Änderungen hatte eine Suche nach z. B. “ettlingen und zurück” im Chromium-Browser 20 Sekunden gedauert und es wurden 1741 Ergebnisse gefunden, von denen nur das erste Ergebnis alle Begriffe beinhaltete.

Die vielen weiteren Ergebnise sind vermutlich dem Fuzzy-Search geschuldet. Aber damit kann ich persönlich eh nichts anfangen, das konnte also eh weg.

Suche im Blog mit alten Einstellungen.

Nach der Änderung der Sucheinstellungen dauert die Suche weniger als 1 Sekunde und es wird nur das einzig passende Ergebnis angezeigt:

Suche im Blog mit neuen Einstellungen.

Bei anderen Suchbegriffen, wie z. B. “Staatsanwaltschaft”, wurden wegen Fuzzy-Search Ergebnisse gefunden, die den Begriff “Staatsanwaltschaft” gar nicht beinhalteten sondern nur eine Teilmenge der selben Buchstaben in anderen Konstellationen und Wörtern. So war ein Ergebnis z. B. der Blogbeitrag mit dem Titel “Fotografie: Landschaft”, der nur Fotos und gar keinen Text beinhaltete.

Erweiterte Suche aktiviert

Ich habe im Blog für FuseJS auch gleich die erweiterte Suche aktiviert, denn damit kann man tolle Dinge machen, wie man hier nachlesen kann.

So findet man z. B. alle Blogbeiträge, die mit dem String “Fotos” beginnen:

^Fotos

Oder mit dem String “werfen” enden:

werfen$

Mit den alten Einstellungen für die Suche findet diese für “werfen” 2216 Ergebnisse und die meisten beinhalten den Begriff nicht einmal.

Leerzeichen werden als AND verwendet und für OR nutzt man Pipe-Zeichen (|).

Zur Aktivierung der erweiterten Suche fügt man in die Datei config.toml im Bereich [params] ein:

search.fuse.useExtendedSearch = true

Man findet zusätzlich noch ein paar mehr relevante Ergebnisse auch ohne explizite Verwendung der erweiterten Möglichkeiten.

Ergebnis der Optimierung der FuseJS-Einstellungen

Jetzt bin ich auch im Blog mit der Suchfunktion sehr zufrieden. Ich habe bisher alles gefunden, wonach ich testweise gesucht habe, und das ohne viele, viele weitere unnötige Suchergebnisse.

Dazu gibt es jetzt noch erweiterte Suchfunktionen, wie oben beschrieben. Damit muss ich mich nur erinnern, welche Begriffe ich in einem Beitrag verwendet haben könnte.

Zum Beispiel hatte ich mal den Spruch “rechter Reifen Mittelstreifen” verwendet, den ich jetzt so auch finde. Zusätzlich kann ich Beiträge finden, die genau diesen String enthalten ODER mit dem String “bußgeldstelle” beginnen mit "rechter reifen mittelstreifen"|^bußgeldstelle und das Ergebnis beinhaltet 17 Blogbeiträge:

Sucht man nur nach “bußgeldstelle”, dann werden 26 Blogbeiträge gefunden.

Und die Suche ist jetzt schnell, die Ergebnisse sind immer nach circa einer Sekunde da (in Chromium, in Firefox aus dem selben Rechner nach ca. 3 bis 4 Sekunden..

Und als mir dann noch einfiel, dass die Bußgeldstelle mir gegenüber mal die Kombination “scharf rechts” verwendete, kann ich auch danach noch suchen mit dem Suchbegriff bußgeldstelle "scharf rechts" und das Ergebnis ist:

Kurz: Die neue Suche rockt 👍 😄

Bestimmte Dinge aus der Suche ausschließen (wenig Potenzial)

Mein erster Ansatz war es, bestimmte Dinge aus dem Suchindex auszuschließen. Erst danach probierte ich die Optimierung der Einstellungen von FuseJS aus, das letzlich zum erhofften Performanceschub führte.

Ich will das hier aber trotzdem stehen lassen, da es vielleicht je nach Website nützlich sein kann, bestimmte Kategorien oder alte Blogbeiträge vom Suchindex auszuschließen.

Kategorien ausschließen

Man kann Kategorien ausschließen, die sowieso wenig gesucht werden, weil sie z. B. fast nur Fotos enthalten oder auch Kategorien, zu denen es schon lange keine Inhalte mehr gab, wie hier im Blog z. B. “Spiele”.

Alte Beiträge ausschließen

Genau. Siehe unten. 😊

Inhalt (teilweise) aus der Suche entfernen

Derzeit beinhaltet die json-Datei noch den kompletten Inhalt eines Blogbeitrags. Das könnte man ändern und nur noch z. B. Tags, Kategorien, Daten aus dem Front Matter und vielleicht noch die ersten 250 Zeichen des Inhalts jedes Blogbeitrags in die json-Datei einfügen.

Das gefällt mir aber nicht, da man dann auch nur Dinge findet, die in diesen ersten 250 Zeichen enthalten sind.

Umsetzung an einem Beispiel

Hier beispielhaft eine Erläuterung, wie man Blogbeiträge von der Suche (bzw. von der Eintragung in die index.json) ausschließt, die die folgenden Bedingungen erfüllen.

Beiträge, die älter sind als 5 Jahre.
Beiträge, die zu den folgenden Kategorien gehören:
- Fotografie
- Mumble
- Musik
- Spiele

Zur Umsetzung muss man die Datei themes/hugo-theme-bootstrap/layouts/index.json nach layouts/index.json kopieren und wie folgt anpassen:

{{- $.Scratch.Add "index" slice -}}
{{- range .Site.RegularPages -}}
    {{- if ge (sub now.Year .Date.Year) 4 -}}
    {{- else if or (in .Params.categories "Musik") (in .Params.categories "Fotografie") (in .Params.categories "Mumble") (in .Params.categories "Spiele") -}}
    {{- else -}}
        {{- $date := .Date.Format $.Site.Params.dateFormat -}}
        {{- $title := .Title }}
        {{- if $.Site.Params.titleCase -}}
            {{- $title = title $title -}}
        {{- end -}}
        {{- $img := "" -}}
        {{- if .Params.Images -}}
        {{- $img = index .Params.Images 0 | absURL -}}
        {{- else -}}
        {{- $images := .Resources.ByType "image" -}}
        {{- $featured := $images.GetMatch "*feature*" -}}
        {{- if not $featured }}{{ $featured = $images.GetMatch "{*cover*,*thumbnail*}" }}{{ end -}}
        {{- with $featured -}}
            {{- $img = $featured.Permalink -}}
        {{- end -}}
        {{- end -}}
        {{- $item := (dict "title" $title "tags" .Params.tags "categories" .Params.categories "series" .Params.series "content" .Plain "permalink" .Permalink "date" $date "img" $img) -}}
        {{- $.Scratch.Add "index" $item -}}
    {{ end }}
{{- end -}}
{{- $.Scratch.Get "index" | uniq | jsonify -}}

Um einen Hinweis auf der Suchseite einfügen zu können, kopiert man die Datei themes/hugo-theme-bootstrap/layouts/_default/search.html nach layouts/_default/search.html und trägt z. B. ein:

Hinweis: Einige Blogbeiträge sind von der Suche ausgeschlossen. Für Details hier klicken.

Ergebnis der Optimierung via Weglassen

Im Ergebnis wurde die index.json statt 3,8 MiB nur noch ca. 1,4 MiB groß. Ohne Optimierung der Sucheinstellungen von FuseJS wurde das aber nur etwas schneller.

Verbesserung des Render Hooks für Bilder hier im Blog (und im Wiki)

Wed, 27 Apr 2022 02:20:37 +0200

Nach dem letzten Blogbeitrag zu meinem neuen Render Hook zum Einbinden von Bildern in Hugo habe ich von SuperTux88 wertvolle Rückmeldungen bekommen. Vielen Dank dafür. 👍

Update

Update 1: Den Shortcode und den Hook gibt es hier zum herunterladen, siehe unten.

Update 2 (04.04.2023): Es gibt wieder einen verbesserten Render Hook, der sich am Ursprungsformat eines Fotos orientiert, nur auf Webp für die Bildvarianten ausgelegt ist und somit sehr viel schneller ist und viel weniger Daten produziert, siehe hier.

Die Rückmeldungen

Die Rückmeldungen sind im Einzelnen aufgelistet…

Mehr Monitor

Wenn jemand einen 4k Monitor hat, dann freut er sich über Bilder, die höher aufgelöst sind als nur 816 Pixel in der Breite.

Meine Lösung: Wenn das Originalbild breiter ist als 1632 Pixel, dann wird zusätzlich noch ein hoch aufgelöstes Bild erzeugt mit 1632 Pixel Breite. In meinem Blog trifft das z. B. auf einzelne Fotos oder Panoramabilder zu, die mindestens 2000 Pixel breit sind.

WebP und JPG

Hugo kann man anweisen, die Varianten des Originalbilds immer als WebP zu erzeugen, auch wenn das Original ein anderes Format hat.
~~Safari auf Mac OS kann noch nicht mit WebP umgehen~~. Korrektur: Nur Safari auf alten Mac OS Systemen kann kein WebP. Es hängt wohl vom Betriebssystem ab und das aktuelle Mac OS kann WebP.

Lösung: Für alle Bilder werden jetzt kleine Bildvarianten in den Formaten JPG und WebP erzeugt. Beide Dateiformate werden zur Verfügung gestellt. WebP ist der Standard und JPG das Fallback (z. B. für Safari und Mac OS).

4k “simulieren”

Im Browser auf 200 % zoomen, dann bekommt man auch die große Bildvariante geliefert, wenn sie vorhanden ist, siehe nächster Abschnitt.

Wie der neue Render Hook arbeitet

Und aus all den Vorschlägen und viel Arbeit ist nun das neue Render Hook entstanden, das wie folgt arbeitet (und damit etwas anders als bisher):

Ist das Originalbild eine .webp-Datei, dann wird dieses konvertiert und eine .jpg-Datei erzeugt, sodass beide Formate vorliegen.
Ist das Originalbild eine .jpg-Datei, dann wird dieses konvertiert und eine .webp-Datei erzeugt, sodass beide Formate vorliegen.
Ist das Originalbild eine andere von Hugo unterstützte Datei, dann wird diese konvertiert und sowohl eine .webp- als auch in eine .jpg-Datei erzeugt, sodass beide Formate vorliegen.
Ist das Originalbild 816 Pixel breit oder breiter, dann wird ein srcset erzeugt für die Breiten 360, 500, 816 und optional bei Bildern über 1632 Pixeln noch zusätzlich 1632 Pixel Breite.
Ist das Originalbild kleiner als 816 Pixel, dann wird nur das Originalbild ohne srcset in der Seite eingebunden und es findet keine Verlinkung statt und es werden keine kleinen Bildvarianten erzeugt.
Ist das Originalbild breiter als 1000 Pixel, dann wird um die einbegundene verkleinerte Variante herum ein Link auf das Originalbild gesetzt.
In allen Fällen wird das Bild per picture-Element eingebunden. Dieses enthält immer als Voreinstellung per source-Element (Dokumentation) alle Bildgrößen im .webp-Format und als Fallback im img-Element alle Bildgrößen im .jpg-Format.
Liegt das Bild nicht im Page Bundle, dann wird es ohne irgendwelche Zusätze per img-Element eingebunden.
Bilder werden immer per Lazy loading eingebunden.

Vorteile der neuen Variante des Render Hooks

Ich kann für die Originalbilder alle Formate verwenden, die Hugo konvertieren kann. Das sind bmp, gif, jpeg, jpg, png, tif, tiff, webp. Alle kleinen Bildvarianten werden jedoch im JPG- und WebP-Format zur Verfügung gestellt.

Beispiele

So sieht es z. B. aus, wenn das Originalbild eine circa 5000 Pixel breites WebP-Datei ist (Pfade und Dateinamen auf das Wesentliche gekürzt):

<figure class="image-caption">
    <a href="lala.webp">
        <picture>
            <source type="image/webp"
                srcset="360x.webp 360w,500x.webp 500w,816x.webp 816w, 1632x.webp 1632w"
                sizes="(max-width: 424px) 360px, (max-width: 596px) 500px, (min-width: 565px) 816px,(min-width: 1200px) 1632px"
            />
            <img alt="lala"
                    srcset="360x.jpg 360w, 500x.jpg 500w, 816x.jpg 816w, 1632x.jpg 1632w,"
                    sizes="(max-width: 424px) 360px, (max-width: 596px) 500px, (min-width: 565px) 816px,(min-width: 1200px) 1632px"
                    src="1632x.jpg" title="lala" loading="lazy" />
        picture>
    a>
    <figcaption>lalafigcaption>
figure>

Und so sieht es aus, wenn die Datei schmaler als 816 Pixel ist:

<figure class="image-caption">
    <picture><source type="image/webp" srcset="330x.webp" />
    <img alt="lala" src="lala.jpg" title="lala" loading="lazy" />picture>
    <figcaption>lalafigcaption>
figure>

Unschöne Platzverschwendung

Update

29.04.2022: Eindeutig Unfähigkeit 🤪

Mit den genannten Befehlen wird das Ergebnis ins HTML gerendert. Das Bild wird aber schon beim Befehl .Resize generiert. Danke für die Klarstellung.

Durch eine zur Verfügung gestellte Beispielimplementierung von SuperTux88 hab ich einige Dinge über Hugo gelernt, die ich vorher nicht wusste. Bin halt Anwender, kein Programmierer. 🤪 Dadurch konnte ich den Render Hook so umsetzen, wie ich es eigentlich vor hatte.

Zum Beispiel werden jetzt nicht mehr immer alle möglichen Bildgrößen erzeugt sondern nur die benötigten. Für den Blog bedeutet das eine Verkleinerung der genertierten Bilddateien von 700 MiB auf 244 MiB und für das Wiki von 644 MiB auf 355 MiB.

Entweder liegt es an meiner Unfähigkeit oder an Hugo, dass Bildvarianten, die gar nicht verwendet werden und in irgendwelchen If-Bedingungen im Render Hook stehen und gar nicht erfüllt werden, trotzdem jedes Mal erzeugt werden. Stört mich nicht sehr, da sie niemals ausgeliefert werden, aber sie sind da und belegen Speicherplatz. Vielleicht kann ich das in Zukunft noch lösen.

~~Laut Dokumentation sollte meinem Verständnis nach das Bild erst dann generiert werden, wenn einer dieser “Befehle” auf das Bild ausgeführt wird: Permalink, RelPermalink, Width, Height.~~

~~Im Render Hook reicht aber schon so eine Zeile aus, um das Bild zu generieren~~:

{{- $img_webp := $img.Resize "600x webp" -}}

~~Wer darüber etwas weiß, darf sich gerne melden. 🙂~~

Verbesserungen?

Vielleicht wäre es sinnvoller, immer auf die konvertierte jpg-Datei zu verlinken. Oder auf die webp-Datei? Kann man das irgendwie so in HTML einbinden, dass sich der Browser je nach Fähigkeit selbst aussuche, welchen Link zu welchem Ziel er wählt?

Nützliches zum Picture-Tag

Antwort auf die Frage, ob man ein picture-Element in ein figure-Element stecken darf, siehe hier. Spoiler: Definitiv. Und hier zur weiteren Lektüre dazu.

Shortcode und Hook zum Herunterladen

Das .txt am Ende muss entfernt werden.

Einbindung von Bildern in Hugo – Infos und eigener Render Hook

Sun, 24 Apr 2022 12:01:40 +0200

Ein paar Informationen dazu, wie man in Hugo Bilder einbinden kann, welche Hilfsmittel es gibt und auch, was mit Bordmitteln von Hugo nicht möglich ist. Und zum Schluss ein eigener Render-Hook, der hilfreiche Dinge macht.

Update

Update 1 (27.04.2022): Im Blog wird jetzt ein aktuelleres und verbessertes Render Hook verwendet, siehe hier.

Bilder in Hugo

Es gibt verschiedene Möglichkeiten zur Einbindung von Bildern in Hugo.

Standard-Markdown-Syntax
Render Hook
Theme-Erweiterungen
Shortcode

Standard-Markdown-Syntax – Tut, kann aber nix

Die Standard-Markdown-Syntax, die Hugo von sich aus unterstützt, funktioniert zwar, kann dafür aber nichts:

![Alt Text](/pfad/zu-datei.jpg)

Das bedeutet konkret:

Keine Möglichkeit zur Angabe, wie groß das Bild dargestellt wird, es wird immer maximal groß angezeigt.
Es werden keine kleineren Bildvarianten erstellt. Ist ein Bild z. B. 10 MiB groß, 2000 Pixel breit und beträgt der zur Verfügung stehende Platz im Blog nur 800 Pixel in der Breite, so wird trotzdem das Originalbild mit 2000 Pixeln eingebunden, nur eben verkleinert und man muss 10 MiB herunterladen.

Render Hook

Für einen Render Hook erstellt man die Datei layouts/_default/_markup/render-image.html.

Hier kann man Programmcode hinterlegen, der ausgeführt wird, sobald die Standard-Markdown-Syntax für die Einbindung von Bildern gerendert wird.

Dies hat den Vorteil, dass man im Gegensatz zu einem Shortcode beim Standard-Markdown bleiben oder diesen auch erweitern kann.

Theme-Erweiterungen

Das hier im Blog verwendete Theme ‘Bootstrap’ stellt einige Möglichkeiten zum Einbinden von Bildern bereit. So kann man z. B. Bilder verkleinert anzeigen lassen und dafür wird auch wirklich eine kleinere Variante des Originalbildes erzeugt (wenn das Bild Teil des Page Bundles ist).

Es kann eine erweitere Standard-Markdown-Syntax verwendet werden, wie z. B.

![Alt Text](pfad/zu-datei.jpg?height=200px)

Letztlich wird das üer einen Render Hook ermöglicht, siehe oben.

Shortcode

Es gibt im Netz verschiedene Lösungen in Form von Shortcodes, die z. B. automatisch kleinere Varianten der Bilder erstellen und diese einbinden statt des Originals und es auch ermöglichen, einen Link auf das Originalbild zu setzen, einen Text unter dem Bild anzuzeigen und mehr.

Solch einen Shortcode hatte ich bis vor kurzem auch verwendet. Jedoch muss man für Shortcodes eine andere Syntax verwenden, z. B. für den Shortcode bildeinbinden:

{{< bildeinbinden src="" link="" alt="" title="" width="" >}}

So nah am Standard, wie möglich

Ich bevorzuge die Verwendung von gegebenen Standards statt einer eigenen Lösung. Denn so werden Probleme beim Wechsel eines Themes oder auch beim Export minimiert.

So verwende ich lieber die Standard-Markdown-Syntax für das Einbinden von Bildern in Hugo statt eines eigenen Shortcodes, dessen Parameter man sich mehr oder weniger merken muss. Zudem ist es für neue Menschen leichter.

Deshalb habe ich mich hier im Blog für einen Render Hook entschieden, um Bilder einzubinden.

Der eigene Render Hook

Als Ausgangspunkt habe ich diese Version hier verwendet und für meine Anforderungen angepasst.

Die Syntax ist die selbe wie in Hugo:

![Alt-Text](bild-200px.jpg "Titel")

z. B.

![Ein Demobild mit Radfahrenden, um zu verdeutlichen, wie ein Bild mit dem eigenen Render Hook eingebunden wird. ](bild-200px.jpg "Radfahrende in Pforzheim")

Im Ergebnis das 200 Pixel breite Bild, das nicht automatisch verlinkt wird, weil es zu klein ist:

Radfahrende in Pforzheim

Und hier ein Beispiel eines Bildes, das 2000 Pixel breit ist und deshalb automatisch zum Originalbild verlinkt, während automatisch eine erzeugte kleinere Variante (800 Pixel breit) des Originalbildes hier eingebunden wird.

Aus:

![Fahrrad auf einem Feldweg und mit einem 'Vorsicht Kinder' Schild auf dem Gepäckträger](bild-gross.jpg "Das Schild habe ich zuvor am Straßenrand gefunden.")

Wird:

Das Schild habe ich zuvor am Straßenrand gefunden.

Man kann jedoch sowohl den Alt-Text als auch den Titel weglassen.

Hinweis

Mir gefällt jedoch an dieser Syntax, dass man immer daran erinnert wird, einen Beschreibungstext zu hinterlegen und nicht nur einen Titel. Denn der Beschreibungstext (Alt-Text) ist wichtig für Menschen mit Sehbeeinträchtigungen.

Ich werde in Zukunft somit darauf achten, solche Texte zu hinterlegen. In der Vergangenheit habe ich das im Blog fast nie getan.

Quelltext

Hier der fertige Render Hook layouts/_default/_markup/render-image.html:

{{ $autolinking := .Page.Param "imageAutoLink" | default true }}
{{- $img := .Page.Resources.GetMatch .Destination -}}
{{- if and (not $img) .Page.File -}}
{{ $path := path.Join .Page.File.Dir .Destination }}
{{- $img = resources.Get $path -}}
{{- end -}}
{{- with $img -}}
{{- $large := $img.Resize "816x" -}}
{{- $medium := $img.Resize "500x" -}}
{{- $small := $img.Resize "360x" -}}

{{ if gt $img.Width 816 }}
	{{ if and (gt $img.Width 1000) (eq $autolinking true ) }}{{- $img.RelPermalink -}}">{{ end }}
    {{ $.Text }}" srcset="
        {{ $small.RelPermalink }} 360w,
        {{ $medium.RelPermalink }} 500w,
        {{ $large.RelPermalink }} 816w" sizes="(max-width: 424px) 360px,(max-width: 596px) 500px,(min-width: 565px) 816px" src="{{ $small.RelPermalink }}" title="{{ $.Title }}" loading="lazy" />
    {{ if and (gt $img.Width 1000) (eq $autolinking true ) }}{{ end }}
{{ else }}
    {{ $.Text }}" src="{{ $img.RelPermalink }}" loading="lazy" title="{{ $.Title }}" />
{{ end }}
    {{ with $.Title | safeHTML }}{{ . }}{{ end }}

{{- else -}}
{{ .Destination | safeURL }}" alt="{{ $.Text }}" title="{{ $.Title }}" loading="lazy" />{{- end -}}

Wie der neue Render Hook funktioniert

Und so funktioniert der neu erstellte Render Hook render-image.html:

Bild ist breiter als 816 Pixel¹:
- Es werden automatisch kleinere Bildvarianten erstellt und via srcset eingebunden.
Bild ist schmaler als 816 Pixel:
- Es werden keine kleineren/größeren Bildvarianten erstellt und auf ein srcset wird verzichtet, es wird nur das Originalbild eingebunden. (Man könnte noch implementieren, dass in letzterem Fall nur die Bildvarianten erstellt werden, die kleiner als 816 Pixel sind. Aber das spare ich mir, da das nur selten vorkommt und das meistens Dateien mit sehr geringen Dateigrößen sind.)
- Hierdurch wird ein sehr kleines Bild wirklich nur so groß angezeigt, wie es auch ist, nicht vergrößert und matschig.
Bild ist breiter als 1000 Pixel:
- Es wird automatisch ein Link auf das Originalbild gesetzt. Das Verlinken kann man unterbinden mit imageAutoLink: false im Front Matter eines Blogbeitrags.
Der angegebene Titel wird unter dem Bild angezeigt.
Der angegebene Alt-Text in eckigen Klammern wird in das alt-Attribut eingefügt.
Die Bilder werden per Lazy loading eingebunden, sodass der Browser sie erst herunterlädt, wenn sie in der Nähe des Sichtbereits im Browser sind. Das spart Ressourcen, falls man nur einen Teil eines Beitrags liest.
Es werden kleine Bildvarianten mit 500 und 360 Pixeln Breite erstellt. Diese sind für die kleineren Ansichten im Blog notwendig, z. B. auf Mobilgeräten.

Ideen für später

Es wäre schön, wenn die Beschreibung aus den Exif-Tags verwendet werden könnte, sofern man keine eigene Beschreibung in Markdown einträgt. Ein Beispiel einer Umsetzung gibt es hier.
Angabe von selbst festgelegter Breite für das Einbinden eines Bildes, wie z. B. hier beschrieben oder auch im hier im Blog verwendeten Theme.

Uffbasse (Aufpassen) – Besser kein srcset bei kleinen Bildern

Man kann Hugo anweisen, kleinere Bildvarianten des Originalbildes zu erstellen, die man dann statt des Originalbildes verwenden kann. Alternativ kann man daraus ein srcset erstellen, sodass der Browser automatisch die passende Größe aussuchen und herunterladen kann.

Jedoch ist dieser Mechanismus der Erstellung von Bildvarianten in Hugo ziemlich “dumm”. Wenn z. B. das Bild nur 200 Pixel breit ist, werden angeforderte größere Bildvarianten trotzdem erstellt und das resultiert dann in einem total zermatschten größeren Bild.

In diesem Screenshot wird das deutlich sichtbar. Das Originalbild (200 Pixel breit) und darunter das Bild, das von Hugo auf Anfrage in 800 Pixel Breite erzeugt wurde, obwohl das Originalbild kleiner ist:

Oben das Originalbild in 200 Pixel breite und darunter das von Hugo angefragte aus dem Originalbild erzeugte Bild mit circa 800 Pixeln, das entsprechend breit angezeigt wird und natürlich total zermatscht ist.

Jedoch kann man in Hugo per .Width die Breite eines Bildes abfragen und nur dann weitere Bildvarianten erstellen lassen, wenn eine Mindestbreite gegeben ist und bei zu kleinen Bildern auf srcset verzichten.

Passt

Ich bin mit der neuen Lösung erst einmal zufrieden. Ich kann die Standard-Markdown-Syntax verwenden, es wird automatisch ein srcset eingefügt und große Bilder werden automatisch zum Originalbild verlinkt. Und zusätzlich werde ich auch noch daran erinnert, einen passenden Alt-Text zu schreiben.

816 Pixel ist die Breite des Inhalts in der Standardansicht meines Blog. ↩︎

Web on Natenoms Blog

Hugo Shortcode kann per Einstellung aufs Original verlinken

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

Hugo Helper erweitert

Neuer Workflow für Blogbeiträge

Mein Hugo Helper Python Script und was es tun kann

Konfiguration

Ein Alias macht das Leben einfacher

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

Allgemeine Infos

Verzeichniswechsel

Kommentar-Datei

Neuer Blogbeitrag

Tmux

Lokale Vorschau einer Website

Tags, Kategorien und deren Häufigkeit

Alles andere finden

Einfache Variante

Erweiterte Variante

Website bauen und hochladen

Hugo Helper herunterladen

Verbessertes Script für Häufigkeit von Kategorien und Tags in einem Hugo Blog (Update 2024-01-09)

Alte Lösung mit Hugo und sehr umständlich

Jetzt ohne Hugo

Detaillierter Ablauf

Update der Daten

Neues Helferlein für Hugo erleichtert das Bloggen

Das Script

Verzeichnisse erstellen

Slug erzeugen

Page Bundle

Datei index.md

Nächster Schritt

Blogbeitrag schreiben

Passt

Kommentare können jetzt via JSON hinterlegt werden – und mir sonstwie zugeschickt werden

Früher mit Isso

Jetzt mit json-Datei

json-Datei nicht veröffentlichen

Noch sehr rudimentär

Beispiel

Nachtrag

Keine Kommentare mehr im Blog, da fast nicht genutzt

Fast nicht genutzt

Keine Kommentare mehr

Kommentare gelöscht

Nur noch Rückmeldungen auf anderen Wegen

Und nu doch wieder

Suche im Wiki verbessert

Weitere Verbesserung für 360°-Fotos und Panoramen hier im Blog

Viewer für 360°-Fotos im Blog verbessert

Verbesserungen des 360°-Viewers

Weitere Möglichkeiten in Zukunft dank Plugins

Metadaten – so wichtig für unvollständige Panoramen

Sooo schön

Kleine, aber nicht mehr aktive Alternative – Pannellum

Mehrere Spheres (360°-Fotos) in einem Blogbeitrag

Eindeutige ID mit .Ordinal

Einbindung per Shortcode

Konfiguration von Nginx

Beispiele

In Zukunft bessere Qualität

Was mir noch fehlt

Lagesensor

Link zum Originalbild

Weiterleitungen für den neuen Foto-Blog

Im Wiki aufgeräumt

Neuerungen in Blog und Wiki

Blog

Datenschutzkonformes iframe

Seiten im Suchindex verstecken

Ähnliche Beiträge

Unter der Haube

Wiki

Navigationsleiste

Interaktive Navigation

Shortcodes

Suchfunktion

Kein HTML-Quelltext mehr

JavaScript für Kommentarfunktion in eigene Datei ausgelagert