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

Datei in VSCode im Kontext eines bestimmten Workspace öffnen

Mon, 08 Jan 2024 03:04:53 +0100

Ich konnte heute mein Helferscript für das Schreiben von Blogbeiträgen nochmals verbessern.

Jetzt ist es auch möglich, direkt im Anschluss den neuen Blogbeitrag (als index.md) innerhalb eines bestimmten Workspace in VSCode zu öffnen.

Wie das geht, ist aber meiner Ansicht nach nicht wirklich intuitiv und deshalb lege ich es hier ab, damit es gefunden werden kann.

So reicht es nicht aus, einfach VSCode beim Start den Dateinamen in der Shell anzugeben. Dann wird nur die Datei geöffnet aber ohne einen Bezug zum Workspace herzustellen und der “Explorer” ist auch nicht verfügbar:

Stattdessen muss man zusätzlich zum Pfad der Datei noch den Pfad zum Verzeichnis des Workspace in der Kommandozeile angeben:

vscode /pfad/blogworkspace/blogpost1/index.md /pfad/blogworkspace

Erst dann ist links der Explorer mit all den zugehörigen Dateien des Workspace sichtbar:

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.

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