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.

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 <script>-Konstrukts einfügt.

So wird aus:

<script>
 const viewer_{{ .Ordinal }} = new […]
</script>

In Ergebnis das hier:

<script>
 const viewer_"2" = new […]
</script>

Details dazu gibt es hier zu lesen und die Lösung ist safeJS.

Der funktionierende Code sieht dann so aus und die Anführungszeichen sind dann weg:

<script>
 const viewer_{{ .Ordinal | safeJS }} = new […]
</script>

Noch mehr Arbeit für die Karte

Optional kann ich für jede Sphere auch einen Kartenausschnitt von OpenStreetMap einbinden, siehe hier. Dabei gibt es jedoch das selbe Problem mit der eindeutigen ID und auch hier lädt nur die erste Karte. Denn das JavaScript referenziert auch mehrere IDs.

Doch das übersteigt meine Fertigkeiten mit JavaScript und Co und deshalb werde ich die Karten bei mehreren Spheres pro Blogbeitrag erst einmal nicht einbinden, bis ich eine Lösung gefunden habe.

Immerhin gibt es unter jeder Sphere optional die Möglichkeit, einen Link zum Standort zu hinterlegen und das werde ich stattdessen nutzen.

Scripte und CSS nur einmal einbinden

So kann ich jetzt auch mehrere Spheres in einem Blogbeitrag einfügen. Doch es werden noch bei jeder Einbindung die notwendigen, externen Scripte eingebunden. Ordinal kann ich hier nicht dafür verwenden, denn der liefert für jeden verwendeten Shortcode innerhalb eines Blogbeitrags eine eindeutige Nummer, jedoch nicht die Information, ob der Shortcode bereits aufgerufen wurde.

Deshalb bietet sich die Funktion .Scratch an.

Mit diesem Code werden Scripte und CSS nur beim ersten Sphere eingebunden, bei weiteren nicht erneut:

<!-- Sphere js und css nur einmalig einbinden -->
{{ if ne ($.Page.Scratch.Get "sphere_used") "true" }}
{{ $.Page.Scratch.Set "sphere_used" "true" }}
Hier Einbindung der Scripte und CSS.
{{ end }}

Als ich heute in meinem Foto-Blog gestöbert hatte, sah ich ein solches Foto. Ohne die entsprechende Formatierung sieht es natürlich total verzerrt aus.

Und dann habe ich ein OpenSource-Projekt gefunden, das es ermöglicht, solche Fotos richtig anzeigen zu lassen. Implementiert in JavaScript, sodass ich das in Hugo sehr einfach selbst einbinden kann.

Das Projekt heißt “Photo Sphere Viewer” und die Website ist photo-sphere-viewer.js.org. Die Installationsanleitung gibt es hier.

Shortcode für Hugo

Für Hugo habe ich ganz Natenom-gemäß – es funktioniert, ist aber nicht schön gemacht – einen Shortcode erstellt. Dieser nutzt die angegebenen Shortcode-Parameter src und caption. Vri wird das dann später in schön implementieren. 😊

Der Quelltext des Shortcodes entspricht hauptsächlich dem Beispiel in der oben genannten Installationsanleitung, enthält aber zustäzlich noch eine deutsche Übersetzung für die Steuerelemente. Und die benötigten JavaScript- und CSS-Dateien habe ich heruntergeladen und stelle sie direkt auf dem eigenen Server zur Verfügung.

{{- $img := (.Page.Resources.ByType "image").GetMatch (printf "*%s" (.Get "src")) -}}
{{- $caption := "" -}}{{ if isset .Params "caption" }}{{ $caption = (.Get "caption" | markdownify ) }}{{ end }}
<head>
    <!-- for optimal display on high DPI devices -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />

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

<!-- the viewer container must have a defined size -->
<div id="viewer" style="width: 100%; height: 60vh;"></div>

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

    });
</script>

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):

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

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

• Waldweg
• Belforter Platz in Leonberg
• Sonne und Landschaft
• Dorfplatz in Hausen an der Würm
• Pfarrgarten in Neuhausen (Enzkreis)
• Baustelle zwischen Perouse und Heimsheim
• Schnee im Wald
• Wartberg in Pforzheim bei Sonnenschein
• Schnappschuss zwischen Althengstett und Möttlingen

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.

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.

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:

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.

Ähnliche Beiträge

Die Liste der ähnlichen Beitrag oberhalb von Blogbeiträgen ist jetzt ansehnlicher geworden, da ich das Datumsformat dort gekürzt habe.

Oben vorher, unten nachher:

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:

Interaktive Navigation

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:

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

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 schreiben</a>
    <a class="btn btn-sm btn-outline-primary" href="https://{{ .host }}/@{{ .username }}/{{ .id }}" target="_blank">Tröt öffnen</a>
  </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-Mail</summary>
  <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 klickst</a>. 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.

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.

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

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

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

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

