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

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

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

Last für den Webserver

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

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

Ergebnis:

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

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

Skaliert nicht gut

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

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

Lösung?

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

Bisher hat es nicht funktioniert

Als ich mich das letzte Mal damit beschäftigte, fand ich nur gewisse Variablennamen und diese haben nicht dazu geführt, dass Bilder für Twitter Cards und/oder Open Graph hinterlegt wurden. Ich kann heute nicht mehr nachvollziehen, was ich damals gefunden hatte, die entsprechende Datei gibt es im aktuellen Theme gar nicht mehr. Beide damals gefundenen Variablen tun daher auch weiterhin nicht. Ich vermute, dass ich damals “überarbeitet” war und den Wald vor lauter Bäumen nicht mehr gesehen hatte.

So funktioniert es

Heute hatte ich mehr Glück: Das Docsy-Theme verwendet keine eigene Implementierung dieser beiden Dinge sondern die interne von Hugo. In der Datei themes/docsy/layouts/partials/head.html steht in Zeile 26 bis 29:

{{ template "_internal/opengraph.html" . -}}
{{ template "_internal/schema.html" . -}}
{{ template "_internal/twitter_cards.html" . -}}

Die Beschreibungen für diese internen Templates gibt es in der offiziellen Dokumentation, hier für Twitter Cards und hier für Open Graph.

Jetzt gibt es auch ein Vorschaubild, wenn man eine Wiki-Seite auf Mastodon, Twitter, Facebook oder einer anderen Website teilt.

Prioritäten

Es funktioniert also genau so, wie auch in meinem Blog (bzw. im Blog wurde es mal vom Theme-Entwickler an das Verfahren in Hugo internals angepasst):

