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.

Verlinkt man oft auf die selben Webseiten, kann man natürlich, wie sonst auch, die komplette URL immer wieder eintragen. Wenn sich aber irgendwann die Domain des Ziels ändern sollte, dann müsste man alle verwendeten Links wieder anpassen. ¹

Man kann aber auch sogenannte Interwiki-Links nutzen, deren “Verwaltung” an einer zentralen Stelle liegt und kann so alle möglichen Anpassungen für verlinkte URLs vornehmen.

Interwiki Links

Bei einem Interwiki Link ist die Zieldomain nur ein einziges Mal irgendwo zentral hinterlegt und man gibt bei einer Verlinkung nur noch eine selbst definierte Abkürzung an und optional den Pfad zur Unterseite.

Für mein Wiki ist die Domain aktuell https://wiki.natenom.de/ und die verlinkte Unterseite könnte z. B. verkehr/projekte/radfahrer_faq sein. Die definierte Abkürzung ist n-wiki.

Um einen solchen Link in meinem Blog einzufügen, würde ich schreiben:

{{​< interwiki dest="n-wiki" title="Ein Link zu meinem Wiki" link="verkehr/projekte/radfahrer_faq" >​}}

Das Ergebnis: Ein Link zu meinem Wiki

Das sieht jetzt erst einmal nicht so aus, als hätte man durch mehr Schreibarbeit einen Vorteil. Hier ist die Liste z. B. die Liste der Interwiki-Links aus meinem Wiki, die ich verwende.

Hier eine Liste der verfügbaren Interwiki-Links auf meinen Websites.

In meinem Blog hatte ich es wegen WordPress nie geschafft, so etwas umzusetzen. Hier in Hugo ist das sehr einfach zu realisieren.

Anpassungen für Interwiki-Links

Es ist mit Interwiki-Links auch möglich, z. B. ein kleines Icon der Website anzuzeigen, wie ich es von DokuWiki kenne, siehe hier.

Oder man kann weitere Attribute nur für eine bestimmte Verlinkung angeben, z. B. rel.

Shortcode für Interwiki in Hugo

Ich habe für meine Interwiki-Links einen Shortcode geschrieben:

{{ $dest := .Get "dest" }}
{{ $link := .Get "link" }}
{{ $title := .Get "title" }}

{{ if eq $dest "n-wiki"}}
{{ .Scratch.Set "baseurl" "https://wiki.natenom.de/" }}
{{ else if eq $dest "n-com"}}
{{ .Scratch.Set "baseurl" "https://www.natenom.com/" }}
{{ else if eq $dest "n-de"}}
{{ .Scratch.Set "baseurl" "https://www.natenom.de/" }}
{{ else if eq $dest "n-files"}}
{{ .Scratch.Set "baseurl" "https://f.natenom.de/" }}
{{ else }}
{{ errorf "Invalid dest set. See shortcode for help."}}
{{ end }}

<a class="shortcode-interwiki natenom" href="{{- .Scratch.Get "baseurl" -}}{{- $link -}}">{{ if $title }}{{ $title }}{{ else }}{{ .Scratch.Get "baseurl" }}{{ $link }}{{ end }}</a>

Noch mehr Möglichkeiten

Wenn es eine Domain gar nicht mehr geben sollte, auf die ich oft verlinkt hätte, könnte ich das im Shortcode so ändern, dass nur der Link nicht mehr gesetzt wird und der Linktext zusätzlich durchgestrichen wird und eine kleine Info angezeigt wird, dass es das Ziel nicht mehr gibt.

Oder ich könnte einstellen, dass externen Links auf fremde Seiten, je nach Ziel, eine Warnung vorgeschaltet wird.

So viele Möglichkeiten :)

Verbesserungspotenzial

Schön wäre es, wenn ich Interwiki-Links in Hugo so umsetzen könnte, dass ich das normale Markdown weiterhin verwenden kann. Für einen Link zu meinem Wiki als Interwiki-Link könnte ich dann z. B. statt

[Link zum Wiki](https://wiki.natenom.de/docs/fahrrad/faq)

bzw. meiner Variante mit einem Shortcode

{{​< interwiki dest="n-wiki" title="Ein Link zu meinem Wiki" link="verkehr/projekte/radfahrer_faq" >​}}

so eine Syntax verwenden:

[n-wiki:Link zum Wiki](verkehr/projekte/radfahrer_faq)

Damit werde ich mich später mal beschäftigen.

Der einzige Punkt, der mich noch (minimal) stört, ist die Tatsache, dass die meisten der alten Beiträge noch den Ursprungs-HTML-Code von WordPress enthalten und nicht oder nur unvollständig nach Markdown exportiert werden konnten.

Aber zumindest kann man die alten Beiträge noch ansehen, wenn sie auch nicht immer sehr gut aussehen weil z. B. Fotos nicht mehr in Galerien dargestellt werden, sondern nur noch als Listen.

Das wird jedoch weiterhin so bleiben. Denn ich habe keine Zeit, die 2560 Beiträge, die ich seit 2009 geschrieben habe, einzeln durchzusehen, den HTML-Quelltext manuell nach Markdown umzuschreiben und Fotos vom alten /wp-content/-Verzeichnis in ein zu erstellendes Page Bundle zu verschieben.

Vereinzelt, wenn ich mal Lust habe, werde ich den einen oder anderen Beitrag umschreiben und habe das auch schon getan. Der Rest bleibt.

Alle Beiträge ab dem 01.10.2021 sind komplett in Markdown geschrieben. Das ist sozusagen das “Neue Zeitalter” des Blogs :)

Für mich passt das so.

Was mir in Kate besonders fehlt:

• Live-Vorschau beziehungsweise Ausblendung der für Fließtext nicht relevanten Teile.
• Übersicht des Textes durch ein Inhaltsverzeichnis

Deshalb habe ich in den vergangenen Wochen immer wieder verschiedene andere Programme ausprobiert, mit denen man Blogbeiträge in Markdown schreiben kann.

Erst heute habe ich alles aufgeschrieben, was mir gefällt und nicht gefällt, daher dieser Blogbeitrag.

So richtig gefallen hat mir bisher nichts. Die Programme, die schön aussehen und z. B. eine Live-Vorschau bieten, sind keine nativen Anwendungen basieren auf Electron. Solche Software will ich gar nicht laufen lassen, aus verschiedenen Gründen, die ich hier nicht erläutern werde.

Trotzdem habe ich z. B. den Editor “Mark Text” getestet, weil ich erst später auf der Projektseite gesehen habe, dass auch dieses auf Electron basiert.

Es folgt eine Liste der Editoren, die ich ausprobiert habe. Ich habe nicht alles in jeder Software getestet sondern nur das, was mir wichtig ist. Und wenn etwas davon nicht erfüllt war, habe ich den Test beendet. Ich habe nur Editoren getestet, die für Linux verfügbar sind.

Mein Fazit

Programme mit einer Live-Vorschau sind sehr angenehm fürs Schreiben, weil sie alles ausblenden, was nicht Fließtext ist. Hier ein Vergleich zwischen Kate, was immer den Quelltext anzeigt und “Mark Text”, das die Live-Vorschau anzeigt und nur den Quelltext des Elements, an dem sich der Cursor aktuell befindet. Der Cursor befindet sich in beiden Dokumenten an der selben Stelle.

Dafür hat aber jedes der getesteten Programme Bugs/Features/Eigenheiten, mit denen ich so nicht dauerhaft arbeiten will (siehe unten).

Außerdem will ich mich weiterhin nicht mit dem Aussehen von etwas beschäftigen, sondern mit Inhalten. Und in jedem Editor sieht die Vorschau je nach verwendetem Stil/CSS ganz anders aus.

Ich wollte mal prüfen, was es außer Kate sonst noch so gibt und habe festgestellt, dass nichts davon für mich nutzbar ist. Daher bleibe ich bei Kate und werde mir das weiterhin schön einrichten.

Und ich habe letztlich beim Testen der Editoren und beim Schreiben dieses Blogbeitrags auch einen für mich gut funktionierenden Workflow gefunden. Dazu werde ich einen weiteren Blogbeitrag schreiben und ihn hier verlinken: Hier ist der Blogbeitrag zu meiner Arbeitsweise mit Hugo.

Getestete Programme

Ich lasse diese Liste der getesteten Programme liegen, damit ich hier nachschauen kann, was ich bereits getestet hatte und weshalb ich es nicht benutzen will. Falls mir mal jemand etwas empfiehlt.

Apostrophe

Link zur Website.

• Pro
  • Kein Browser.
• Contra
  • Scrollt nicht synchron.
  • Auch hier sind Formatierungen in der Vorschau nur sehr zurückhaltend gestaltet und daher kann ich verschiedene Elemente nicht gut unterscheiden.
  • Keine Textsnippets.

Formiko

Das Vorschaufenster enthielt nur Python-Fehlermeldungen. Habe das Paket aus den Debian-Quellen installiert.

Ghostwriter

Link zur Website.

• Pro
  • Kein Browser.
• Contra
  • Dokument und Vorschau leider nicht synchron scrollbar. Bei großen Dokumenten ist das sehr unübersichtlich.
  • Aussehen der Vorschau gefällt mir nicht. Elemente wie <code>xxx</code> erkennt man kaum als solche. Formatierungen sind sehr rudimentär.
  • Keine Textsnippets.

Kate

Link zur Website.

• Pro
  • Kein Browser.
  • Extrem viele Möglichkeiten, unabhängig von Markdown, z. B. kann man markierte Bereiche mittels Shellkommandos bearbeiten (sort, uniq, …), Tools -> Filter Through Command.
  • Schönes Syntaxhighlighting.
  • Autovervollständigung für bereits verwendete Strings.
  • Klein und schnell.
  • Konsole lässt sich im Programm öffnen (F4).
  • Standardeditor von KDE/Plasma, dadurch gut in den Desktop integriert.
  • Textsnippets gibt es, sie werden aber nur zuverlässig eingefügt, wenn man am Ende einer Zeile ist. Wenn nicht, dann fehlt ein Teil des Snippets.
• Contra
  • Keine Liste von möglichen Formatierungen sichtbar. Sollte aber nach einiger Zeit nicht mehr relevant sein, da man das irgendwann gelernt hat.
  • Es gibt ein Plugin für eine Vorschau. Dieses erzeugt aber nur sehr rudimentäre Ausgaben und das auf auf Seitenbasis. Für mich unbenutzbar.

Mark Text

Link zur Website.

Wie man sieht, habe ich diesen Editor nach Kate am längsten benutzt.

• Pro
  • Live-Vorschau des Dokuments. Nur dort, wo gerade der Cursor ist, wird der Quelltext angezeigt.
  • Benutzerinterface und Vorschau gefallen mir sehr gut.
  • Kleines Overlay zur Anwendung von Formatierungen an.
  • Es gibt eine Ansicht für den Quelltext und eine Live-Vorschau. In der Live-Vorschau lässt sich zusätzlich noch ein “Focus Mode” aktivieren. Dadurch tritt alles farblich in den Hintergrund und nur der aktuelle Absatz ist normal zu sehen.
  • Keine störenden Elemente, keine Menüleiste. Nur oben wird als Breadcrumbs der Pfad zur aktuellen Datei angezeigt und links oben gibt es ein Hamburger-Menü. Optional kann man aber eine Sidebar und eine Tab Bar aktivieren.
  • In der Sidebar gibt es eine Liste der aktuell geöffneten Dokumente, eine Suchfunktion innerhalb eines geöffneten Verzeichnisses und ein Inhaltsverzeichnis des aktuellen Dokuments.
  • Am Anfang einer neuen Zeile kann man mit dem @-Zeichen ein Menü öffnen, in dem man aus einer Liste von Formatierung etwas auswählen kann.
  • Sprachen für die Rechtschreibkorrektur sind innerhalb der Anwendung herunterladbar.
  • Mit der Tastenkombination Strg + Shift + P öffnet man die Befehlspalette.