Template

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

{{ 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">
  <div id="mastodon-comments-buttons">
    <a class="btn btn-sm btn-outline-primary" href="https://{{ .host }}/interact/{{ .id }}?type=reply" target="_blank">Kommentar schreiben</a>
    <a class="btn btn-sm btn-outline-primary" href="https://{{ .host }}/@{{ .username }}/{{ .id }}" target="_blank">Tröt öffnen</a>
  </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>
  document.getElementById('load-comments').addEventListener('click', loadComment)

  function escapeHtml(unsafe) {
    return unsafe
      .replace(/&/g, '&amp;')
      .replace(/</g, '&lt;')
      .replace(/>/g, '&gt;')
      .replace(/"/g, '&quot;')
      .replace(/'/g, '&#039;');
  }

  function loadComment() {
    document.getElementById('load-comments').innerHTML = 'Lade …';
    fetch('https://{{ .host }}/api/v1/statuses/{{ .id }}/context')
      .then(function(response) {
        return response.json();
      })
      .then(function(data) {
      if(data['descendants'] &&
        Array.isArray(data['descendants']) && 
        data['descendants'].length > 0) {
        document.getElementById('mastodon-comments-list').innerHTML = "";
        data['descendants'].forEach(function(reply) {
          reply.account.display_name = escapeHtml(reply.account.display_name);
          reply.account.emojis.forEach(emoji => {
          reply.account.display_name = reply.account.display_name.replace(`:${emoji.shortcode}:`,
            `<img src="${escapeHtml(emoji.static_url)}" alt="Emoji ${emoji.shortcode}" height="20" width="20" />`);
          });
          replyCreationDate = new Date(reply.created_at).toLocaleDateString(undefined, { day: 'numeric', month: 'short', hour: 'numeric', minute: 'numeric' });
          replyCreationDateLong = new Date(reply.created_at).toLocaleDateString(undefined, { day: 'numeric', month: 'long', year: 'numeric', hour: 'numeric', minute: 'numeric' });
          mastodonComment =
          `<div class="mastodon-comment">
            <div class="avatar">
              <img src="${escapeHtml(reply.account.avatar_static)}" alt="">
            </div>
            <div class="content">
              <div class="author-wrapper">
                <a class="author" href="${reply.account.url}" rel="nofollow">
                  <span class="author-name">${reply.account.display_name}</span>
                  <span class="author-handle">${escapeHtml(reply.account.acct)}</span>
                </a>
                <a class="date" href="${reply.uri}" rel="nofollow" title="${replyCreationDateLong}">
                  ${replyCreationDate}
                </a>
              </div>
              <div class="mastodon-comment-content">${reply.content}</div> 
            </div>
          </div>`;
          document.getElementById('mastodon-comments-list').appendChild(DOMPurify.sanitize(mastodonComment, {'RETURN_DOM_FRAGMENT': true}));
        });
      } else {
          document.getElementById('mastodon-comments-list').innerHTML = "<p>Keine Kommentare gefunden</p>";
      }
    });
  };
  </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-Mail</summary>
  <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 klickst</a>. Der Inhalt davon bleibt privat und wird nicht hier im Kommentarbereich veröffentlicht.</p>
  </div>
</details></p>

CSS

Das SCSS kommt in die Datei assets/main/scss/_custom.scss:

/* Für Kommentar, die von Mastodon geladen werden. :) */
#mastodon-comments-wrapper {
	#mastodon-comments-buttons {
		margin-bottom: 0.5em;
	}
	#mastodon-comments-list {
		button#load-comments {
			border: 0;
			border-radius: var(--#{$prefix}border-radius);
			background-color: var(--#{$prefix}btn-border-color);
			margin: 0 auto;
		}
		.mastodon-comment {
			display: grid;
			grid-gap: 1em;
			grid-template-columns: auto 1fr;
			.avatar img {
				border-radius: var(--#{$prefix}border-radius);
				position: relative;
				top: 6px;
				width: 48px;
			}
			.content {
				.author-wrapper {
					.author {
						.author-name {
							font-weight: bold;
						}
						&:hover {
							color: var(--hbs-link-color);
							text-decoration: none;
							.author-name {
								color: var(--hbs-link-hover-color);
								text-decoration: underline;
							}
						}
					}
					.date {
						float: right;
					}
				}
			}
		}
	}
}

JavaScript

Es wird die Bibliothek DomPurify benötigt. Die steht unter einer freien Lizenz zur Verfügung und kann somit verwendet werden.

Die Datei habe ich heruntergeladen und nach static/my_js/purify.min.js abgelegt.

Header (auf dem Webserver)

Auf meinem Server sind die Header für den Blog relativ streng eingestellt.

Damit JavaScript Daten von extern laden darf, musste der Header in der Nginx-Konfiguration von:

Eadd_header Content-Security-Policy "default-src 'none'; font-src 'self'; connect-src 'self'; form-action 'self'; img-src 'self' data: https://*.natenom.com https://*.natenom.de; media-src https://*.natenom.com https://*.natenom.de; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; frame-ancestors 'none';";

geändert werden nach:

Eadd_header Content-Security-Policy "default-src 'none'; font-src 'self'; connect-src 'self' https://social.anoxinon.de; form-action 'self'; img-src 'self' https://social.anoxinon.de data: https://*.natenom.com https://*.natenom.de; media-src https://*.natenom.com https://*.natenom.de; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; frame-ancestors 'none';";

Sowohl im Bereich connect-src als auch bei img-src musste die Domain der Mastodon-Instanz eingetragen werden.

Datenschutz

Die Informationen zum Datenschutz wurden um den Bereich “Kommentare” erweitert, siehe hier.

Was noch fehlt

Tröts für Kommentarfunktion nicht automatisch löschen lassen

Meine Mastodon-Tröts werden bei mir derzeit nach einem Monat automatisch gelöscht. Kommentare würden so nach dieser Zeit nicht mehr angezeigt werden.

Es ist jedoch in Mastodon einstellbar, dass bestimmte Tröts nicht gelöscht werden, z. B. solche, die man zu den Lesezeichen hinzugefügt hat. Dadurch könnte ich die Lesezeichen-Funktion aber nicht mehr für andere Inhalte benutzen.

Eine Alternative wäre, die Automatisch-Löschen-Funktion von Mastodon nicht mehr zu verwenden und stattdessen ein externes Script (siehe hier). Dieses Tool könnte man so konfigurieren, dass es keine Toots löscht, die ein bestimmtes Hashtag beinhalten.

Eingerückt

Es wäre schön, wenn auch auf der Seite erkennbar wäre, auf welchen Mastodon-Tröt genau jemand geantwortet hat. Die Reihenfolge passt zwar schon, aber die Einrückungen fehlen noch.

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.

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.

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.

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

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:

<p><a href="/ueber/suche/">Hinweis: Einige Blogbeiträge sind von der Suche ausgeschlossen. Für Details hier klicken.</a></p>

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.

Top Bar

Die TopBars von Blog und neuem Wiki sind jetzt angeglichen und es wird das einfarbige Logo verwendet, das auch noch etwas größer ist und als SVG vorliegt. Zudem wurden beide bezüglich Schrift und Höhe einander angeglichen.

Blog

Wiki

Inline Code

Die Darstellung von Inline-Code wurde verbessert, sodass unterschiedliche Teile in unterschiedlichen Zeilen nicht mehr aussehen, als würden sie zusammen kleben.

Kategorien und Tags

Im Theme, das ich hier im Blog verwende, ist per Voreinstellung in einzelnen Beiträgen nur anhand der Positionierung unterscheidbar, was Kategorien und was Tags sind.

Das haben wir dadurch geändert, dass Tags jetzt immer ein Raute-Zeichen vorangestellt wird, sowohl im Beitrag als auch in der rechten Seitenleiste. Die Idee kam von einem dritten Menschen.🙂

Unter der Haube – CSS -> SCSS

Dann hat Vri noch das ganze CSS aufgeräumt und daraus SCSS gemacht.

Post-Panel

Das Panel, das rechts oben innerhalb von Blogbeiträgen angezeigt wird, wurde bisher beim Herunterscrollen auf mobilen Geräten ausgeblendet und stattdessen ein Icon aus dem Font-Awesome angezeigt. Jetzt ist es dauerhaft sichtbar und dafür konnte das Icon weg.

Keine Lightbox mehr

Bisher gab es im Blog eine Lightbox. Hat man auf ein Vorschaubild geklickt, das mit dem Originalbild verknüpft war, so hat man die Website nicht verlassen, um zum Bild zu gelangen, sondern das Bild wurde in einem kleinen Overlay innerhalb der Website angezeigt.

Das ist ansich eine schöne Sache. Jedoch kommt es so immer wieder vor, dass Bilder, die eigentlich in einer höheren Auflösung vorliegen, in diesem Overlay trotzdem nur verkleinert angezeigt werden. Ganz deutlich merkt man dies bei Panoramafotos. Auch auf mobilen Geräten hat man das sehr gut gesehen, da hier die Vorschaubilder meist so breit sind wie der Bildschirm und das Overlay mit dem Originalbild nicht wesentlich größer war.

Ich habe mich daher heute dazu entschieden, das Lightbox-Script im Blog zu entfernen. Klickt man ein Vorschaubild an, öffnet sich im aktuellen Tab also das Bild. Über den Zurück-Button im Browser gelangt man wieder zur Website.

Ich weiß noch nicht, ob das so bleiben wird und ob das für normale Menschen gut ist, aber für mich passt es erst einmal.

Es wird dadurch auch wieder etwas weniger JavaScript im Blog eingebunden. Das spart für die Lightbox für die .js-Datei und die .css-Datei insgesamt 9 KiB.

Ausgenommen sind Galerien. Diese werden weiterhin in einem (anderen) Overlay auf der aktuellen Seite angezeigt. Das finde ich gut so, denn eine Galerie gehört irgendwie zusammen, während einzelne Bilder eben einzelne Bilder sind.

Seitenliste im Wiki

Die Abstände sind verringert worden, gefällt mir so besser.

Footer im Wiki

Die Farben im Footer sind jetzt richtig.

Neue Icons – Octicons

Im Blog werden an ein paar Stellen Icons von der Schrift Font-Awesome verwendet. Das hat uns beiden nicht sehr gefallen und Vri hat mich auf Octicons hingewiesen. Das ist ein Satz aus frei nutzbaren Icons, die als SVG zur Verfügung gestellt werden.

Vri hat Icons im Panel eines Blogbeitrags deshalb durch diese Octicons ausgetauscht.

Die Icons werden automatisch je nach Hell-/Dunkel-Theme angepasst.

Die Octicons Icons gibt es hier. Dazu wurde auch entsprechend die Lizenz-Seite hier im Blog angepasst.

Auch das Icon für externe URLs ist jetzt eines von Octicons.

Jetzt ohne JavaScript

Die Icons im Panel eines Blogbeitrags (Kommtentare, Inhaltsverzeichnis, …) wurden bisher nur angezeigt, wenn JavaScript aktiviert war. Das ist jetzt nicht mehr notwenidig, da die Icons inline eingefügt wurden.

Vorher:

Jetzt:

Hier berichte ich davon, wie genau ich das gemacht habe, was es zu bedenken galt und wie es im Ergebnis geworden ist. In erster Linie ist es für mich als Dokumentation gedacht, damit ich das in x Zeit noch nachvollziehen kann. Und wenn jemand anderes damit auch noch etwas anfangen kann, dann ist es noch besser.

Dabei schreibe ich übrigens das erste Mal einen Blogbeitrag mit einem einfachen Editor, offline, ohne Browser, in einem einfachen Textbearbeitungsprogramm. Und das fühlt sich gut an.

Wieso überhaupt weg von WordPress?

Ich habe WordPress seit 2009 für meinen Blog benutzt und es immer auf eigenen Servern selbst gehostet. Ich war immer sehr zufrieden damit. WordPress hat es mir ermöglicht, mich immer nur auf den Inhalt konzentrieren zu können und hat mir die ganze Arbeit drumherum abgenommen. Und es ist immer noch so. Das schätze ich an dem Content Management System WordPress. Jedes Upgrade auf eine neue Version war immer fehlerfrei mit nur wenigen Klicks möglich.

Die meisten Funktionen von WordPress habe ich nie benutzt. Und mit dem Update auf den Gutenberg-Editor und jetzt kürzlich auf 5.9 mit dem Super Feature “Full Site Editing” ist noch klarer geworden, dass ich solch ein komplexes System nicht benötige. Es ist immer noch sehr einfach zu bedienen und zu aktualisieren, aber ich brauche es eben nicht.

Was ich brauche, ist eine einfache Möglichkeit, Texte zu schreiben, die Maus möglichst nicht bewegen zu müssen und außerdem benötige ich nur die grundlegensten Formatierungen. Kurzum das, was Markdown bietet.

Natürlich sind da noch andere Aspekte:

• Wartbarkeit: Webserver, PHP, Datenbank, alles will gepflegt werden und benötigt ab und zu Aufmerksamkeit. Mit Hugo kann man den kompletten Blog, der aus statischen Dateien (HTML, CSS, JavaScript) besteht, auf einen Webserver werfen und für immer dort liegen lassen.
• Portierbarkeit/Backup: Sollte ich mal vom Rad fallen und nicht mehr aufstehen, kann man sich das Archiv herunterladen und hat weiterhin Zugriff auf die Inhalte des Blogs. Entsprechend wird man sich später das einmal alle x Zeit aktualisierte Archiv herunterladen können. Dazu später mehr.
• Sicherheit: Da nichts dynamisch ausgeführt wird, gibt es auch keine Sicherheitslücken, die jemand ausnutzen könnte.
• “Einfachheit”: Text-Editor, Hugo laufen lassen, hochladen per SFTP. Fertig.

Ein schönes Theme für Hugo finden

Man kann natürlich auch selbst ein Theme bauen, aber das ist nichts für mich.

Eine Liste von aktuell 285 Themes gibt es auf der Webseite von Hugo, siehe hier.

Ich habe mich für das Theme Bootstrap Theme for Personal Blog and Documentations entschieden, weil es fast alles liefert, was ich benötige und vielfältige Einstellungsmöglichkeiten hat.

Was ich besonders mag:

• Dark Mode/Light Mode
• Suchfunktion (fuse.js)
• Durch Ausblenden der Seitenliste kann der Inhaltsbereich breiter gemacht werden.
• Es gibt bereits Shortcodes für Nachrichtenboxen (Info, Alarm, …). Siehe hier.
• Twitter Cards und Open Graph
• Responsive
• optional mehrsprachig
• Archivseiten
• Shortcods für Verleinern von Bildern. Die verkleinerten Bilder werden beim Rendern von Hugo aus den Originaldateien erzeugt.
• Lazy loading für Bilder
• Inhaltsverzeichnis für Blogbeiträge
• Keine Einbindung von externen Inhalten
• Liste von “ähnlichen Beiträgen”

Vor dem Export in WordPress aufräumen

Tabellen aufräumen

Vor dem Export der Daten kann man den Blog noch etwas aufräumen. Hat man z. B. wie ich über die Jahre viele verschiedene Plugins ausprobiert und wieder entfernt, dann könnten die Daten der Plugins immer noch irgendwo in den Tabellen der Datenbank liegen und beim Export in den Daten landen. Das wären alles zusätzliche Daten, die man nicht benötigt.

Dazu hatte ich mal einen eigenen Blogbeitrag verfasst, siehe hier.

Entwürfe

Werden Entwürfe exportiert, dann erhalten diese in der exportierten Version kein Datum und sind somit erstmal aus dem Sichtbereich raus oder bekommen seltsame Namen/URLs zugewiesen wie z. B. “?p=52696/”, das der fortlaufenden ID von Blogbeiträgen entspricht. Das will man später alles nicht einzeln bearbeiten müssen. Deshalb Entwürfe löschen oder veröffentlichen.

Verlinkungen in WordPress

Man kann in WordPress entweder die komplette URL verwenden (Standard), um auf einen Beitrag im eigenen Blog zu verlinken oder die ID des Beitrags verwenden.

Die komplette URL wäre z. B. “natenom.de/2021/01/beitrag-ueber-den-kleinen-elefanten” während die ID “natenom.de/?p=12345” wäre.

Solche Verlinkungen sollte man noch im laufenden WordPress Blog finden und in die erste Form (lange URL) überführen, da die zweite Form mit der ID in Hugo nicht funktionieren wird.

Dazu reicht die Suchfunktion im Adminpanel aus. Man sucht nach “/?p=”. In meinem Fall fanden sich ca. 130 solcher Beiträge mit ID Verlinkungen.

(optional) Backup des Blogs – Für Hugo nicht relevant

Da der Blog am Ende abgeschaltet werden soll, habe ich ein letztes Mal Backups gemacht:

• Backup der WordPress Datenbank
• Als Admin in WordPress angemeldet und unter Werkzeuge -> Daten exportieren -> Alle Inhalte ausgewählt und die xml-Datei heruntergeladen. In dieser Datei sind alle Beiträge, alle Seiten und auch die Kommentare von Benutzern enthalten. Nicht jedoch die hochgeladenen Dateien. In meinem Fall ist die Datei um 50 MiB groß und hat um die 50000 Zeilen.
• Backup des kompletten WordPress-Verzeichnisses inklusive den hochgeladenen Dateien und dem ganzen PHP-Zeug
• Herunterladen der kompletten Webseite mit wget, um später noch nachvollziehen zu können, unter welchen URLs was zu finden war. Für solche URLs, die Hugo nicht generiert. Die könnte man dann mit einem Webserver passend weiterleiten. Die Kommandozeile dafür ist:

wget --recursive --domains=natenom.de --html-extension --page-requisites --convert-links --no-parent "/" -R "*xmlrpc*" --reject-regex ".*wp-content.*"

-erobots=off

Das Verzeichnis wp-content habe ich bewusst ausgelassen, da es nur hochgeladene Dateien enthält (ca. 7 GiB), die bereits in einem anderen Backup enthalten sind.

Daten für Hugo aus WordPress exportieren

Mit dem Tool WordPress to Hugo Exporter kann man alle Seiten und Beiträg eines Blogs in eine Zip-Datei exportieren.

Ich gehe hier nicht darauf ein, wie man das Tool verwendet, da das ausreichend gut auf dessen Webseite erklärt ist. Wichtig ist hier nur, dass man am Ende eine Datei erhält, hier im Beispiel mit dem Namen wpexport.zip.

Auf der Projektseite steht, was man an der PHP-Datei anpassen muss, damit auch Kommentare exportiert werden.

Der Export kann eine ganze Weile dauern und sollte deshalb auf der Kommandozeile ausgeführt werden. Die wpexport.zip meines Blogs hatte eine Dateigröße von etwas mehr als 7 GiB.

Die Datei wpexport.zip hat diese Struktur:

seite-a/index.md
seite-b/index.md
irgendeine-seite/index.md
posts/
    2022-01-05-mein-beitrag-im-januar
    2022-01-06-mein-beitrag-ueber-bluemeleinchen
    2022-02-08-ein-neuer-beitrag-mit-tollen-fahrraedern
wp-content/
    uploads/
        2022/
            01/
                2022-01-04-hochgeladenes-bild-1.jpg
                2022-01-04-hochgeladenes-bild-2.jpg
config.yaml

• Es sind alle “Seiten” des Blogs als Verzeichnisse enthalten, in den index.md-Dateien sind die Inhalte.
• Die “Beiträge” (Englisch “Posts”) liegen als md-Dateien im Verzeichnis “posts”.
• Die hochgeladenen Dateien wie Fotos, Screenshots oder auch Audio und Video liegen im Verzeichnis wp-content/uploads, sortiert nach Jahr und Monat.
• Dann gibt es noch die Datei config.yaml, welche die URL des Blogs enthält, den Namen und die Beschreibung.

Die Daten lädt man dann auf den eigenen PC herunter.

Eine Webseite mit Hugo anlegen und Theme einfügen

Ich will hier nicht darauf eingehen, wie man eine Webseite mit Hugo anlegt und das Theme einfügt, das ist auf der Projektseite bereits ausführlich gut dokumentiert, siehe hier.

Sobald das erledigt und das Theme eingebunden ist, kann man die exportierten Daten aus dem heruntergeladenen Archiv entpacken und die Daten in das Verzeichnis des neuen Blogs hineinkopieren:

• Die Datei config.yaml habe ich weg gelassen.
• Das Verzeichnis posts wird nach content kopiert.
• Das Verzeichnisse seite-x werden nach content/pages kopiert.
• Das Verzeichnis wp-content wird nach static kopiert.

Ein bisschen Konfiguration

Eine Liste aller Einstellungsmöglichkeiten gibt es auf der Seite des Theme-Entwicklers.

Taxonomie

Bei der Taxonomie wollte ich die URLs von WordPress möglichst erhalten.

Per Voreinstellung verwendet Hugo für tags in der URL “tags”, WordPress jedoch “tag”. Bei Kategorien verwendet Hugo “categories” und WordPress “category”.

Das kann man in der config.toml anpassen mit:

[taxonomies]
  category = 'category'
  tag = 'tag'

In meinem ausgewählten Theme funktioniert das jedoch leider nicht, da zwingend “tags” und “categories” notwendig sind. Kann man sicher anpassen, ich aber nicht. Also bleibt es bei den Voreinstellungen. Ich werde es dann einfach mit dem Webserver weiterleiten lassen.

In Nginx z. B. mit:

rewrite ^/tag/(.*)$ /tags/$1 redirect;
rewrite ^/category/(.*)$ /categories/$1 redirect;

Wenn das gut funktioniert, kann man das später auf permanent umschreiben.

Beiträge nicht gelistet

Auf der Startseite des Blogs wurden die Beiträge nicht gelistet. Mit Herumprobieren konnte ich herausfinden, dass das an dem Eintrag “type: post” im Front Matter (Metadaten eines Beitrags) lag. Daher habe ich mit dem folgenden Shell-Aufruf diese Zeile in allen md-Dateien gelöscht:

sed -i "/^type: post$/d" *.md

Sonstige Konfiguration

Hier noch ein paar weitere wichtige Dinge, die ich in der Konfiguration eingestellt habe.

[…]
baseURL = "/"
rssLimit = 15
[…]
[params]
comment = false
breadcrumb = true
palette = "blue"
dateFormat = "Mon, 02 Jan 2006 15:04"
mainSections = ["posts", "pages" ]
poweredBy = false
math = false
diagram = false
logo = false
description = " Verkehrswende, Fahrrad, CriticalMass, OpenBikeSensor, SimRa, Mumble, Open Source, Minimalist, OpenStreetMap, Müllsammeln"
recentPostCount = 5
relatedPostCount = 6
categoryCount = 200
tagCount = 150
searchBar = true
post.copyright = false
search.fuse.threshold = 0.0
countTaxonomyPosts = true
post.excerpt = "description"
viewer = false
showShare = false
socialShare = false

[outputs]
  home = ["HTML", "RSS", "JSON"]

Von absoluten URLs zu relativen URLs

Ich habe keine Ahnung von SEO und habe mich nie damit beschäftigt. Könnte es sein, dass WordPress aus SEO-Gründen absoulte URLs verwendet und nicht realtive? Ich habe dazu die Info auf einer Webseite gefunden, dass relative Links problematisch werden könnten, wenn der Server nicht richtig eingerichtet sei.

Hat man Bedenken, dann weiter zum nächsten Abschnitt.

Aber: Will man den neuen Blog auf dem eigenen PC anschauen, benötigt man ohne die Veränderungen der URLs eine Internetverbindung, damit eingebettete Inhalte wie z. B. Bilder vom Browser von der ursprünglichen Webseite heruntergeladen werden können. Oder aber man biegt das DNS temporär um, muss dann aber zumindest aus https http machen, und so weiter.

Absolute URLs auf hochgeladene Dateien

Alle Verlinkungen auf Fotos, Bilder und Videos sind in WordPress mit der absoulten URL angegeben, in meinem Fall mit natenom.de/wp-content/uploads/.... Und das wird so auch in die md-Dateien exportiert.

Deshalb kann man die URLs mit dem Streameditor sed umschreiben lassen:

sed -i -E -e 's#/wp-content/uploads/#/wp-content/uploads/#g' *.md

(Ich habe das aktuell erstmal noch nicht getan.)

Das Kommando führt man in allen Verzeichnissen aus, in denen md-Dateien liegen. Man könnte das auch so umschreiben, dass es ausgehend vom neuen Blogverzeichnis alle md-Dateien findet und so alle erfasst. Aber so reicht es mir.

Absolute URLs auf Blogbeiträge

Das selbe gilt auch für Verlinkungen im Blogbeiträgen auf andere Beiträg im eigenen Blog. Auch diese URLs lasse ich umschreiben:

sed -i -E -e 's#/#/#g' *.md

(Ich habe das aktuell erstmal noch nicht getan.)

Aus dem absoulten Link / wird dadurch /.

Umlaute in URLs von Kategorien und Tags

Ich verwende im Blog das Tag “Müllsammeln” und die Kategorie “Mobilität”. Wordpress hat dabei automatisch die Umlaute in den dafür genutzten URLs in die alternativen Schreibweisen “muellsammeln” und “mobilitaet” umgewandelt. Hugo macht das nicht, weshalb dort das Tag auch “müllsammeln” lautet.

Es gibt mehrere Lösungen:

1. Es dabei belassen, denn mittlerweile sind diese Zeichen kein Problem mehr. Es sieht nur nicht sonderlich schön aus, wenn man statt mobilität das hier sieht mobilit%C3%A4t
2. Ohne Veränderungen an den Beiträgen wäre die Option removePathAccents von Hugo möglich, die aus “mobilität” “mobilitat” macht.
3. Hugo selbst zu verändern, siehe hier.
4. Alle Vorkommen der Tags in den Beiträgen mit sed umschreiben und ö durch oe ersetzen usw.
5. Weiterleitungen durch den Webserver, siehe unten.

Einen Issue mit vielen Informationen zu diesem Theme gibt es auf Github, siehe hier. Ein weitere Issue zu dem Thema ist seit November 2021 noch offen, siehe hier.

Ich habe mich entschieden, das so zu belassen das erst einmal mit Weiterleitungen zu “fixen” und zu schauen, was sich bei dem Issue tut.

In Nginx sind diese:

rewrite ^/tag/muellsammeln/(.*)$ /tags/müllsammeln/$1 redirect;
rewrite ^/category/mobilitaet/(.*)$ /categories/mobilität/$1 redirect;
rewrite ^/tag/(.*)$ /tags/$1 redirect;
rewrite ^/category/(.*)$ /categories/$1 redirect;

Ich nutze bei solchen Dingen am Anfang immer erst redirect, was dem HTTP Status 302 entspricht und ändere das dann irgendwann zu permanent (Status 301) um.

Fehlerseite für 404

Falls doch mal eine Seite nicht gefunden wird, habe ich die 404.html in Nginx eingerichtet:

error_page 404 /404.html;

Hier kann man die Seite mal ansehen: Dieser Link zeigt auf eine nicht vorhandene Seite.

Damit erstmal keine Inhalte fehlen

Würde man jetzt schon Hugo starten, würden vermutlich viele Inhalte in verschiedenen Beiträgen fehlen. Das liegt daran, dass das oben genannte Export-Tool viele HTML Tags nicht in Markdown konvertieren kann und dann an diesen Stellen den HTML-Quelltext in die exportierten md-Dateien schreibt. Doch Hugo filtert diesen HTML-Quelltext beim Rendern der Website heraus.

Damit ich nicht erst alle 2560 Blogbeiträge manuell überprüfen und korrigieren muss, bevor ich den neuen Blog öffentlich machen kann, habe ich mich entschieden, dieses Verhalten von Hugo umzustellen und Hugo anzuweisen, den HTML-Quelltext nicht herauszufiltern. Das ist zwar nicht im Sinne des Erfinders aber so habe ich die Möglichkeit, die Arbeit auf irgendwann später zu verschieben.

Details dazu findet man hier. Suche nach unsafe.

In die config.toml fügt man dazu Folgendes ein:

[markup]
  [markup.goldmark]
    [markup.goldmark.renderer]
      unsafe = true

Run Hugo, Run

Jetzt kann man Hugo veranlassen, den neuen Blog das erste Mal zu rendern und dann lokal zur Verfügung zu stellen. Per Voreinstellung ist er unter localhost:1313 erreichbar.

Dazu wechselt man auf der Kommandozeile in das Verzeichnis des neuen Blogs und führt aus:

hugo server --renderToDisk -D -E -F -v

Jetzt werden alle gerenderten Dateien und auch die aus dem static-Verzeichnis in das Verzeichnis public kopiert, welches Hugo automatisch erstellt, wenn es noch nicht existiert.

Sobald alles bereit ist, gibt es eine Meldung wie etwa:

                   |  DE   
-------------------+-------
  Pages            | 4350  
  Paginator pages  | 1694  
  Non-page files   |    1  
  Static files     |   88  
  Processed images |    0  
  Aliases          |  889  
  Sitemaps         |    1  
  Cleaned          |    0  

Built in 45228 ms
Watching for changes in /home/natenom-web-hugo/{assets,content,layouts,static,themes}
Watching for config changes in /home/natenom-web-hugo/config.toml, […]
Environment: "development"
Serving pages from /home/natenom-web-hugo/public
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

Erstmal fertig

Das reicht dann auch wieder für diesen Beitrag. Man kann jetzt schon im eigenen Blog offline umgucken und wird hier und da noch unschöne Dinge finden, wie falsch dargestellte Bilder.

In Teil 2 geht es darum, für die Übergangszeit das übrig gebliebene HTML, das nicht zu Markdown konvertiert werden konnte, automatisiert so zu verändern, dass der Blog trotzdem ansehnlich ist, wenn auch noch nicht perfekt.

It is written in Perl.

New in this release:

• Handle bogus whitespace in EXIF timestamps.
• Ignore hidden/invalid files instead of failing.
• Support „tificc2“ as an alias to „tificc“ (for Fedora).
• Avoid calling „tificc“ for images already in sRGB.
• Load thumbnails on-demand for faster loading of large galleries.
• Extract and visualize image captions (see here how it works).
• Added „utils/fcaption“ to edit image captions.

I am looking forward for the ability to display some meta information like aperture, exposure, ISO and more (see this issue) and would then like to use this for my photographs.

A demo gallery with the latest features can be found at www.thregr.org/.

Website of the project: www.thregr.org/~wavexx/software/fgallery/.

• Die Navigation scrollt nun nicht mehr nach rechts mit, wenn einzelne Überschriften breiter sind als die Spalte.

  • Trotzdem werden nun auch zu lange Seitennamen in der Navigation komplett angezeigt, wenn man mit der Maus darüber geht.
    Vielen Dank an Deltachaos, der sich dafür die Zeit genommen und das technisch umgesetzt hat. Das JavaScript und das CSS für die Umsetzung gibt es im Wiki.
    So sieht das dann aus (ohne die Änderung wäre nach „…. zwischen Mumble-S“ alles abgeschnitten):

    

  • Man sieht keine Text-Vorschau der einzelnen Seiten mehr, was eher gestört hat als dass es hilfreich war.

  • Durch eine Änderung an der Konfiguration lädt die Navigation nun etwas schneller.

  • Die Seitennamen und Namensräume sind nun alphabetisch sortiert, was die Übersichtlichkeit sehr verbessert:

    

  Hier gehts zum Wiki: http://wiki.natenom.de.

Wie man ausserdem auf der Projektseite von EtherPad Lite lesen kann, braucht das alte EtherPad auch ordentlich Ressourcen (257 MB direkt nach dem Start, bis zu ~1 GB).

Das neue Etherpad Lite braucht nur Node.js und ist ziemlich einfach zu installieren. Lite deshalb, weil es viel weniger Ressourcen frisst (16 MB nach dem Start, bis zu ~30 MB).

So, nun haben wir auch so ein Ding, jedoch nicht öffentlich mit Passwort-Schutz :)

Schon aus Prinzip ist das Pad nur per https und ohne Erhebung von IP-Adressen erreichbar und  liegt auf einem mit LUKS verschlüsselten Datenträger; wenn später der Server an einen neuen Kunden geht oder heruntergefahren wird, kommt man auch nicht an die Daten ran :)

LVM ist schon toll.

Gefunden bei: http://www.gulli.com/news/16978-etherpad-lite-2-jahre-herumprobieren-und-entschlackung-2011-08-29