• Priorität 1 (höchste): Es wird das erste Bild verwendet, das im Front Matter im Parameter images definiert wird. Dabei wird das so angegebene Bild aber relativ zum Root-Verzeichnis der Website eingebunden und nicht relativ zum Page Bundle.
• Priorität 2: Es wird das erste Bild verwendet, das im Namen den Substring feature, cover oder thumbnail enthält. Es können somit Bilder im aktuellen Page Bundle eingebunden werden und diese werden auch richtig verlinkt.
• Priorität 3: Es wird das erste Bild verwendet, das in der Konfiguration der Website im Parameter images angegeben wird. (bei mir im Wiki ist dies aktuell images = ["/images/natenom-avatar.png"].

Ich verwende immer Priorität 2.

Ergebnis

So sieht das dann z. B. auf Twitter aus:

Beschreibung nicht automatisch

Im Gegensatz zum Theme, das ich im Blog verwende, wird im Wiki mit dem Theme Docsy immer die Beschreibung (description) “Natenoms Wiki” eingefügt, wenn keine solche im Front Matter definiert wurde. Im Blog wird in einem solchen Fall ein Ausschnitt (die ersten x Zeichen eines Blogbeitrags) verwendet.

Im Wiki muss ich das daher im Front Matter angeben, z. B. für den Bereich Müllsammeln mit:

---
title: Müll sammeln
tags:
- Plogging
- Müll
- Pforzheim
- Enzkreis
- Müllsammeln
- Neuhausen
import_status: done
description: "Ich sammle Müll. Sowohl in kleinem Rahmen zwischendurch als auch in etwas größeren Rahmen mit [Fahrrad](/docs/fahrrad/meine_fahrraeder/mtb) und [Fahrradanhänger](/docs/fahrrad/fahrradanhaenger). Die 'kleine' Ausrüstung (Müllgreifer und Mülltüten) habe ich fast immer dabei, wenn ich mit dem [Fahrrad](/docs/fahrrad) unterwegs bin."
---

Diese Beschreibung wird auch automatisch auf der Seite oberhalb der Tags angezeigt. Dabei freut es mich sehr, dass man offenbar auch Shortcodes innerhalb des Front Matters benutzen kann, sodass ich hier einfach die ersten Sätze der Seite in die Beschreibung verschieben kann.

Die Verwendung von <!--more--> funktioniert leider nicht. Damit kann man in anderen Themes definieren, dass der Bereich vom Anfang des Beitrags/der Seite bis zu dieser Zeichenkette als Beschreibung verwendet werden soll.

Hier in der Dokumentation von Hugo ist das mit der Page Summery erläutert.

So sieht es jetzt mit einer Beschreibung aus:

Die Beschreibung wird auch, und das wusste ich bisher nicht, in der Liste der Unterseiten eines Bereichs eingefügt. Das gefällt mir.

Zugriff auf Informationen von Git

Das Theme docsy, das ich für mein neues Wiki verwende, zeigt auf Wunsch und mit Hilfe von Git Zusatzinformationen an.

Zur Aktivierung trägt man die folgende Zeile in den Hauptbereich der Konfiguration in der config.toml ein:

enableGitInfo = true

Ich werde das für meinen Blog erst aktivieren, wenn es ein öffentliches Repo für mein Wiki gibt.

Letzte Bearbeitung und Beschreibung

Wenn Git aktiviert ist, wird automatisch unter jeder Seite das Datum der letzten Bearbeitung angezeigt, dazu die Commit-ID und die Commit-Beschreibung.

Links zum Git-Repo

Dann trägt man noch im Bereich [params] in der config.toml die Variable github_repo = "https://github.com/<user>/<repo>" ein.

Dann werden auch Links generiert, die auf den letzten Commit einer Seite verlinken.

Feeds

Man kann noch den Atom Feed für die Website aktivieren mit:

[outputs]
section = [ "HTML", "RSS" ]

Druckansicht

Es gibt im Theme auch die Möglichkeit, eine Druckansicht hinzufügen (rechts oben), die dann z. B. den gesamten Hauptbereich Fahrrad in einer einzigen Seite anzeigt. Das werde ich vielleicht später aktivieren.

Dazu muss man in der config.toml noch im Bereich outputs hinzufügen:

[outputs]
section = [ "HTML", "RSS", "print" ]

Dokumentation

Startseite meines neuen Wikis

Ich kann ja nix bei so Websachen, das weiß man ja. Deshalb versuche ich immer, das irgendwie zu nutzen, war mir das System vorgibt, wie zum Beispiel die Möglichkeit des Themes Docsy, ein Cover auf der Startseite zu nutzen. Dessen Beschreibung gibt es hier.

Die Themenbereiche darunter wurden mit dem Shortcode Card Pane erstellt. Hier die Dokumentation dazu.

Dafür ist die Datei content/de/_index.md zuständig. Dieser Inhalt wird immer angezeigt, wenn man auf das Document Root der Webseite geht (also /).

So sieht die Startseite aktuell aus:

Twitter Cards und Open Graph

Über das Partial docsy/assets/vendor/bootstrap/site/layouts/partials/social.html werden Twitter Cards und Open Graph Metadaten im Docsy-Theme in eine Seite eingefügt. Dort sind auch twitter:image und og:image enthalten, z. B. für twitter:image:

<meta name="twitter:image" content="{{ if .IsHome }}{{ .Site.Params.social_image_path | absURL }}{{ else }}{{ .Site.Params.social_logo_path | absURL }}{{ end }}">

Für die Startseite des Wikis wird somit das Logo aus dem Bereich params in der Variable social_image_path verwendet und für alle anderen Seiten das aus der Variable social_logo_pathim Front Matter der einzelnen Seite. Glaube ich. Es hat leider nicht funktioniert.

Weiterleitungen

Damit man auch über das alte Wiki noch zu den Inhalten des neuen Wikis kommt, habe ich alles entsprechend weitergeleitet.

Ich habe jeden Hauptbereich des alten wikis einzeln weitergeleitet mit:

rewrite ^/android(.*)$ https://wiki.natenom.de/docs/android$1 redirect;

Somit kann ich links das Navigationsmenü im alten Wiki stehen lassen und man kommt auch bei Unterseiten im neuen Wiki an. Und auch Menschen, die auf irgend einer fremden Website auf einen Links zum alten Wiki klicken, landen im neuen Wiki.

rewrite ^/verkehr/projekte/radfahrer_faq(.*)$ https://wiki.natenom.de/docs/fahrrad/faq$1 redirect;
rewrite ^/verkehr(.*)$ https://wiki.natenom.de/docs/mobilitaet$1 redirect;

Informationen für Menschen – So wichtig

Für diejenigen Menschen, die in der Seitennavigation (links) im neuen Wiki die Themen vermissen, die nicht im neuen Wiki sind, habe ich für diese dort trotzdem Einträge erstellt. Klickt man diese an, bekommt man die Information, dass sie noch im alten Wiki zu finden sind.

Das betrifft die Bereiche Minecraft, Mumble und Sauerbraten.

Auf der Startseite des neuen Wikis sind diese Bereiche natürlich auch verlinkt.

Altes Wiki – “keine Änderungen”

Das alte Wiki bleibt erst einmal so bestehen. Mit der Zeit werde ich dann vermutlich die weitergeleiteten Bereiche in der Seitennavigation ausblenden und vielleicht sogar ganz entfernen. Natürlich mit vorherigem Backup.

Dann könnte ich irgendwann einmal die alten Bereiche in eine statische Seite umwandeln und dann DokuWiki selbst entfernen. Dann bräuchte ich kein PHP mehr auf meinem Server.

Todo

Von den Todos aus dem letzten Blogbeitrag habe ich das Favicon umgesetzt. Wie das geht, steht hier.

Das mit der Nummerierung der Überschriften habe ich angefangen, aber es funktioniert bisher leider noch nicht.

Hinzu kommende Aufgaben:

• Alle Verlinkungen im Blog auf die umgezogenen Bereiche aufs neue Wiki umschreiben. Es gibt zwar Weiterleitungen, aber auf die will ich mich nicht dauerhaft verlassen.
• Bilder für Twitter Cards und Open Graph siehe oben.
• Feed mit Änderungsdatum aus Git füttern.

Passt 🙂

Das passt so erst einmal für mich. Ich hatte damit extrem viel Arbeit in den letzten Tagen (und Wochen?) und bin froh, dass es jetzt fertig ist.

Und so sieht mein neues Wiki jetzt aus:

Artikelbilder

Vor dem Update

Bisher wurde als Beitragsbild das erste Bild in der Liste der Bilder der Variable images: im Front Matter verwendet:

images:
  - relativer-pfad/bild.jpg

# Ergebnis: /blogbeitrag-titel/relativer-pfad/bild.jpg

Oder:

images:
  - /absoluter-pfad/bild.jpg

# Ergebnis: /absoluter-pfad/bild.jpg

Nach dem Update

Seit dem Update hat sich das verändert. Relative Pfade sind nicht mehr relativ zum aktuellen Beitrag bzw. Page Bundle sondern immer relativ zum static-Verzeichnis der Website:

images:
  - relativer-pfad/bild.jpg

# Ergebnis: /relativer-pfad/bild.jpg

Dann gibt es noch die Neuerungen, dass fürs Artikelbild automatisch das erste gefundene Bild eines Page Bundles verwendet wird, wenn folgender Dateiname passt (in dieser Reihenfolge) UND KEINE Variable images im Front Matter definiert ist:

• *feature*
• *cover*
• *thumbnail*

Hierbei sollte ein Bild verwendet werden, das in den Breiten von 180 Pixel und um 500 Pixel noch gut aussieht, da die Artikelbilder in der normalen Ansicht sehr klein und in der mobilen Ansicht sehr groß angezeigt werden.

Vielleicht könnte man hier noch einen Feature Request stellen, damit für das verwendete Bild automatisch die benötigten Größen von Hugo generiert werden. Technisch ist das möglich.

Twitter Card und Open Graph

Für die Twitter Card und den Open Graph wird immer das Artikelbild verwendet. Gibt es kein Artikelbild, dann nutzen Twitter Card und Open Graph das in der config.toml eingestellte Bild der Variable logo=. Vor dem Update gab es in letzterem Fall gar kein Bild.

Die Lösung mit dem logo finde ich nicht gut. Denn normalerweise wird das Logo auf der Website oben nur in 30x30 Pixeln dargestellt, auf Twitter oder anderen Social-Media-Plattformen aber mit über 500 Pixeln. Auch hier wäre es meiner Ansicht nach möglich, automatisch die Größenvarianten des Logos von Hugo erstellen zu lassen.

Somit wurde die Handhabung im Theme an die Funktionsweise in Hugo selbst angeglichen.