• Contra
  • Basiert auf Electron.
  • Tastaturnavigation mit Strg + Shift + Pfeiltaste hoch funktioniert nicht mehr, sobald das kleine Overlay mit Formatierungsoptionen (automatisch) geöffnet wurde.
  • Scrollen mit Bild hoch funktioniert manchmal nicht und die Ansicht springt immer wieder nach unten zurück.
  • Keine Textsnippets.
  • Shift + Tab innerhalb eines Listenpunktes rückt den Listenpunkt nach rechts statt nach links, wie es in allen anderen Editoren funktioniert. Listen mit Unterpunkten kann man dadurch nicht wirklich bearbeiten.
  • Sobald man Klammern oder Anführungszeichen eingegeben hat, wird ein zweites dahinter gesetzt. Wenn man Texte erst schreibt, ist das super, wie auch bei anderen Programmen. Will man jedoch ein Anführungszeichen vor einen bestehenden String setzen, so werden trotzdem immer zwei Zeichen gesetzt. Löscht man das erste, werden beide gelöscht. Es ist dann nur möglich, das zweite zu löschen, damit das erste übrig bleibt.
  • Beim Löschen von mehreren markierten Zeilen mit Shift + Pfeiltaste hoch wurde schon mehrfach alles bis zum Ende des Dokuments gelöscht statt nur der markierte Bereich.
  • Manchmal dauert länger also normalerweise, bis sich bei einem markierten Wort das Rechtsklick-Menü öffnet, sofern dieses von der Rechtschreibkorrektur als falsch eingestuft und markiert wurde.
  • In vielen Bereich werden unnötige Leerzeilen generiert, z. B. auch in Listen.
  • Ich hatte zeitweise den Eindruck, dass die Anwendung etwas träge reagierte.
  • Keine Textsnippets.

Marker

Link zur Website.

• Pro
  • Viele verschiedene CSS für die Vorschau, z. B. die von Github.
  • Kein Browser.
• Contra
  • Ähnlich rudimentär wie ReText.
  • Vorschau scrollt nicht synchron mit.
  • Editor kann nicht einmal “Suchen und Ersetzen”.
  • Keine Textsnippets.

ReText

Link zur Website.

• Pro
  • Kein Browser
• Contra
  • Drag and Drop zum Öffnen von Dokumenten funktioniert in KDE nicht.
  • Syntaxhighlighting so gut wie nicht vorhanden. Daher sind Texte schwieriger zu lesen.
  • Keine Textsnippets.

Typora

Link zur Website.

• Pro
  • Tastaturnavigation und scrollen funktionieren sehr gut.
• Contra
  • Basiert auf Electron.
  • In der Beta kostenlos, danach wird es kostenpflichtig werden.
  • Live Rendering wie auch bei Mark Text, aber nicht so schön, wie ich finde.
  • Auch in der “Distraction Free”-Ansicht sieht man noch eine Menüleiste
  • Keine Textsnippets.

VSCode, VSCodium, Obsidian, Atom, …

Editoren wie VSCode, VSCodium, Obsidian und Atom habe ich gar nicht erst ausprobiert, da sie alle auf Electron basieren.

Vorteil dieser Editoren ist jedoch, dass es extrem viele Erweiterungen gibt.

Update: Eine erste Galerie, wo ich das mal mit den .meta-Dateien umgesetzt habe, gibt es hier.

Bisher werden hier im Blog bei Verwendung des Galerie-Shortcodes hugo-shortcode-gallery nur die Bilder angezeigt. Ich hätte aber gerne für manche Bilder eine Beschreibung. So, wie ich es noch von WordPress kenne.

Zwei Methoden verfügbar

Für die verwendete Galerie gibt es zwei Methoden:

1. Verwendung sogenannter Sidecar-Dateien.
2. Hinzufügen der Variable ImageDescription zu den Exif-Metadaten eines Fotos.

Im Prinzip kann man für beide Möglichkeiten einfache Script schreiben, um die Metadaten zu Bildern hinzuzufügen.

Methode Sidecar

Das sind json-Dateien, die es für jedes einzelne Bild gibt.

Heißt das Foto etwa 2021-01-07-mammutbaum-pforzheim.jpg, dann kommen die folgenden Daten in die Datei 2021-01-07-mammutbaum-pforzheim.jpg.meta:

{
"Title": "Ein Mammutbaum in Pforzheim"
}

In der Dokumentatino von hugo-shortcode-gallery sind noch weitere Metadaten in der Datei .meta enthalten, nach meinem Test wird aber nur “Title” im HTML-Code der Galerien hinterlegt.

Methode Exif Metadaten

Exif-Metadaten werden mit meinen Einstellungen in den Bildern der Galerie angezeigt, wenn sie in der Lightbox geöffnet werden. Dazu habe ich in der Konfiguration von Hugo die Option galleryShowExif = true gesetzt.

Unter Linux kann man z. B. mit dem Tool exiftool Exif-Daten in Dateien schreiben:

exiftool -imagedescription="Ein Mammutbaum in Pforzheim" 2021-01-07-mammutbaum-pforzheim.jpg
    1 image files updated

Ergebnis in beiden Fällen

Der Titel wird dann sowohl beim Hover über das Thumbnail angezeigt als auch in der Lightbox oben am Rand. Im HTML-Code fehlt leider das Alt Attribut, dazu werde ich beim Entwickler einen Bugreport erstellen, damit er das noch einfügen kann.

Titel beim Hovern mit der Maus über ein Bild:

Titel in der Lightbox:

Noch nicht entschieden

Ich habe mich noch nicht entschieden, welche Methode ich nutzen werde. In jedem Fall werde ich das Script später hier im Blog veröffentlichen, mit der ich in Zukunft die Bildbeschreibungen hinterlegen werde.

Die Methode mit den Exif-Metadaten hätte den Vorteil, dass die Daten auch in anderen Programmen angezeigt werden können. Zudem könnte ich anfangen, in meiner Fotoverwaltungssoftware immer diese Daten bereits einzutragen.

• Dazu gekommen sind die Weiterleitungen für Umlaute in URLs, wie ich hier beschrieben habe.
• Die am ersten Tag des Umzugs etwas unglück eingerichteten Weiterleitungen der in WordPress verfügbaren Feeds auf die von Hugo habe ich jetzt in schön geschrieben. (Eine gute Beschreibung der Feeds und deren URLs, die in WordPress automatisch erstellt werden, gibt es hier.)

Somit ist die ganze Konfiguration für den Blog in Nginx relativ einfach geworden.

Es könnte z. B. sein, dass es nicht sinnvoll ist, die URLs der Feeds der anderen Formate stumpf nach rss (index.xml) weiterzuleiten. Etwas anderes erzeugt Hugo per Voreinstellung aber nicht und ich will das auch nicht ändern.

Falls ich etwas Dummes getan habe, würde ich mich über einen Hinweis freuen. Danke.

server.conf

Die Anmerkungen von mir sind inline, da das besser zum Lesen ist:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

server {
    […]

    # Das ganze drumherum an Konfiguration des Blogs in Nginx (TLS,
    # Header, Rootverzeichnis, Logs, …) ist in andere Dateien
    # ausgegliedert. Hier ist nur der relevante Teil für alle
    # Verzeichnisse und Weiterleitungen.



    # Weiterleiten der alten Sitemap URLs auf die neue.
    # Es steht zwar auch schon in der robots.txt, man
    # kann es aber trotzdem machen.
    rewrite ^/sitemap.xml.gz[/]?$ /sitemap.xml permanent;
    rewrite ^/wp-sitemap-posts-post-2.xml$ /sitemap.xml permanent;
    rewrite ^/wp-sitemap-posts-post-1.xml$ /sitemap.xml permanent;



    # Bei neu eingerichteten Weiterleitungen der alten Feeds
    # zu den Feeds von Hugo verwende ich den HTTP Status
    # Code 302 "Found", sobald es sich als gut herausgestellt
    # hat, werde ich es auf 301 "Moved permanently" ändern.
    rewrite ^/feed/(rss|rss2|rdf|atom)[/]?$ /index.xml redirect;
    rewrite ^/category/(.*)/feed/(rss|rss2|rdf|atom)[/]?$ /categories/$1/index.xml redirect;
    rewrite ^/tag/(.*)/feed/(rss|rss2|rdf|atom)[/]?$ /tags/$1/index.xml redirect;

    rewrite ^/(feed|rss|rss2|rdf|atom)[/]?$ /index.xml redirect;
    rewrite ^/category/(.*)/(feed|rss|rss2|rdf|atom)[/]?$ /categories/$1/index.xml redirect;
    rewrite ^/tag/(.*)/(feed|rss|rss2|rdf|atom)[/]?$ /tags/$1/index.xml redirect;



    # Die Taxonomie ist in meinem Theme leicht anders als
    # in WordPress:
    rewrite ^/tag/(.*)$ /tags/$1 redirect;
    rewrite ^/category/(.*)$ /categories/$1 redirect;



    # Umleitungen zu Umlaut-URLs (siehe unten
    # im Blogbeitrag)
    rewrite ^/categories/mobilitaet(.*)$ /categories/mobilität$1 redirect;
    rewrite ^/tags/mobilitaet(.*)$ /tags/mobilität$1 redirect;
    rewrite ^/tags/muell(.*)$ /tags/müll$1 redirect;
    rewrite ^/tags/muellsammeln(.*)$ /tags/müllsammeln$1 redirect;
    […]



    # Habe das Verzeichnis der WordPress-Installation 1 zu 1
    # übernommen. Dort landen per Voreinstellung alle hochgeladenen
    # Dateien. Das Verzeichnis bleibt, da noch viele Beiträge
    # hier in Hugo das originale HTML von WordPress enthalten
    # und eingebettete Bilder von dort geladen werden und/oder
    # dorthin verweisen.
    location /wp-content/ {
        alias /pfad-zu/alten-wordpress-dateien/;
        include pfad-zu/static_files.conf;
    }



    # Alle Dateien bekommen eine maximal mögliche Lebenszeit.
    # Siehe nächster Abschnitt, wo die inkludierte Datei zu sehen ist.
    location / {
        include pfad-zu/static_files.conf;
    }
}

Tipp: Hier ein Blogbeitrag zu Weiterleitungen zu Umlaut-URLs, die Hugo aus Tags mit Umlauten generiert.

static-files.conf

Auch hier sind Anmerkungen wegen der Lesbarkeit inline:

 1    if ($request_uri ~* ".(jpg|jpeg|gif|zip|gz|avi|png|mpeg|mpg|txt|mp4|woff|woff2|ttf|eot)$") {
 2            expires 90d;
 3    }
 4
 5
 6
 7    # Das sind die von Hugo erstellen kleinen Varianten
 8    # von Bildern für Thumbnails.
 9    if ($request_uri ~* ".*hu[a-z0-9]{32}.*resize.*$") {
10        expires 300d;
11        break;
12    }
13
14
15
16    # Das Verzeichnis, in dem JavaScript Assets landen.
17    # Sobald sich die Ursprungsdatei ändert, ändert sich
18    # auch der Hashwert im Namen, sodass man eine sehr
19    # lange Lebenszeit angeben kann.
20    if ($request_uri ~* "^/js/.*$") {
21        expires 300d;
22        break;
23    }
24
25
26
27    # Hier gilt das selbe wie auch für die JavaScript
28    # Assets oben drüber.
29    if ($request_uri ~* "^/css/.*$") {
30        expires 300d;
31        break;
32    }
33
34
35
36    # Eingebundenes CSS und JS für Dinge, die
37    # ich relativ oft verändern möchte. Auch Favicons
38    # möchte ich relativ schnell ändern können.
39    if ($request_uri ~* ".(css|ico|js)$") {
40        expires 48h;
41    }

Das wars. Für mich funktioniert das so gut. Anmerkungen bitte per E-Mail.

Danke :)

Ich habe mich etwas mit der URL-Struktur hier im Blog beschäftigt. Da ich anfänglich fast nur auf Basis der aus WordPress exportierten Blogbeiträgt gearbeitete hatte, gewöhnte ich mir an, im Front Matter immer die Option url: anzugeben. Diese enthält immer den vollen Pfad der URL ab der baseURL. Letztere besteht in meinem Blog aus dem Protokoll (https) und dem Domainnamen.

Für diesen Blogbeitrag hätte ich somit im Front Matter eingetragen:

url: /2022/02/url-struktur-hugo-url-slug-title

Nicht gut

Das ist nicht optimal, denn man verliert die Flexibilität. So kann man nicht einfach mal irgendwann die URL-Struktur anpassen, weil in jedem Blogbeitrag schon die am höchsten priorisierte Option url: angegeben ist.

Außerdem braucht man es auch gar nicht, da es in der Konfiguration von Hugo einen Abschnitt gibt, der festlegt, wie die URL (nach der BaseURL) generiert werden soll.

Gut

Ich habe die Konfiguration von Hugo umgestellt und werde in Zukunft nur noch slug: angeben. Der Slug ist der Teil der URL, der nur das Dokument des Blogbeitrags repräsentiert. Im oberen Beispiel wäre das "url-struktur-hugo-url-slug-title".

Damit die URL-Struktur im Blog weiterhin so bleibt wie bisher ("/jahr/monat/titel-des-beitrags/"), habe ich in die config.toml eingetragen:

[permalinks]
  posts = '/:year/:month/:slug/'

Die Voreinstellung, würde man das nicht einfügen, wäre:

'/:year/:month/:title/'

Die Voreinstellung will ich nicht, da ich teils lange Titel für Blogbeiträge habe, die URLs insgesamt aber relativ kurz halten möchte.

Jetzt verwende ich im Front Matter eines Blogbeitrags nur noch die Option slug: und habe im Endeffekt die selbe URL-Struktur und das ganze ist dadurch weniger fehleranfällig, falls man in der url bei Jahr oder Monat etwas Falsches einträgt.

Im Front Matter sah es früher so aus:

---

title: URL-Struktur in Hugo mit url, slug und title
url: /2022/02/url-struktur-hugo-url-slug-title
[…]

---

Und jetzt so:

title: URL-Struktur in Hugo mit url, slug und title
slug: url-struktur-hugo-url-slug-title
[…]

---

Erreichbar ist der Blogbeitrag in beiden Fällen unter:

natenom.de/2022/02/url-struktur-hugo-url-slug-title

Bestehende Blogbeiträge per Script ändern, irgendwann

Und wenn ich dann irgendwann mal alle Front Matter der Blogbeiträge automatisiert von url: nach slug: ändere, habe ich dann sogar die Möglichkeit, mit einer einzigen Änderung in der config.toml die URL-Struktur für alle Blogbeiträge auf einmal zu verändern. Natürlich sollte man in so einem Fall dann Weiterleitungen einrichten.

Bis dahin gibt es keine Probleme mit der bestehenden URL-Struktur, da die Option url: im Front Matter eines Beitrags immer die höchste Priorität hat.

Dokumentation

Die Dokumentation zu diesem Thema findet sich auf der Projektseite von Hugo.

ID vs Fancy URL

WordPress hat für jeden Blogbeitrag eine eindeutige ID. Statt einer fancy URL mit ausgeschriebenem Titel wie natenom.de/2022/01/tschuess-wordpress-hallo-hugo kann man daher auch die ID verwenden wie z. B.: natenom.de/?p=12345.

Ich hatte das schon auf dem Schirm. Leider nur in Bezug auf Beitragsentwürfe, nicht auf Verlinkungen in meinem Wiki auf den Blog.

Viele Verlinkungen auf den Blog per ID

Erst heute ist mir aufgefallen, dass es in meinem Wiki ca. 70 solcher Verlinkungen gab, die ich alle per Hand in die fancy URL auflösen musste. Da war die Suchfunktion von Hugo sehr gut. Hätte ich das vor dem Abschalten von WordPress gemacht, hätte ich nur den Link im Browser eingeben müssen und WordPress hätte mich selbst zur fancy URL geleitet.

Man kann solche Links in einem DokuWiki sehr leicht finden. Zuerst wechselt man auf der Konsole in das Verzeichnis data/pages und fürt dann aus:

grep -i -r '\?p=' .

Möglicherweise Zuordnung automatisch erzeugen

Da ich noch den Export meines alten WordPress-Blogs habe, könnte ich sicher auch darin die IDs finden und dann basierend auf dem Export eine Zuordnung von ID zu URL erstellen. Das schaue ich mir später vielleicht noch an. Bis dahin laufen solche Verlinkungen auf meinen Blog ins Leere bzw. auf die Startseite. Das könnte ich dann vielleicht so erstellen wie die Weiterleitungen zu den URLs mit Umlauten.

Die ID steht drin und die URL sind im Export enthalten:

[…]
<link>natenom.de/2010/11/mumble-server-lauft-wieder-rund/</link>
[…]
<wp:post_id>123</wp:post_id>
[…]

Sinnvoll?

Ich kann mich also daran versuchen. Ob es aber Sinn hat, aktuell über 2580 URL-Weiterleitungen von ID nach Fancy URL in der Nginx Konfiguratin zu haben?

Außerdem hatte ich schon fast immer Fancy URLs aktiviert. D. h. wenn überhaupt, dann hat man von außen nur zur Anfangszeit diese URLs aus der Adresseleiste des Browsers kopiert. Später habe ich die dann nur noch selbst benutzt, um Beiträge zu verlinken, die noch nicht öffentlich waren.

Das bedeutet, dass z. B. die alte URL vom WordPress-Blog “/tags/mobilitaet/” in Hugo “/tags/mobilität/” heißt.

Ich hatte bereits am ersten Tag der Umstellung in ganz wenigen Fällen manuell Weiterleitungen erstellt, insgesamt nur drei.

Heute habe ich mich dann etwas damit beschäftigt, geprüft und festgestellt, dass es neben der Kategorie “Mobilität” noch 88 Tags mit Umlauten oder “ß” gibt.

Ich hatte nicht wirklich Lust, das alles manuell einzugeben, und so habe ich ein bisschen Shell-Magic benutzt, um das zu automatisieren. Das will ich hier genau beschreiben.

Überlegungen

Nur am Anfang

Diese ganzen Weiterleitungen muss man natürlich nur am Anfang nach dem Umzug von WordPress nach Hugo bereitstellen. Irgendwann werden Suchmaschinen von selbst auf die neuen URLs mit Umlauten umspringen. Aber ich verstehe nix von SEO. Mir gehts darum, dass ich mal gelernt habe, dass URLs möglichst immer bestehen bleiben sollten.

Alle URLs umschreiben, nicht nur Tags

Es wäre auch möglich, zusätzlich noch alle URLs herauszufischen und die dann auch weiterzuleiten.

Nur je “Wort”, nicht allgemein möglich

Weiterleitungen, die Umlaute für sich umschreiben, wären wohl keine gute Idee, weil die Teilstrings “ae”, “oe”, “ue” und “ss” auch so in URLs vorkommen könnten. Deshalb muss man die einzelnen Begriffe rausfischen und die Weiterleitungen basierend auf diesen erstellen.

.*ss.* -> .*ß.*
.*oe.* -> .*ö.*

keine gute Idee:

essen -> eßen
oboe -> obö

Umgekehrt wäre das kein Problem.

Wie es geht

Datei 1 – Die aktuellen Tags aus Hugo auslesen

Ich verwende meinen hier beschriebenen Alias hugo-search-tags:

hugo-search-tags -E "(ä|ö|ü|ß)" | cut -d':' -f2 > /tmp/umlaut-urls-hugo.txt

Zum Verständis: Die Funktion hugo-search-tags gibt mir die Daten in diesem Format aus (Anzahl:Tag):

327:mobilität
88:müll
83:müllsammeln
64:wälder
51:landstraße
51:fahrradanhänger
33:überholen
24:sonnenuntergänge
[…]

Datei 2 – Die selben Tags in den WordPress-Stil umwandeln

hugo-search-tags -E "(ä|ö|ü|ß)" | cut -d':' -f2 | sed -e "s/ä/ae/g" -e "s/ö/oe/g" -e "s/ü/ue/g" -e "s/ß/ss/g" > /tmp/umlaut-urls-wordpress.txt

Beide Dateien vereinen

Jetzt kann man mit dem Shell Tool paste jede Zeile der einen Datei mit der selben Zeile der anderen Datei vereinen und als Trenner einen Doppelpunkt verwenden:

paste -d':' umlaut-urls-wordpress.txt umlaut-urls-hugo.txt

Das Ergebnis ist dann:

mobilitaet:mobilität
muell:müll
muellsammeln:müllsammeln
waelder:wälder
landstrasse:landstraße
fahrradanhaenger:fahrradanhänger
ueberholen:überholen
sonnenuntergaenge:sonnenuntergänge
fruehling:frühling
bussgeldstelle:bußgeldstelle
[…]

Links ist der String, wie er in WordPress verwendet wurde und rechts der von Hugo.

Konfiguration für Nginx erzeugen

Diese Ausgabe wird nun mittels sed so abgewandelt, dass man direkt die Ausgabe bekommt, die man in die Nginx-Konfiguration eintragen kann. Und das automatisch für alle Tags mit Umlauten.

Der gewünschte für “mobilität” ist zum Beispiel:

rewrite ^/tags/mobilitaet(.*)$ /tags/mobilit_t$1 redirect;

Dies erreicht man mit diesem Kommando:

paste -d':' umlaut-urls-wordpress.txt umlaut-urls-hugo.txt | sed -E -e 's_(.*):(.*)_rewrite ^/tags/\1(.*)$ /tags/\2$1 redirect;_g'

Anmerkung zu den Unterstrichen bei sed: Man kann als Trenner in sed fast beliebige Trennzeichen verwenden, solange sie innerhalb eines Ausdrucks immer gleich sind. Meist sieht man hier einen Schrägstrich.

Die Ausgabe ist:

rewrite ^/tags/mobilitaet(.*)$ /tags/mobilität$1 redirect;
rewrite ^/tags/muell(.*)$ /tags/müll$1 redirect;
rewrite ^/tags/muellsammeln(.*)$ /tags/müllsammeln$1 redirect;
rewrite ^/tags/waelder(.*)$ /tags/wälder$1 redirect;
rewrite ^/tags/landstrasse(.*)$ /tags/landstraße$1 redirect;
rewrite ^/tags/fahrradanhaenger(.*)$ /tags/fahrradanhänger$1 redirect;
rewrite ^/tags/ueberholen(.*)$ /tags/überholen$1 redirect;
rewrite ^/tags/sonnenuntergaenge(.*)$ /tags/sonnenuntergänge$1 redirect;
rewrite ^/tags/fruehling(.*)$ /tags/frühling$1 redirect;
rewrite ^/tags/bussgeldstelle(.*)$ /tags/bußgeldstelle$1 redirect;
rewrite ^/tags/kaelte(.*)$ /tags/kälte$1 redirect;
rewrite ^/tags/mehrplatzfuersrad(.*)$ /tags/mehrplatzfürsrad$1 redirect;
[…]

Nginx neustarten

Das kann man nun in Nginx eintragen und schon funktionieren alte Links wieder richtig :)

Vorher vielleicht noch testen mit:

nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Und Nginx neustarten.

Fertig. Alle Tags und Kategorien werden nun von den alten URLs auf die neuen von Hugo weitergeleitet.

Update: Jemand hat per E-Mail angemerkt, dass WordPress zwar mehr Anforderungen habe, dafür aber auch mehr Funktionalität wie Login oder Teamfähigkeit (die ich aber auch nicht benötige). Das ist richtig. :)

Ich habe Anfang Februar 2022 diesen Blog hier von WordPress auf Hugo umgestellt. Ich lasse hier mal die Liste der Vorteile stehen, die sich dadurch für meine Infrastruktur ergeben haben, falls ich jemals wieder mit dem Gedanken spielen sollte, WordPress oder etwas Ähnliches wieder verwenden zu wollen. Was ich derzeit nicht tue :)

• MySQL-Server abschalten und deinstallieren. Habe sonst nur noch ein DokuWiki im Betrieb, das keine Datenbank benötigt, weil es mit Flat files arbeitet.
• Backup von MySQL-Server deaktivieren.
• Backup des Webverzeichnisses des Blogs deaktivieren. Schließlich liegt jetzt die komplette Seite in einem lokalen Git-Repository und wird nur auf den Server geworfen.
• Alle Zugangsdaten für den Blog verwerfen.
• Schutzvorrichtungen (Basic Auth) für verschiedene Webverzeichnisse des Blogs wie /wp-admin entfernt.
• Vereinfachung der Nginx Konfiguration, da der Webserver für den Blog nur noch statische Dateien ausliefern muss.
• Entfernen des Cronjobs, der alle 10 Minuten lief und dafür sorgte, dass geplante Blogbeiträge zuverlässig veröffentlicht wurden, auch dann, wenn gerade niemand im Blog unterwegs war.
• Im Newsreader konnte ich den Filter löschen, den ich vor Jahren angelegt hatte, um News über Sicherheitslücken in WordPress und in Plugins zu erhalten.

Was will ich überhaupt lösen?

Mein Problem: In WordPress kann man beim Einfügen von Tags in einen Beitrag direkt Vorschläge sehen, die zum eingegebenen String passen. So wird verhindert, dass es irgendwann verschiedene Schreibweisen von Tags gibt und man immer die selben Tags verwendet.

In Hugo gibt es das natürlich nicht. Zumindest habe ich dazu nichts gefunden. Deshalb möchte ich eine Liste aller Tags angezeigt bekommen, die bisher allen vorhandenen Blogbeiträgen verwendet wurden und dazu auch noch die Anzahl der Vorkommen.

Ich könnte jetzt anfangen, $Suchmaschine zu benutzen und mir in Python irgendwas zusammen zu coden. Ich bin für die einfachere Möglichkeit. Denn schließlich zeigt das bei mir im Blog verwendete Theme bereits die Tags und Kategorien an und und sogar, wie oft diese verwendet wurden. Hugo kann also die Arbeit für mich machen.

Die Ideallösung wäre, wenn ich eine json-Datei erstellen lassen könnte mit diesen Informationen. Wie man so etwas macht, konnte ich leider nicht herausfinden. Ich bin Anwender, kein Programmierer.

Ultra hacky ab jetzt :P

Letzte Warnung: Mach hier zu, wenn du noch etwas Würde behalten möchtest :)

Zuerst erstellt man einen Shortcode in layouts/shortcodes/ mit dem Namen _internal-cats-tags.html mit folgendem Inhalt:

{{ range $.Site.Taxonomies.categories.ByCount }}
internal_category:{{ .Name }}:{{ .Count }}:
{{end}}

{{ range $.Site.Taxonomies.tags.ByCount }}
internal_tag:{{ .Name }}:{{ .Count }}:
{{end}}

Es ist Absicht, dass hier eine Textliste und kein HTML generiert werden soll. So muss man später weniger filtern.

Danach erstellt man in contents/ eine Datei _internal_cats_tags.md mit diesem Inhalt:

---
title: internal-only-cats-tags
date: 2022-02-08T02:43:20+01:00
---

{{< _internal-cats-tags >}}

Die Datei ist sollte jedoch am besten noch auf Entwurfsmodus eingestellt werden, also den Wert true im Tag draft haben, um nicht auf der veröffentlichten Website zu landen.

Dann lässt man Hugo die ganze Website rendern (Schalter -D für den Hugo-Aufruf nicht vergessen, damit Drafts auch gebaut werden) und erhält die Datei public/_internal_cats_tags/index.html.

Ergebnis

So sieht die generierte Seite aus:

Und so sieht der Quelltext aus:

[…] internal_category:643:allgemein: internal_category:416:mobilität:
internal_category:332:fotografie: internal_category:326:mumble:
internal_category:274:musik: […] internal_tag:761:open-source:
internal_tag:525:fahrrad: internal_tag:368:fotos:
internal_tag:348:creative-commons: internal_tag:335:mumble:
internal_tag:326:mobilität: internal_tag:292:musik:[…]

Aus dieser Seite kann man nun die Daten filtern.

Daten filtern und in neue Dateien schreiben

Jetzt kann man die Kategorien und die Tags herausfiltern und in neue Datien schreiben.

Nach Kategorien filtern

grep -i -E "^internal_category:[0-9]{1,4}:[a-z0-9-]*:$" public/_internal_cats_tags/index.html | sort -r -V | uniq | cut -d':' -f2,3 > _list-categories.txt

Ergebnis:

643:allgemein
416:mobilität
332:fotografie
326:mumble
274:musik
225:linux
162:web
94:android
66:spiele
34:linkdump

Tags

grep -i -E "^internal_tag:[0-9]{1,4}:[a-z0-9-]*:$" public/_internal_cats_tags/index.html | sort -r -V | uniq | cut -d':' -f2,3 > _list-tags.txt

Ergebnis:

525:fahrrad
368:fotos
335:mumble
326:mobilität
292:musik
256:linux
241:pforzheim
215:videos
213:natur
206:filme
[...]

Helfer für die Bash

In die .bashrc kommt hinein:

export HUGO_WORKDIR="/home/natenom.de-hugo"

function hugo-check-and-write-cats-tags (
    cd $HUGO_WORKDIR
    test -f public/_internal_cats_tags/index.html && \
        grep -i -E "^internal_category:[0-9]{1,4}:[a-z0-9]*:$" public/_internal_cats_tags/index.html | sort -r -V | uniq | cut -d':' -f2,3 > _list-categories.txt && \
        grep -i -E "^internal_tag:[0-9]{1,4}:[a-z0-9]*:$" public/_internal_cats_tags/index.html | sort -r -V | uniq | cut -d':' -f2,3 > _list-tags.txt && \
        echo "Updates written" || \
        echo "File is not available, no updates."
)

alias hugo-search-tags='cd $HUGO_WORKDIR; cat _list-tags.txt | grep -i '
alias hugo-search-categories='cd $HUGO_WORKDIR; cat _list-categories.txt | grep -i '

Wenn ich den Eindruck habe, dass die extrahierten Daten veralten sein könnten, rufe ich in der Shell hugo-check-and-write-cats-tags auf, sobald die komplette Website generiert wurde.

Suchfunktion

Jetzt kann ich nach Tags suchen:

$ hugo-search-tags oliz
66:polizei
3:polizeipräsidium
2:polizeipräsidentin

Und nach Kategorien:

$ hugo-search-categories ""
643:allgemein
416:mobilität
332:fotografie
326:mumble
274:musik
225:linux
[…]

Und im KDE Advanced Text Editor (kate) kann ich dann direkt mit F4 eine Konsole öffnen und nach Kategorien und Tags suchen, während ich das Front Matter bearbeite.

Später

Und irgendwann mal, später, also irgendwann später, mache ich das dann auch so, dass man sich nicht für die Lösung schämen muss. Ganz bestimmt.

Genau diese Funktionalität fehlt mir in Hugo.

Aber das ist kein Problem. Ich kann zwar nicht programmieren, habe aber noch ein paar alte Kenntnisse zur Shell.

Dabei sind eine Shell-Funktion und ein Alias entstanden. Die Funktion, weil dort einfache Hochkommata gebraucht werden und mir das Maskieren der inneren einfachen und doppelten Anführungszeichen in der Befehlszeile zu umständlich ist. Und dann tortzdem ein Alias, das die Funktion aufruft, weil es so nämlich möglich ist, dass man nach dem Alias einfach so weiter schreibt, als hätte man den Alias gerade selbst geschrieben.

In die .bashrc schreibt man:

export HUGO_WORKDIR="/home/src/hugo"

function hugo-search-posts-helper (
    cd $HUGO_WORKDIR
    hugo list all | awk -F',' '{print "\n\""$3"\"\t"$8}'
)

alias hugo-search-posts='hugo-search-posts-helper | grep -i'

Jetzt kann man z. B. nach Posts mit hugo suchen:

$ hugo-search-posts hugo
"Kleiner Helfer zum Finden von Links in Hugo (nach dem Vorbild WordPress)"      /2022/02/kleiner-helfer-zum-finden-von-links/
"Nextcloud Editor für Markdown-Dateien zerstört Front Matter von Hugo"  /2022/02/nextcloud-editor-zerstoert-frontmatter/
"Umzug von WordPress zu Hugo – Teil 2 – Bestandsaufnahme und Korrekturen"       /2022/01/umzug-des-blogs-von-wordpress-zu-hugo-teil-2/
"Umzug von WordPress zu Hugo – Teil 1 – Von den Gründen bis zum ersten funktionierenden Blog"   /2022/01/umzug-des-blogs-von-wordpress-zu-hugo-teil-1/
"Hugo kann mehrsprachig :)"     /2016/12/hugo-kann-mehrsprachig/
"gpEasy (PHP) durch Hugo (statisches HTML) ersetzt"     /2015/12/gpeasy-php-durch-hugo-statisches-html-ersetzt/

Ich weiß, dass man das bestimmt auch in schön machen kann. Aber mir reicht das so. Ich nehme aber auch Spenden von entsprechend schönem Code an. Vielleicht gibts auch schon was Fertiges, das ich nicht über $Suchmaschine gefunden habe.

Man kann natürlich auch auf der Webseite direkt suchen oder, wenn man keine Netzwerkverbindung hat, Zuhause den Befehl hugo server nutzen. Letzteres dauert bei mir aber ca. 50 Sekunden fürs Rendern.

Update: Der Workflow ist so gut, dass ich das immer dann veröffentlichen werde, wenn genug Links gesammelt sind. Details siehe hier.

Ich mache wieder einen Linkdump von Dingen, die ich die Woche über gelesen habe. Das ist jetzt einfacher für mich, weil ich das jetzt auch wieder auf dem Smartphone einfach direkt beim Lesen erledigen kann:

• Datei öffnen (am PC oder Smartphone)
• URL einfügen, optional etwas Text dazu.
• Dank Markdown kann ich auch direkt alles formatieren.
• Fertig.

Mit WordPress musste ich mich immer erst auf der Webseite anmelden und brauchte dafür natürlich auch einen Netzzugang. Dann musste ich den Editor von WordPress benutzen, der auf einem Smartphone nicht gut zu bedienen ist und dort alles formatieren. Das war immer eine zu große Hürde, um eben mal nen Link einzufügen. Habe es dann auch damit versucht, die gelesenen Links irgendwo abzulegen und den Linkdump später zu schreiben. Auch diese Hürde war zu groß und ich hatte nie Lust, das fertig zu machen.

Ein weiterer Vorteil von Hugo ist die gute integrierte Suche, mit der ich Dinge finde, die ich mit der WordPress-Suche nie gefunden habe und deshalb in der Vergangenheit immer eine Suchmaschine benutzt hatte. So gehe ich davon aus, dass ich irgendwelche abgelegten Links auch wiederfinden werde.

Auf dem PC benutze ich ich zum Bearbeiten der Markdown-Datei kate (KDE Advanced Text Editor) und auf dem Smartphone (Android) die App Markor.

Der aktuelle Linkdump der Woche liegt dabei als Page Bundle (Verzeichnis) in einer Nextcloud. Zugang dazu habe ich sowohl auf dem Smartphone als auch auf dem PC. In diesem Verzeichnis gibts eine Datei index.md, in die ich hier gerade schreibe, in die alle Links eingefügt werden.

Wenn ich Samstag abend fertig bin, verschiebe ich das Verzeichnis auf dem PC nach content/posts von Hugo, passe das Front Matter (Metadaten) an, lasse Hugo den Blog generieren, lade alles hoch und schon ist der Linkdump veröffentlicht.

Dann erstelle ich für den Linkdump der nächsten Woche ein neues Page Bundle. Dafür habe ich eine Vorlage in archetypes erstellt:

---
title: Linkdump KW FIXME/2022
url: /2022/xx-linkdump-kw-FIXME-2022
date: { { .Date } }
author: Natenom
description: Linkdump für Kalenderwoche FIXME/2022
images:
  - featured.png
categories:
  - Linkdump
tags:
  - FIXME
---
## Allgemein

## Regionales

Mit der folgenden Befehlszeile kann ich dann das Page Bundle für den nächsten Linkdump erstellen lassen:

hugo new -k linkdump posts/2022-02-linkdump-kw-6-2022

Das neue Page Bundle verschiebe ich dann wieder in die Nextcloud, um auf beiden Geräten Zugriff zu haben.

Der Ranomier stellt mir hierfür einen Nextcloud-Zugang zur Verfügung. Vielen Dank dafür :)

Für die Linkdumps gibt es eine eigene Kategorie: Linkdump. Dort sind auch schon die alten Linkdumps zu finden.

Hier im zweiten Teil geht es darum, für die Übergangszeit das übrig gebliebene HTML, das nicht zu Markdown konvertiert werden konnte, automatisiert so zu verändern, dass der Blog trotzdem ansehnlich ist, wenn auch noch nicht perfekt. Das hat den Vorteil, dass ich den Blog mit Hugo bereits aktiv nutzen kann und nicht im Hintergrund erst alles auf manuell auf Markdown umstellen musste.

Es wird nicht ganz so viel werden, wie im ersten Teil.

Übrig gebliebenes HTML schön machen

Wie bereits erwähnt enthalten viele exportiere Beiträge noch einiges an HTML-Quelltext, der vom Export-Tool nicht in Markdown umgewandelt werden konnte. Und ich werde noch eine Weile mit diesem HTML Code leben müssen, bis ich es irgendwann geschafft habe, alles in sinnvolles Markdown zu übersetzen.

Ich wollte aber schon vorher den neuen Blog mit Hugo veröffentlichen. Deshalb war es notwendig, dass ich diesen bestehenden HTML Code soweit schön mache, dass es am besten gar nicht auffällt, dass die Quelle noch kein Markdown verwendet.

Nachfolgend werden die dafür notwendigen Anpassungen erläutert.

Wichtig: wp-content behalten

Damit nicht so gut wie alle Bilder und Fotos fehlen, die bisher nur über “alten” HTML-Code statt über Markdown eingebunden sind, habe ich eine Kopie des Verzeichnisses wp-content/uploads/ auch im Webverzeichnis der neuen statischen Webseite eingebunden. So funktionieren alle bisherigen Verlinkungen und Einbettungen weiterhin.

Mit der Zeit werde ich alle Galerien im Blog so umschreiben, dass die Page Bundles benutzen, d. h. die Bilder für einen Beitrag sind zusammen mit dem Beitrag selbst in einem eigenen Verzeichnis.

Verzerrte Fotos in Galerien

In einigen der Galerien wurden die Fotos noch in WordPress mit width=“2000” und height=“xxx” eingebunden. Das führte dazu, dass sie im neuen Hugo-Theme aufgrund der fehlenden Breite, oder weshalb auch immer, gestaucht angezeigt werden.

Daher habe ich die beiden Tags komplett entfernt mit:

sed -i -E -e 's/ width="[0-9]{1,4}"//g' *.md
sed -i -E -e 's/ height="[0-9]{1,4}"//g' *.md

Diese Zeilen entfernen natürlich alle Vorkommen von width und height. Soweit ich gesehen habe, bleiben diese Tags nach dem Export aus WordPress aber wirklich nur bei Bildern und vermutlich auch bei Videos erhalten.

Unscharfe Fotos – Zu klein wird zu groß angezeigt

In anderen Blogbeiträgen gab und gibt es immer noch unscharfe Fotos. Das liegt daran, dass diese Bilder in WordPress als kleine Vorschaubilder angezeigt wurden und bei einem Klick darauf die großen Varianten der Bilder in voller Auflösung in einer Lightbox geföffnet wurden.

So sah der Beitrag ursprünglich in WordPress aus:

Erste Möglichkeit bei unscharfen Bildern: Lightbox benutzen

Die verwendete Lightbox öffnet im Overlay nicht die kleine Datei sondern die verlinkte, große Datei. In der Lightbox ist das Bild somit scharf.

So sieht es dann aus:

In Hugo werden nur noch diese kleinen Bilder in viel zu groß dargestellt. Dank einer verwendeten Lightbox werden zumindest beim Anklicken die Originalfotos in einem Overlay angezeigt und für die Übergangszeit reicht mir das so auch.

Für diese Lösung habe ich mich erst einmal entschieden.

Zweite Möglichkeit bei unscharfen Bildern: HTML automatisiert anpassen …

Man kann das Problem auch damit beheben, dass man den HTML-Quelltext so abändert, dass statt der kleinen Dateien überall die Originaldateien eingebunden werden, aber weiterhin auch verlinkt bleiben.

Damit wird z. B. statt dem eingebetteten Bild mumble-git-1-100x50.jpg das Bild mumble-git-1.jpg eingebunden. Nicht optimal, da es aus sein kann, dass ein riesiges Originalfoto von einer Landschaft dann relativ klein angezeigt wird. Öffnet man einen Blogbeitrag mit einer Galerie von Landschaftsfotos, dann sieht man zwar nur kleine Bilder, der Browser lädt dann aber direkt alle Bilder in voller Auflösung herunter.

Deshalb habe ich mich gegen diese Lösung entschieden, obwohl sie am besten aussieht.

Hier trotzdem die Befehlszeile(n), um die URLs der kleinen Varianten der Bilder gegen die Originale zu ersetzen:

sed -i -E -e 's#-[0-9]{1,4}x[0-9]{1,4}\.jpg#\.jpg#g' *.md
sed -i -E -e 's#-[0-9]{1,4}x[0-9]{1,4}\.png#\.png#g' *.md
sed -i -E -e 's#-[0-9]{1,4}x[0-9]{1,4}\.gif#\.gif#g' *.md

Natürlich muss man diese Zeilen für die verwendeten Dateitypen anpassen (png, gif, …).

Das Ergebnis wäre dann:

srcsets entfernen

Um zusätzlich noch die srcsets aus solchen Galerien zu entfernen, kann man diese Zeile ausführen:

sed -i -E -e 's# class=".*;" />#/>#g' *.md

Ich habe das erst einmal sein lassen. Vielleicht schaffe ich es ja noch, dass diese srcsets doch noch genutzt werden, solange ich noch nicht alles auf Markdown umgewandelt habe.

Eingebettete Videos werden zu breit dargestellt

Mit dem video-Tag eingebundene Videos sind im Theme so breit, dass sie teilweise hinter dem rechten Seitenpanel versteckt sind.

Um das zu heben, habe ich erstmal ein bisschen css verwendet:

video {
  max-width: 100%;
  height: auto;
}

Damit werden alle Videoeinbettungen, auch die, die ich später mit Markdown verwenden werde, richtig angezeigt.

Später werde ich den HTML Code durch einen Shortcode video ersetzen.

Artikelbilder

In den WordPress-Themes, die ich bisher verwendet hatte, gab es immer Artikelbilder. Ich finde das sehr schön, weil es meiner Ansicht nach auflockernd wirkt und man besser erkennt, worum es in einem Blogbeitrag gehen könnte. Deshalb fand ich es schade, als ich bemerkte, dass in meinem ausgewählten Theme keine Artikelbilder zu sehen waren.

Ich habe dann selbst versucht Artikelbilder zu implementieren und dabei dann entdeckt, dass das Theme solche durchaus vorsieht und nur die richtigen Angaben im Front Matter fehlten.

Dank des Exports von WordPress landeten im Frontmatter bei immerhin ca. 1900 von 2460 Beiträgen die Angaben zu Artikelbildern im Stil von:

featured_image: dateiname.jpg

Doch das Hugo Theme erwartet die folgende Struktur:

images:
  - dateiname.jpg

Kein Problem, denn mit dem Streamingeditor sed unter Linux ist das mit einem Befehl erleidgt:

sed -i -E -e 's/^featured_image: (.*)$/images:\n  - \1/' *.md

Seitdem werden, wie auch im WordPress zuvor, Artikelbilder auch im mit Hugo generierten Blog angezeigt.

Reicht wieder

Das reicht auch schon für den zweiten Teil.

Im nächsten Teil geht es dann um Lightboxen, Kommentare, um verschiedene Konfigurationsmöglichkeiten und mehr.

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.

Diese kann man entweder manuell löschen oder mit einem WordPress-Plugin, wie z. B. diesem hier.

Von einst 134 Dateien im Verzeichnis von MySQL sind nach dem Cleanup noch 18 übrig geblieben.

https://wiki.natenom.de/docs/sammelsurium/wordpress/datenbank_aufraeumen

Dank der Arbeit von Vrifox, die einige Dinge an unsere Bedürfnisse angepasst hat, sind wir auch mit dem neuen Aussehen zufrieden.

Die Anpassungen sind hier zu finden. Schön ist, dass auch die Leiste ganz oben hell wird, wenn man im Blog die Ansicht umschaltet.

Danke fürs Anpassen :)

Die Suchfunktion ist jetzt nicht mehr oben (Lupe im Screenshot) sondern ganz unten auf der Seite; nicht schön, ist mir auch eben erst aufgefallen.

Hier im Direktvergleich, der Blog bisher:

Und der Blog jetzt – im hellen Modus:

Und im dunklen Modus:

Automatische Hell-Dunkel-Auswahl im Browser

Siehe hier.

In der letzten Zeit und speziell in den letzten Tagen hat sie wieder mal ganz viel Arbeit investiert und viele Dinge gemacht, umgestaltet und verschönert, die ich hier auflisten möchte.

SCSS an zentraler Stelle statt Knuddelmuddel

Früher gab es eine CSS-Datei für den Blog, eine fürs Wiki und ganz früher noch je eine Datei für weitere meiner Webseiten. Das alles zu warten, war immer sehr umständlich. Vrifox hat das ganze CSS-Zeugs nach SCSS portiert und die Handhabung damit deutlich vereinfacht, da man in SCSS auch z. B. Variablen nutzen oder andere Dateien importieren kann. Am Ende generiert man aus den SCSS-Dateien je eine CSS-Datei fürs Wiki, eine für den Blog, eine für die Dateiablage und eine für die Hauptseite.

Wer daran interessiert ist, wie alles funktioniert, der darf sich gerne den Quelltext ansehen unter code.cozy.town/vri/natenom-websites.

Mein Logo im Git

Mein Logo und alle Varianten davon gibt es jetzt in einem Git-Repo, siehe hier.

Navigation im Wiki

Erst vor wenigen Tagen hat sie wieder etwas sehr schönes umgesetzt. Sie hat die Hervorhebung der aktuellen Seite im Wiki, die Hover-Effekte und auch die Anzeige von überlangen Überschriften deutlich verschönert.

So sieht die Navigation im Wiki jetzt aus:

Es gibt wieder eine Hauptseite

Es gibt wieder eine Hauptseite, www.natenom.com. Dort ist die Seite „Über Natenom“ gelandet, die vorher im Blog war. Das passt meiner Ansicht nach besser dorthin, da das sozusagen meine „Einstiegsseite“ ist, wenn man z. B. natenom.de oder natenom.com im Browser eingibt.

GlobalTopBar für Dateiablage und Startseite

Vrifox hat die „GlobalTopBar“ jetzt auch auf f.natenom.de und auf www.natenom.com eingebunden. Die „GlobalTopBar“ ist die obere Leiste, die man auf allen meinen Webeiten sehen und über die man zu allen meinen Webseiten navigieren kann.

Datenschutz und Impressum

Über die GlobalTopBar erreicht man jetzt auf allen Webseiten die dazugehörigen Datenschutzbestimmungen und das globalen Impressum. Bei der Dateiablage war dies zuvor nur im Hauptverzeichnis möglich und die Hauptseite (www.natenom.com) hatte ich zuvor gar nicht genutzt.

Dunkles Theme für Dateiablage und Hauptseite

Die Dateiablage unter f.natenom.de und die Hauptseite unter www.natenom.com haben zusätzlich ein Dark-Theme bekommen.

Mal wieder bin ich sehr dankbar, dass Vrifox mir dabei hilft :)

Falls jemandem ein Fehler auffällt, kann er sich gerne melden, das ganze Webdings ist ein fortwährendes Projekt, an dem Vrifox immer wieder arbeitet.

Jetzt konnte ich es – zufällig – lösen. Es war eine Leerzeile am Ende der functions.php des Child-Themes. Ich habe diese entfernt und dann war wieder alles in Ordnung.

Auch an andere Stelle hatte diese Leerzeile ein Problem verursacht – bei der Sitemap, siehe hier.

Für Suchmaschinen gab es bisher damit keine Probleme, aber es war nicht schön, dass man die Sitemap nicht direkt ansehen konnte; außer über den Quelltext.

Jetzt habe ich zufällig endlich herausgefunden, wo das Problem lag. In der functions.php des verwendeten Childthemes war am Ende eine Leerzeile.

Das wars; Leerzeile entfernt und schon funktioniert es, wie es soll.

Somit konnte ich das bisher genutzte Plugin „Google XML Sitemaps“ deinstallieren. Wieder etwas aufgeräumt.

Man sollte daran denken, in der robots.txt die URL der Sitemap anzupassen. Und man kann auch noch eine Weiterleitung von der alten URL auf die neue einstellen. In meinem Fall von sitemap.xml nach wp-sitemap.xml.

Anscheinend ist das nicht allen Menschen klar und so wurde auch mal behauptet, ich würde mit dem Blog Geld verdienen. Dem ist nicht so.

Ich habe noch nie für irgend einen Beitrag in meinem Blog oder in meinem Wiki Geld von irgendwem bekommen und auch keine anderen Gegenleistungen.

Wenn ich über etwas schreibe, dann nur, weil es mich interessiert und meistens, weil ich es selbst benutze oder benutzt habe. Und dann schreibe ich auch nur das, was ich an Erfahrungen damit gemacht habe oder wie meine Meinung dazu ist.

Vor einigen Jahren gab es für kurze Zeit Werbung auf meinen Webseiten, weil ich mir das Hosting damals aus eigenen Mitteln nicht mehr hätte leisten können.

Ich bekomme ab und zu Anfragen für bezahlte Beiträge, habe darauf aber noch nie reagiert.

Um das – aus meiner Sicht Offensichtliche – klar zu zeigen, habe ich die Idee eines Menschen umgesetzt und nachträglich unter alle Blogbeiträge zu Produkten einen sogenannten Disclaimer gesetzt:

Wenn ich einen Beitrag übersehen habe, dann werde ich das dort noch nachholen. Auch bei neuen Beiträgen zu Produkten wird es diesen Disclaimer geben.

Technisch ist der Disclaimer ein selbst erstellter Block im Gutenberg-Editor von WordPress.

Für [mein Wiki][1] muss ich mir jetzt auch noch eine Möglichkeit für einen Disclaimer überlegen, denn Vorlagen, wie man sie von z. B. MediaWiki kennt, gibt es in DokuWiki nicht habe ich jetzt auch einen Disclaimer, siehe hier. Wie genau das funktioniert, steht natürlich in meinem Wiki, siehe hier.

Deshalb habe ich im Plugin „Socialcards“ meines DokuWikis eine höher aufgelöste Version meines Logos hinterlegt. Im Blog tat ich dasselbe in den Einstellungen des WordPress-Plugins Open Graph.

In beiden Fällen wird das Logo immer dann automatisch für Twitter-Cards verwendet, wenn es im Blog kein Artikelbild oder im Wiki keine Bilder auf der Seite gibt.

Hier der Unterschied zwischen jetzt (oben) und vorher (unten) im Twitter-Client:

Beide Plugins funktionieren übrigens nicht nur für Twitter sondern auch für andere Plattformen, auf denen Links zu den Webseiten eingefügt werde. Der Standard, der das ermöglicht, heißt Open Graph.

Allerdings in einer modifizierten Dark-Version, die mir Vrifox bereit stellt.

Damit wurde hier im Blog das alte Thema Twentyfourteen abgelöst, das seit 2013 verwendet wurde. Mit vielen Modifikationen sah das das zuletzt so aus wie hier:

Für Interessierte habe ich die Liste der Modifikationen im Wiki hinterlegt; und auch für mich, falls ich irgendwann zurück zu diesem Design möchte.

Jetzt sieht es so aus wie auf der Webseite zu sehen, bzw. hier für den Fall, dass ich es wieder ändern werde:

Plugins gelöscht

Durch den Wechsel auf das neue Thema konnte ich auch zwei weitere Plugins aus WordPress entfernen.

• Disable Google Fonts
• Fourteen Colors

Keine Google-Fonts mehr von Haus aus

Mir gefällt sehr, dass WordPress in der neuen Version die verwendete Schriftart selbst mitliefert und nicht, wie bei älteren Versionen, per Google-Fonts einbindet. Zumindest nicht für den normalen Benutzer einer Webseite. Im Editor werden durchaus Schriften von Google eingebunden. Aber die habe ich gesperrt.

Anpassungen und was noch fehlt

Folgende Anpassungen sind für das neue Thema gemacht worden:

• Dunkler Hintergrund
  • Hintergrundfarbe für Header und Footer: #252d39
  • Hintergrundfarbe: #212730
• Weißer Text
• Überschriften kleiner
• Weiterlesen-Button nicht mehr so hoch und nicht mehr „Uppercase“.
• Abstand der Bilder (oben und unten) wurde verringert. Auch bei Beiträgen ohne Artikelbild ist der Abstand kleiner.
• Die Bildbeschreibungen von Artikelbildern wurden ausgeblendet, da ich sie dort nicht haben will.
• Autor im Headerbereich der Beiträge wurde ausgeblendet; das ist mein Blog, daher unnötig.
• Fürs Cover-Template hat der Bereich mit dem Overlay nur noch 60% der Höhe. Man sieht dadurch besser, dass es unten weitergeht.
• Farbe fürs Cover-Overlay: #252d39
• Die Primärfarbe lässt sich zwar im Interface von WordPress einstellen, jedoch nur über einen Hue-Farbpicker und der ist sehr ungenau. Eigene Werte lassen sich dort nicht eintragen. D. h. entweder muss man umständlich alles übers CSS anpassen oder in der Datenbank den Wert manuell setzen. Ziel war hier das Blau meines Elefanten-Icons und es ist jetzt umgesetzt.
• Seit dem Update des Themas auf Version 1.1 funktionieren das Menü und die Suche auch auf dem Smartphone.

Aufräumarbeiten

Da ich sowieso einige der alten Beiträge durchschauen musste, habe ich direkt einige davon gelöscht (150 an der Zahl).

Damit eingebettete Videos in der mobilen Ansicht des Blogs auf dem Smartphone nicht zu breit dargestellt werden musste ich jedes Video im Beitrag anpassen. Dazu wurde der Beitrag mit „In Blöcke umwandeln“ bearbeitet und dann musste die Art der Videoeinbettung geändert werden.

Auch gab es und gibt es immer noch viel zu tun wegen der hier verwendeten Galerien. Dazu später mehr in einem eigenen Beitrag.

Ich habe die Ansicht, dass Äußerungen im Kommentarbereich irgendwann gelöscht werden sollten, aus mehren Gründen:

• Oftmals enthalten sie veraltete und/oder nicht mehr gültige Informationen.
• Die Namen der Verfasser und ihre Inhalte müssen nicht „für immer“ mit dem Blog hier verbunden sein (Recht auf Vergessen).
• Bis auf Suchmaschinen liest sie eh so gut wie niemand, wohl eher keiner.
• Wenn ich meinen Blog irgendwann einmal auf einen statischen Webseitengenerator umstelle, dann werde ich weniger Arbeit mit den Kommtaren haben.

Wenn jemand möchte, dass ich einen Kommentar lösche und nicht bis zur nächsten Löschaktion warten will, so möge dieser mich kontaktieren, siehe Datenschutzerklärung für meinen Blog.

Mit dem heutigen Update auf WordPress 5.3 wurde das Problem teilweise behoben. Zwar kann man immer noch nicht die Vorschaugröße selbst einstellen. Diese wird indirekt automatisch über die Anzahl der Spalten der Galerie festgelegt. Aber immerhin wird beim Anklicken der Bilder nicht mehr die Miniversion der Bilder geöffent sondern das Bild in voller Auflösung. Für mich reicht das aus. Einen schon ziemlich alten Bugreport dazu gibt es auf Github, siehe hier.

Wenn man trotzdem noch den Classic Editor für Galerien verwenden möchte, so muss man jetzt nur noch zum Erstellen einer Galerie in diesen Wechseln. Eine bereits vorhandene Galerie in einem Beitrag kann man jetzt auch im Gutenberg Editor komplett mit allen Einstellungen bearbeiten, so als wäre man im alten Editor.

Ich brauche das aber nicht mehr, deshalb konnte ich heute das Plugin für den Classic Editor endlich löschen und arbeite jetzt nur noch mit dem Gutenberg Editor. Gleichzeitig kann ich auch das Plugin Publish Confirm löschen, das bei einem, meist versehentlichen, Klick auf „Veröffentlichen“ eine zusätzliche Abfrage stellte, damit nicht aus Versehen ein unfertiger Blogbeitrag veröffentlicht wird. Diese Funktion ist bereits im Gutenberg Editor enthalten.

Sehr schön; einen schönen Editor bekommen, zwei Plugins entfernt. Passt. In den nächsten Tagen werde ich dann noch testen, ob das neue Thema Twenty Twenty für meine Bedürfnisse passen könnte.

Ich brauche keine Kommentare oder Likes für Videos und die meisten Videos enthalten nur kurze Videosequenzen, die wenig Speicherplatz benötigen.

Dadurch benötige ich auch das WordPress Plugin „Video Embed Privacy“ nicht mehr und mein WordPress ist damit wieder etwas „leichter“.

Falls ich doch noch auf Youtube verlinke, dann nur noch mit einem Textlink und ohne Einbettung. Es könnte sein, dass ich die eine oder andere Einbettung übersehen habe, das werde ich dann noch nachholen.

Fügt man einen Galerie-Block ein, dann werden nicht die voll aufgelösten Bilder verlinkt sondern nur kleine Versionen der Bilder.

Die einzige Möglichkeit ist aktuell, dass man für das Erstellen einer Galerie in den Classiceditor wechselt und dann wieder zurück.

Einen Bugreport gibt es bereits, siehe hier.

Eine dieser Aufgaben war es, die in meinem Blog verwendeten Kategorien zu ordnen. Gestern noch gab es 40 Kategorien, teilweise verschachtelt. Immer wenn ich einen neuen Beitrag erstellt hatte, fügte ich ihn in mehrere Kategorien ein. Ein Beitrag über OsmAnd beispielsweise kam in die Kategorien „OpenStreetMap“, „FOSS“, „Open Source“ und „Android“. Als Schlagwörter fügte ich dann dieselben Begriffe und noch weitere ein.

Ich hatte niemals wirklich das System von Kategorien und Tags/Schlagwörter verstanden, das man in WordPress benutzt; bis gestern. Da hatte ich mir im Kontext von Hugo so einiges dazu durchgelesen.

Das Ergebnis ist, dass es jetzt nur noch 10 Kategorien in meinem Blog gibt und dass jeder Artikel nur noch in genau einer Kategorie zugehörig ist. Zudem gibt es keine verschachtelten Kategorien mehr. Ein Beitrag kommt immer in die Kategorie hinein, die direkt und am besten passt.

Ich habe übrigens keine Beiträge gelöscht, sondern nur die Zuordnungen zu Kategorien.

Dies sind die neuen Kategorien, die man jetzt auch immer in der oberen Leiste sieht:

• Allgemein (vorher: Linkdump, Links, Mumblezitate)
• Android
• Fotos (vorher: 360°-Foto-Schnappschüsse, Foto-Schnappschüsse, Momentaufnahmen, Film)
• Hardware
• Linux
• Mumble
• Musik
• Spiele (vorher: Sauerbraten, Minecraft)
• Verkehr/Mobilität (vorher: Fahrradpolitik, Regionen, Pforzheim, Stuttgart, Leonberg, Karlsruhe, Radreisen, OpenStreetMap)
• Webdesign/Hosting (vorher: MediaWiki, DokuWiki, Wiki, WordPress)

Das, was ich bisher falsch gemacht hatte, mache ich jetzt nicht mehr über Kategorien, sondern über die Tags. Oder in kurz: Die Kategorie ist die grobe Einordnung eines Beitrags, während die Tags den genauen Inhalt spezifizieren.

Auch die Anzahl der Tags habe ich reduziert, vor allem, solche, die doppelt vorkamen, wie z. B. „Bilder“ und „Fotos“.

Falls jemand auf die Idee kommt, zu fragen, welches Plugin ich dafür verwendet habe… ich habe tatsächlich alle 2240 Blogbeiträge mehrfach über die „Quick-Edit“-Funktion bearbeitet.

Statt der Liste der Kategorien, die bisher links an der Seite zu sehen war, sieht man dort jetzt die am häufigsten im Blog verwendeten Tags, die je nach Anzahl der Verwendungen größer sind.

Um die Breite an die des tatsächlich im Blog verwendeten Themes anzupassen, muss man ein paar Dinge anpassen.

Welche genau das sind, kann man hier nachlesen.

Was wir alles geändert haben:

• Die globale Topbar, die auf allen meinen Webseiten zu sehen ist, ist nun dunkler, hat einen Hover-Effekt und sieht insgesamt schöner aus.
• Die Suchleiste wird jetzt an der richtigen Stelle angezeigt und nicht mehr mitten auf der Webseite.
• Der Blog ist nun ziemlich dunkel gehalten und nur die einzelnen Artikel sind weiß hinterlegt. Somit lässt sich noch besser erkennen, wo ein Artikel anfängt und aufhört.
• Das Aussehen der Tags unterhalb der Artikel wurde dezenter gemacht und die Tags sind nicht mehr durchgehend groß geschrieben.
• Die Artikelbilder werden nicht mehr teilweise von den Überschriften verdeckt sondern sind komplett sichtbar.
• Die Artikelbilder sind an den oberen Ecken abgerundet.
• Artikel selbst sind am unteren Rand abgerundet.
• Und noch einiges mehr, das ich vergessen habe.

Zum Vergleich, vorher und nachher:

• Die Artikel sind jetzt breiter als zuvor (700 Pixel statt 474 Pixel).
  • Artikelbilder (die über der Überschrift) sind kleiner geworden (maximal 760 Pixel statt 100% der verfügbaren Breite).
  • Der Hintergrund der Artikelbilder ist nicht mehr weiß/schraffiert sondern dunkel gehalten. Dadurch kann man beim Durchscrollen besser erkennen, wann ein neuer Artikel beginnt.

Hier ein aktueller Screenshot, falls das Design wieder ändert wird:

Der Blog, das Wiki und meine Hauptseite haben jetzt zur besseren Unterscheidung bei mehreren offenen Tabs leicht modifizierte Favicons.

Das Favicon vom Wiki hat unten einen roten Streifen, der Blog einen organgenen Streifen und die Hauptseite hat das Standard-Favicon. Mein altes MediaWiki hat einen grünen Streifen.

Die Idee stammt übrigens von einem gewissen Menschen; zuerst fand ich die Idee nicht gut, später aber dann doch. Umgesetzt hat sie Vrifox.

Plugins vom Blog entfernt

Ich habe in meinem Blog ein paar Plugins rausgeschmissen.

• WP-to-Twitter
• Mastodon Autopost
• Öffentliche Vorschau

Wenn ich einen neuen Blogbeitrag veröffentliche, dann werde ich diesen irgendwann später manuell auf Twitter und Mastodon verlinken.

Blog ist nur noch zweispaltig

Die dritte Spalte rechts mit der Tagwolke und der Liste der letzten 10 Beiträge habe ich entfernt. Deshalb sind die Artikelbilder jetzt größer und Dank Vrifox sind die Artikelbilder auch mittig angeordnet.

Verschiedene Headerbilder im Blog

Ich werde wieder von Zeit zu Zeit neue Bilder oben im Header einfügen.

Spendeninformationen entfernt

Die Spendeninformationen, die seit wenigen Wochen auf jeder meiner Websites zu sehen war, habe ich komplett entfernt. Dafür ist jetzt in der globalen Topbar, die auf allen meinen Websites sichtbar ist, der Link zu „Spenden“ farblich hervorgehoben.

Natürlich gibt es weiterhin eine Spendenübersicht, siehe hier.

Neue Weiterleitungen

Die folgenden URLs werden auf die deutschsprachigen Seiten weitergeleitet:

• natenom.de/kontakt
• natenom.de/mumble
• natenom.de/blog
• natenom.de/wiki
• natenom.de/matrix
• natenom.de/spenden

Und diese URLs werden auf die englischsprachigen Seiten weitergeleitet:

• natenom.com/contact
• natenom.com/mumble
• natenom.com/blog
• natenom.com/wiki
• natenom.com/matrix
• natenom.com/donate

GlobalTopBar

Die Dateien, die für die obere schwarze Leiste notwendig sind, werden jetzt nicht mehr von files.natenom.com eingebunden sondern liegen jeweils auf der Subdomain der entsprechenden Website.

Google Fonts, Awesome-Font

Auf www.natenom.com habe ich die Einbindungen zu Gogle Fonts deaktiviert und versucht, die Fonts selbst zu hosten. Das funktioniert zwar noch nicht wie gewünscht, jedoch ist Google schonmal raus damit. Auch Bootstrapcdn wird nicht mehr einbedunden; die Awesome-Font nutze ich auf dieser Seite sowieso nicht.

Eingebette Videos

Alle eingebetteten Videos zu Vimeo im Blog und auch im Wiki habe ich durch simple Links ersetzt und werde das auch weiterhin so halten.

Im Blog werden Videos von Youtube mit einem einem speziellen Plugin so umgeschrieben, dass erst beim Klick auf Play Daten an Google gesendet werden.

Ziel

Mein Ziel: Ohne erkennbare Aufforderung durch einen Benutzer sollen keine externen Scripte/Inhalte nachladen lassen. Auf allen meinen Webseiten.

Ich denke das ist damit umgesetzt :)

Aus Datenschutzgründen möchte ich einige dieser Daten entweder gar nicht erst in der Datenbank haben oder nachträglich löschen.

Das sind alle Felder der Tabelle wp_comments:

comment_ID 
comment_post_ID 
comment_author 
comment_author_email 
comment_author_url 
comment_author_IP 
comment_date 
comment_date_gmt 
comment_content 
comment_karma 
comment_approved 
comment_agent 
comment_type 
comment_parent 
user_id 
comment_subscribe_optin 
comment_subscribe_optin_verified
comment_subscribe_optin_mailed

Bei den letzten dreien bin ich nicht sicher, ob sie in einer Standard-Installation von WordPress enthalten sind oder von einem installierten Plugin stammen.

Damit die IP gar nicht erst in der Datenbank landet, könnte man sich noch ein WordPress-Plugin installieren. Oder aber man löscht die Daten nach einem Zeitraum X direkt über SQL aus der Datenbank.

Ich habe mich für Letzeres entschieden. In meinem Wiki gibt es dazu eine Beschreibung, siehe hier.

Möchte man jedoch nur Artikel zu einer bestimmten Kategorie oder eines Tags „abonnieren“, dann ruft man diese Kategorie auf und fügt dann an die URL einfach ein feed an.

Aus:

</categories/android/>

wird somit:

</categories/android/feed>

Das funktioniert übrigens bei jedem WordPress-Blog und so ähnlich auch bei anderen Webdiensten:

• Bei reddit hängt man ein „.rss“ an die URL an.
• Bei GitHub hängt man z. B. für den Feed der commits ein „.atom“ an.

Weitere Informationen zu den verfügbaren Feeds in WordPress gibt es hier.

Einstellungen

Folgendes habe ich eingestellt:

• Enable Support: Beiträge -> aktiviert
• Header Label: „Inhaltsverzeichnis“ eingetragen, Voreinstellung ist „Table of Contents“
• Advanced:
  • Lowercase -> aktiviert
  • Exclude Headings:
    Damit im Inhaltsverzeichnis nicht auch der Abschnitt „Ähnliche Themen…“ auftauchen gibt es die Einstellung „Exclude Headings“.
    Hier trägt man die Zeichenkette „Ähnliche Themen…“ ein. Weitere Zeichenketten lassen sich hiermit einem Pipe-Zeichen „|“ getrennt eingeben.

Sichtbarkeit

In der Artikelübersicht ist das Inhaltsverzeichnis nicht zu sehen.

In Beiträgen ist es erst automatisch zu sehen, wenn es mehr als 4 Überschriften gibt.

Hier ein Beispiel von diesem Beitrag:

Es ist möglich, das Inhaltsverzeichnis manuell auszublenden.

Installieren

Das Plugin gibt es hier.

D. h. man benötigt ein Plugin, das diese erst einmal abschaltet und dann muss man noch ein bisschen am Theme basteln.

Eine detaillierte Anleitung dazu habe ich im Wiki hinterlegt, siehe hier.

Jetzt werden in meinem Blog keine Google-Sachen mehr eingebunden; es sei denn, dass z. B. ein Youtube-Video direkt eingebunden ist.

Daher habe ich nach aktuelleren Plugins mit dieser Funktionalität gesucht.

Was macht eine Lightbox?

Ohne ein Lightbox-Plugin werden Bilder immer als Datei im Browser geöffnet. Gerade bei vielen Bildern in einer Galerie ist das absolut unpraktisch. Gibt es hingegen ein Lightbox-Plugin, dann werden angeklickte Bilder in einem Overlay angezeigt, man kann sich durch alle Bilder durchklicken und bleibt trotzdem immer auf der aktuellen Seite.

Gefunden – Simple Lightbox

Das Plugin „Simple Lightbox“ hingegen ist aktuell und spielt sogar alle Bilder als Diashow ab; das lässt sich aber deaktivieren, siehe unten.

Hier zum Vergleich, das alte Overlay:

Und das neue Overlay:

Das in den Screenshots verwendete Bild ist übrigens hier zu finden.

Einstellungen des neuen Plugins

Pingbacks

Die Funktionalität für Pingbacks habe ich schon vor ca. einem Jahr komplett deaktiviert und den Zugriff auf die entsprechende php-Datei komplett deaktiviert. D. h. wenn jemand auf diesen Blog verlinkt und solch einen Pingback an meinen Blog schickt, dann bekomme ich davon nichts mit. Das stört mich nicht.

Ausserdem wurde dieses Pingback-Zeugs in der Vergangenheit immer wieder missbraucht.

Kommentare

Seit dem 11.12.2016 (fast ein Jahr) wurden gerade mal 14 echte Kommentare zu Blogbeiträgen verfasst. Da man fürs Kommentieren im meinem Blog aus Datenschutzgründen weder Email-Adresse noch Name oder Webseite angeben musste, kamen monatlich nur mehrere hundert Spamkommentare durch.

Weg damit

Deshalb habe ich heute die Kommentarfunktion in WordPress  deaktiviert und eingestellt, dass nur noch mit Account kommentiert werden kann. Denn man kann in WordPress Kommentare anscheinend nicht komplett für alle Artikel deaktivieren sondern nur die Funktion nach x Tagen der Veröffentlichung deaktivieren oder als Voreinstellung für neue Artikel deaktivieren. Eine 0 funktioniert hier nicht.

Auch habe ich Benachrichtigung anderer Blogs per Pingback deaktiviert, die ich in einem Beitrag verlinke.

Ein schöner Nebeneffekt ist der, dass ich wieder ein WordPress-Plugin deaktivieren kann, nämlich jenes, das in der Vergangenheit die Spamkommentare aussortiert hat – Antispam Bee.

Feedback zum Blog auf anderen Wegen

Wer eine Rückmeldung hat oder einen Hinweis auf einen Fehler, der kann mich gerne auf verschiedenen Wegen kontaktieren, siehe „Kontakt“ in der oberen schwarzen Leiste, die man auf allen meinen Webseiten findet. Alternativ kann man auf Twitter oder Diaspora kommentieren, dort werden automatisch alle neuen Beiträge verlinkt.

Ich lade hier im Blog gelegentlich Schnappschüsse hoch, die keinerlei Anspruch auf Qualität haben (müssen), aber die mich an verschiedene Dinge erinnern.

Bisher konnte ich diese aber immer erst von zuhause aus hochladen…

Da ist er wieder, der Datenschutz, der manches so kompliziert macht :)

Denn mir ist wichtig, dass bestimmte Metadaten aus Bildern entfernt werden. Außerdem soll das Bild auf maximal 2000 mal 2000 Pixel herunterskaliert werden. Auf einem Linux-System verwende ich dazu die beiden Tools imagemagick und exiftool. Den Rest erledigt ein kleines Shell-Script.

Dabei entsteht eine neue Datei mit einem zufälligen Dateinamen, die dann im Blog hochgeladen wird.

Das Script zum entfernen sensibler Metadaten gibt es übrigens in meinem Wiki, siehe hier. Ein Script, das alle Metadaten entfernt, gibt es hier.

Zuhause

Mein Ablauf zuhause beschränkt sich dank des Scripts auf:

• Rechtsklick auf eine Datei in Dolphin -> „2000×2000 Datei erstellen“

Dann kann ich das Bild im Blog hochladen.

Unterwegs

Unterwegs war mir das bisher nicht möglich, denn ich wollte nichts hochladen, das voll mit Metadaten ist und das auch noch unnötig groß ist.

Gestern habe ich mir ein paar Apps angeschaut, die mir das oben beschriebene auch ermöglich sollten.

Am besten für mich funktioniert die App Image Shrink Lite, denn diese kann sowohl das Bild verkleinern als auch alle Exif-Daten entfernen.

Für mich ist auch wichtig, dass es keine In-App Werbung gibt, das ist hier der Fall.

Dass die App wirklich macht, was sie verspricht, habe ich am PC mit exiftool überprüft.

Nach der Installation der App kann man einstellen, dass auch eine eigene Auflösung in einer Liste angeboten wird. In meinem Fall 2000×2000 Pixel.

Der Ablauf auf dem Android-Gerät ist jetzt:

• Datei in der Galerie-App auswählen -> Teilen -> Image Shrink Lite -> Größe auswählen.

Der neue Dateiname besteht aus einer zufälligen Ziffernfolge und die Datei landet in einem einstellbaren Verzeichnis auf dem Gerät.

Dann kann ich die Datei im Blog hochladen.

Passt :)

Man kann das Tool übrigens auch nutzen, bevor man Bilder z. B. bei Telegram, Whatsapp oder sonstwo vom Android-Gerät aus verschickt.

Das Plugin zeigt Datenschutz-gerechte Teilen-Links für verschiedene Netzwerke an.

Irgendwie fehlte mir die Funktionalität und siehe da es gibt ein weiteres Shariff-Plugin mit dem Namen „Shariff Wrapper“, siehe hier. Dieses scheint noch weiterentwickelt zu werden.

Bessere Übersicht

Fast alle Artikel auf den Übersichtsseiten haben jetzt einen „Weiterlesen“-Link. Das macht das Durchstöbern angenehmer, weil man nicht den ganzen Artikel herunterscrollen muss.

Übersichtliche Galerien

Bei Galerien bzw. Artikel mit vielen Bildern wurden bisher sehr große Vorschaubilder verwendet, sodass man direkt beim Aufruf einer Übersichtsseite mit solchen Artikeln sehr viele Daten herunterladen mussten. Auch musste man ewig nach unten scrollen, um zum nächsten Artikel zu kommen.

Hätte ich in solchen Artikeln nur einen Weiterlesen-Link eingefügt, dann wäre die Vielfältigkeit der Bilder verloren gegangen. Denn man hat mir berichtet, dass teilweise intelligente Menschen davon ausgingen, solche Artikel würden nur aus einem einzigen Bild bestehen (dem bis zum Weiterlesen-Link).

Mit der neuen Lösung der Minivorschaubilder sieht man direkt alle Bilder und kann sich durch diese durchklicken, indem man eines davon anklickt.

Mehr Artikelbilder (oberhalb der Überschrift)

Ist ein Bild in einem Artikel vorhanden, so wird dieses auch immer für die Überschrift verwendet. Das sieht insgesamt schöner aus.

Mehr Informationen zu Bildern

Teilweise sind die Bilder in den Gallerien jetzt auch mit Kommentaren versehen, zumindest wenn ich mich an den Ort erinnern kann oder es etwas dazu zu sagen gibt.

Diese werden entweder angezeigt, wenn man mit der Maus über das Bild fährt oder links oben wenn es in groß geöffnet ist.

Eigentlich gibt es die „Weiterlesen“-Funktion, um genau das zu vermeiden. Diese hatte ich jedoch nicht benutzt, weil im hier verwendeten Thema „Twenty Fourteen“ von Haus aus fehlerhaft ist. Man landet beim Anklicken des Links nicht exakt dort, wo der Link im Text gesetzt war, sondern etwas weiter unten. Das liegt an der oberen Leiste des Themas. Weiss man das nicht, dann ist man im besten Fall leicht irritiert. So ist die Funktion sinnlos.

Obwohl dieser „Bug“ schon seit 2014 im Thema existiert wurde er bis heute nicht behoben. Beim Bugreport ist aber eine Datei beigefügt, die zeigt, wie man das Problem lösen kann.

Das habe ich kürzlich getan und zusätzlich viele der „Weiterlesen“-Links bei großen Artikeln eingefügt.

Passt wieder :)

Da ich für solche Codebeispiele möglichst ohne zusätzliche Plugins auskommen möchte, die möglicherweise zusätzliche Lücken im Blog aufweisen könnten, nutze ich dafür nur noch das Pre-Tag, das man allerdings in der HTML-Text-Ansicht des WordPress Editors einfügen muss.

Das sieht dann z. B. so aus:

Code mit pre tag

Wird gerendert zu

Code mit pre tag

Möchte man auf diese Methode umsteigen und hat vorher z. B. das Plugin „Syntax Highlighter Evolved“ verwendet, so kann man das WordPress Plugin Search Regex nutzen, um die „alten“ Codebeispiele durch Pre-Tags zu ersetzen.

Dafür werden alle Vorkommen von [namedersprache] ersetzt durch

 und alle Vorkommen von [/namedersprache] durch 

Tipp: Benötigt man doppelte Striche in einem Codebeispiel, so sollte man sich noch diesen Artikel durchlesen.

Kopiert man anschließend eine solche Befehlszeile und fügt diese in ein Terminal ein, so funktionert der Befehl natürlich nicht mehr.
Das nervt und ist schon seit Jahren ein Problem in WordPress.

Die für mich einfachste Lösung, die ohne zusätzliche Plugins oder Änderungen am Code auskommt, ist die, statt -- den folgenden Code im Artikel zu verwenden:

<code>--</code>

Um nachträglich alle Vorkommen solcher Stellen zu finden und diese zu ersetzen, kann man das WordPress-Plugin namens Search Regex verwenden.

Habe die Lösung hier gefunden.

Habe eben in den Einstellungen von WP-Piwik für WordPress entdeckt, dass man das Plugin anweisen kann bei einem neuen Artikel in WordPress automatisch solche eine Notiz in Piwik anlegen zu lassen.

Die Einstellung findet sich unter „Einstellungen“ -> „WP-Piwik“ -> „Aktiviere Tracking“. Dort setzt man einen Haken bei „Notiz bei neuem Post“.

Und so sieht es dann in Piwik aus (rechts oben):

Seit irgend einem Update funktioniert das auch für mehrere Beiträge pro Tag :)
Werden allerdings mehrere Artikel an einem Tag veröffentlicht, so wird trotzdem nur die erste Notiz des Tages erstellt. Vielleicht bin ich aber auch nicht schlau genug, die folgenden Notizen des Tages zu finden :)

Unter „Einstellungen“ -> „Allgemein“ sind sowohl „WordPress-Adresse (URL)“ als auch „Website-Adresse (URL)“ auf http eingestellt und dadurch sollte eigentlich auch im gesamten Blog alles nur per HTTP eingebunden werden; dies hat in der Vergangenheit auch funktioniert.

Menschen, die auch einen Blog mit selbst signiertem Zertifikat betreiben, können das ja mal im eigenen Blog überprüfen.

Ich weiss nicht genau, ob das erst seit dem Update auf 4.2 so ist oder schon länger.

Alte Artikel korrigieren

Um die Bilder in allen bisherigen Beiträge von https auf http umzustellen, habe ich das WordPress Plugin Search Regex verwendet und damit die Strings „/wp-content/uploads/“ durch „/wp-content/uploads/“ ersetzen lassen:

Problem insgesamt beheben?

Eine Lösung für das Problem konnte ich bisher leider nicht finden und ein kostenpflichtiges SSL-Zertifikat ist mir viel zu teuer. Auch kenne ich mich mit WordPress nicht wirklich aus, um das Problem zu lokalisieren.

Deshalb begnüge ich mich zunächst damit, nach dem Erstellen eines Artikels mit dem oben genannten Plugin alle neuen URLs von Grafiken mit http zu ersetzen.

Melde mich, wenn es was Neues diesbezüglich gibt. Vielleicht weiss ja jemand, wie man das lösen kann :)

Update vom 11.05.2015:
Es gab in der Zwischenzeit zwei Sicherheitsupdates für WordPress und heute gerade ist mir aufgefallen, dass das Problem nicht mehr auftritt.

Eine gültige Email-Adresse vorausgesetzt erhält man kurz danach eine Email, in der ein Bestätigungslink enthalten ist.
Ruft man diesen auf, so ist das Opt-In abgeschlossen und zukünftig erhält man eine Email, sobald ein weiterer Kommentar zum betreffenden Artikel veröffentlicht wurde.

Weitere Informationen zum Plugin „Subscribe to Double-Opt-In Comments“ gibt es hier.

Die Idee für das Plugin habe ich irgendwann einmal in einem Blog gesehen, an den ich mich gerade leider nicht erinnern kann; falls es mir wieder einfällt, wird er natürlich verlinkt werden :)

Datensparsamkeit an sich mochte ich schon sehr lange, aber bezogen auf die eigenen Webseiten fing das erst so richtig an mit dem „Wir speichern nicht“-Siegel im Jahre 2010 bzw. schon wenige Monate zuvor.

Vor dieser Zeit wurden regelmäßig hier im Blog z. B. Musik von Jamendo über deren Widget eingebunden, Bilder und Videos von fremden Webseiten und mehr.

Datenschutz bedeutet zusätzliche Arbeit

Daten nicht zu speichern bzw. nicht zu erfassen bedeutet fast immer einen Mehraufwand.

Zum Beispiel bindet WordPress im aktuell verwendeten Thema Twentyfifteen bestimmte Webfonts von Google ein. Deshalb ist das Plugin Remove Google Fonts References installiert, um genau das zu unterbinden. Die schöne Schrift fehlt allerdings schon etwas.

Auch müssen Webserver aber auch Webanwendungen wie z. B. die beiden Wikis, Foren, etc. angepasst werden. Einige Anleitungen dazu gibt es hier.

Weitere Plugins im Blog, die helfen, den Datenschutzes zu ermöglichen:

• Shariff
• Remove IP
• WP-Benutzer-Avatar

Aktuelle Regelungen

Die aktuellen Regelungen für den Datenschutz für den Blog gibt es hier, für das Deutsch-sprachige Wiki hier und für das Englisch-sprachige Wiki hier.

Diese sind zusammengefasst:

• (Außer in ganz wenigen Ausnahmefällen) keine Inhalte von Fremdanbietern einbetten sondern nur verlinken bzw. wenn möglich selbst hosten – wie z. B. bei Videos, JavaScripts oder Webfonts.
• IP-Adressen entweder gar nicht oder nur anonymisiert speichern.
• Keinerlei Daten an Dritte weitergeben, nicht einmal die Hashwerte von Emails oder Ähnliches.
• Kommentare sollen ohne Angabe einer Email-Adresse möglich sein.

Konsequenzen der eigenen Regelungen

Daraus ergeben sich unter anderem die folgenden Konsequenzen z. B. für meinen Blog:

• In älteren Versionen von WP konnte man sich die Schriften noch relativ einfach selbst hosten, heute muss man wohl etwas mehr dafür ändern und kann sie nur deaktivieren. Deshalb verwendet das aktuell genutzte Thema hier im Blog nicht die benötigte Schriftart.
• Die Avatarfunktion per Gravatar in den Kommentaren ist nicht möglich; würde man hier Gravatar einsetzen, hätte jeder Benutzer, der seine Email-Adresse angibt, sein sonst auch verwendetes Avatar oder ein automatisch generiertes. Aktuell haben nur meine eigenen Kommentare ein Avatar.
• Spamfilter-Plugins, wie z. B. Akismet, die Kommentare auf einem zentralen Server auswerten, sind aktuell nicht nutzbar.
• Jeder Kommentar muss einzeln freigeschaltet werden. Könnte man die Email-Adresse speichern, dann wäre es möglich, bekannte Kommentatoren automatisch freischalten zu lassen.
• Viele nützliche WordPress-Plugins, die externe Dinge einbinden, lassen sich gar nicht nutzen.
  Ich kann jetzt kein bestimmtes beim Namen nennen, aber ich erinnere mich daran, dass ich vor geraumer Zeit einige solcher gefunden habe, sie aufgrund der eigenen Datenschutzbestimmungen jedoch leider nicht nutzen konnte.

Zweifel

Immer mal wieder kommt der Gedanke auf, wieso man sich den ganzen Aufwand macht, wenn es eigentlich fast allen Menschen völlig egal ist, was mit ihren Daten passiert.

Letztlich grenzt man sich damit selbst in den Möglichkeiten ein und erschwert es zudem, gefunden zu werden.

Es ergeben sich aus meiner Sicht die folgenden Argumente zur Frage, ob ich in der Zukunft die Datenschutzregelungen teilweise (oder komplett?) aufheben will/kann…, sowohl hier im Blog als auch auf den anderen eigenen Webseiten.

Argumente für die (teilweise) Aufhebung der Regelungen

• 99% der Menschen ist es allem Anschein nach egal, was mit ihren Daten passiert. Diejenigen, die zu dem anderen Prozent gehören, sind technisch in der Lage, sich dagegen selbst zur Wehr zu setzen und tun dies meistens auch mit Scriptblockern und anderen Tools.
• Kein „Wir speichern nicht„-Siegel:
  Wobei das Siegel letztlich nie ein Garant dafür war, dass nicht doch gespeichert wurde, da es für die Aufnahme nur notwendig ist, die richtigen Antworten zu liefern.
• Weniger Aufwand und mehr Möglichkeiten (siehe oben).
• Eventueller Umzug zu einem günstigen, reinen Hostinganbieter wäre möglich; denn dort hat man keinen Einfluss auf das Logging, soweit mir bekannt.

Argumente für die Beibehaltung der Regelungen

• Meine Überzeugung – es „fühlt“ sich halt richtig an…
• Einige der schon lange selbst auferlegten Regeln werden möglicherweise bereits vom Gesetz gefordert; hier müsste ich erst einmal recherchieren, was genau erlaubt ist und was nicht.

Oo.

In diesem Sinne…

Es wäre schön, wenn der eine oder andere seine Gedanken dazu als Kommentar anhängen könnte.

Danke.