Blog

Datenschutzkonformes iframe

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

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

Hier ein Beispiel:

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

So sieht das dann aus:

Seiten im Suchindex verstecken

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

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

Ähnliche Beiträge

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

Oben vorher, unten nachher:

Unter der Haube

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

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

Wiki

Navigationsleiste

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

Vorher und nachher:

Interaktive Navigation

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

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

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

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

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

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

Shortcodes

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

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

Suchfunktion

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

Kein HTML-Quelltext mehr

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

Ich habe auch viele solcher Anleitungen geschrieben, die vielfach genutzt wurden. Und teilweise habe ich dann auch auf das Problem hingewiesen.

Um diesen Warnhinweis zu vereinheitlichen, habe ich einen Shortcode für Hugo erstellt, den ich in diesem Blog und auch in meinem neuen Wiki nutzen kann. Diesen werde ich in Zukunft immer in Blogbeiträge und Wikiseiten einfügen, sobald es Shell Kommandos gibt.

Wieso eigentlich nicht?

Wie sollte man Shell Kommandos nicht direkt in eine Shell einfügen und ausführen? Man kann doch sehen, was man markiert hat und was in der Shell ausgeführt werden wird?

Nein.

Ich habe das bisher noch nicht in freier Wildbahn gesehen aber es ist möglich, dass man innerhalb eines Code-Blocks z. B. via CSS, Teile versteckt. Diese werden jedoch beim Markieren mit ausgewählt und kopiert. Fügt man das direkt in die Shell ein und drückt Enter, werden die “unsichtbaren” Shell Kommandos auch ausgeführt. Es gibt vielleicht aber auch noch ältere Terminal-Emulatoren, die direkt die Kommandos ausführen.

Es gibt aber auch Möglichkeiten, das notwendige Drücken von Enter durch den Benutzer mit Steuerzeichen zu überwinden. Der Terminal-Emulator Konsole (von KDE) erkennt beim Einfügen solche Zeichen und fragt nach, ob sie herausgefiltert werden sollen. Xterm zeigt alle Kommandos an und erwartet eine Eingabe vom Benutzer. Wie sich andere Terminal-Emulatoren verhalten, habe ich nicht getestet. Ich habe aber die Rückmeldung bekommen, dass es welche gibt, die dann direkt ausführen.

Wenn auf einer Plattform normale Benutzer gar keinen CSS-Code in Beiträge einarbeiten können, sollte das auch relativ sicher sein, es sei denn, es gibt eine Sicherheitslücke.

Im Zweifel sollte man sich also nicht darauf verlassen, dass der Terminal-Emulator sicher reagiert und die folgende Methode verwenden.

Obwohl das ein ziemlich altes Problem ist, scheint es nicht bei jedem bekannt zu sein, der solchen Anleitungen folgt und die kopierten Kommandos direkt ausführt.

Und wie macht man das richtig?

Die einfachste Möglichkeit, die ich auch bevorzuge, ist ein Texteditor: Bevor man von irgendwelchen Websites Shell Kommandos nutzt, fügt man diese zuerst in einen lokalen Texteditor ein, prüft, ob alles stimmt, markiert kopiert dann die Zeile im Texteditor und nutze diese zum Einfügen in die Shell.

Beispiel

So sieht der Shortcode in Aktion aus, der auch ein Beispiel zum Kopieren enthält (anklicken zum Öffnen):

Immer prüfen

Auch bei vertrauenswürdigen Websites oder Beiträgen sollte man Shell Kommandos immer prüfen, denn es könnte sein, dass Inhalt von Dritten verändert wurden. Auch hier im Blog oder im Wiki.

Quelltext für den Shortcode

HTML

Und das ist der Quelltext für den Shortcode

<div class="shortcode-codewarning">
    <details>
    <summary class="shortcode-codewarning summary">Vorsicht beim Ausführen von Shellkommandos via Copy & Paste</summary>
        <div class="shortcode-codewarning content"><p>
        Man sollte Shellkommandos aus Anleitungen, die in einem Browser angezeigt werden, grundsätzlich nicht einfach ungeprüft in die Shell einfügen und ausführen.</p>
        <p>Denn es ist möglich, Teile des Codes z. B. via CSS zu verstecken. Diese Teile werden aber trotzdem kopiert und landen auch in der Shell, wo sie ausgeführt werden.</p>
        <p>Besser ist es, die Kommandos erst in einen lokalen Texteditor einzufügen und dort zu prüfen, bevor man die ausführt.<p>
        <p>Kopiere doch mal dieses Beispiel und füge es – in die Shell (!NEIN) – in einen Editor ein:</p>
        <p><code>echo "Befehl 1"; <span class="shortcode-codewarning hidden">echo "Befehl 2. Im Browser unsichtbar, da font-size per CSS auf 0 gestellt wurde. Hier könnte z. B. die Festplatte gelöscht oder andere Dummheiten gemacht werden."; </span>echo "Befehl 3"</code></p></div>
    </details>
</div>

SCSS

Und hier das dazugehörige SCSS:

/* Shortcode Codewarning */
.shortcode-codewarning {
	margin-bottom: 1em;
	.hidden {
		font-size:0;
	}
	.summary {
		border-radius: 4px 4px 4px 4px;
		color: #fff;
		font-weight: 700;
		padding-left: 1em;
		margin-bottom: 0px;
		background: rgba(198, 65, 61, 0.8);
	}
	.content {
		border-radius: 4px 4px 4px 4px;
		color: #666;
		display: block;
		font-size: 1em;
		margin-bottom: 0;
		margin-top: 0;
		padding: .6em 1em;
		background: #d9d2d2;
	}
}

Einbindung in Hugo

Um den Shortcode in Hugo einzubinden, speichert man den HTML Teil als codewarning.html nach layouts/shortcodes ab, den CSS-Teil entsprechend im Theme, was sehr unterschiedlich ist.

Um den Shortcode dann innerhalb von Blogbeiträgen einzufügen, schreibt man an entsprechender Stelle:

{{< codewarning >}}

Ist mir bisher noch nicht aufgefallen, ist aber logisch. Das liegt daran, dass rsync so eingestellt ist, dass Dateien, die lokal nicht mehr vorhanden sind, auch online gelöscht werden.

Und immer dann, wenn ich etwas am CSS ändere, wird das wohl zuerst gelöscht, bevor die neue Variante hochgeladen wird. D. h. wenn ich die eine Seite des Blogs genau in dem Moment aufrufe, als dort noch auf das alte CSS verwiesen wird, das aber bereits gelöscht wurde, dann sieht das so aus:

Habe rsync jetzt so eingestellt, dass lokal nicht mehr vorhandene Dateien erst gelöscht werden, wenn alle Dateien hochgeladen wurden und nicht zwischendurch, wie per Voreinstellung.

Aus dem Parameter --delete wird --delete-delay.

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.

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.

Wir konnten die Inhalte mehrerer einzelner Seiten in weniger Seiten zusammenführen und so eine bessere Übersicht schaffen.

Vor allem wurde jedoch am Aussehen auf der Spenden-Seite einiges geändert. Vrifox hat das mittels CSS verschönert. Hier sieht man jetzt auch direkt die aktuelle und komprimiertere Spendenübersicht und die Anzeige ist schön animiert. Und das nur mit CSS.

So sah es vorher aus:

Und so sieht es jetzt aus:

Als nächstes werden wir, bzw. Vrifox, ein dunkles Thema für meine Startseite umsetzen.

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:

It is written in Perl.

New in this release:

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

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

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

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

Die dritte Spalte rechts wurde entfernt, dadurch ist die Inhaltsspalte deutlich breiter und auch so eingestellt, dass Artikel deren volle Breite nutzen können.

Die Änderungen am CSS sind (Quelle):

.site-content .entry-header,
.site-content .entry-content,
.site-content .entry-summary,
.site-content .entry-meta,
.page-content,
.post-navigation,
.image-navigation,
.comments-area {
max-width: 80%;
}

Die Inspiration dafür kam von dieser Seite.

In der linken Spalte gibt es nur noch die Widgets für die Kategorien und die Schlagwörter.

Viele Verlinkungen aus den Seitenleisten sind nun oben im Menü zu finden – welches immer zu sehen ist. Die entfernten Widgets sind im Footer zu finden.

Somit kann man sich (so die Überlegung) besser auf den Inhalt konzentrieren und muss nicht immer wieder an denselben Informationen vorbei.

Außerdem ist das Menü auf kleinen Displays viel besser zu erreichen als die Widgets.

Hintergrund und Schatten

Der Hintergrund ist nun etwas winterlicher, auch wenn es bisher noch keinen Schnee bei mir zuhause gab. Das Foto stammt von Januar 2013 und das Original gibt es hier.

Außerdem gibt es jetzt um die Seite herum einen von KDE SC abgekupferten, bläulichen Schatten.

Das dazu gehörige CSS ist:

div#page.hfeed.site {
box-shadow: 0px 0px 15px 5px #9AD3F2;
}

Das obere Menü hat keinen Schatten; soll dieser auch noch hinzugefügt werden, so benutzt man noch den folgenden CSS-Code:

div.header-main {
box-shadow: 0px 0px 2px 2px #9AD3F2;
}

\o/

Vielleicht wird der ganze Footer in Zukunft auch noch entfernt werden, mal sehen.

Passt :)

Hier noch ein Screenshot, falls sich das Design in Zukunft wieder ändern wird:

Mal wieder…

Habe jedoch heute morgen das Thema mal wieder ausprobiert und wieder einmal begeistert festgestellt, wie schön es z. B. auf mobilen Geräten aussieht:

Und auch sonst hat es ein paar Dinge, die mir sehr gut gefallen. Was mir jedoch gar nicht gefält sind das verwendete tiefe Schwarz und die Linksausrichtung des Themas.

Mit wenig Aufwand lässt sich jedoch beides ändern :)

Ausrichtung

Damit der Blog zentriert dargestellt wird, muss man nur das CSS geringfügig ändern. Damit dieses Änderung nicht bei jedem Update überschrieben wird, erstellt man ein Child-Theme. Wie das funktioniert, steht hier.

Dann fügt man im Child-Theme die folgende Zeile in die Datei  style.css ein (die von hier stammt):

.site {
margin:0 auto;
}

Farben anpassen

Für die Änderungen der Farben wurde das WordPress-Plugin „Fourteen Colors“ verwendet, siehe hier.

Die Werte sind:

• Accent Color: #286bc1
• Contrast Color: #eaeaea
• Hintergrundfarbe: #eaeaea

Wer noch mehr Einflussmöglichkeiten benötigt, sollte sich das Plugin „Styles: Twentyfourteen“ ansehen.

Alternative

Man kann natürlich auch die entsprechenden Stellen für die Farben und die Ausrichtigung in die CSS-Datei des Child-Themes einfügen oder die komplette Datei übernehmen und benötigt kein zusätzliches Plugin. Dann muss man aber bei jedem Update selbst überprüfen, ob sich etwas an der Datei geändert hat.

Unterschiede zwischen Twentyfourteen, dem Child-Theme und vorher

So sah der Blog gestern noch aus mit dem Yoko-Thema:

Hier mit dem Original von Twentyfourteen:

Und hier mit den Anpassungen:

Hinweise

Da Twentyfourteen von sich aus eine Seitennavigation am unteren Rand anzeigt, konnte das Plugin WP-Pagenavi entfernt werden.

Um die Google-Fonts zu deaktivieren, die das Thema einbinden möchte, gibt es das Plugin „Disable Googlefonts„.

\o/

Passt :)

Gerade bei vielen Abschnitten eines Dokuments fällt es schwer, zu erkennen, ob es sich nun um einen Unterpunkt (z. B. 1.1) oder einen neuen Abschnitt (z. B. 2) handelt. Die Struktur des Dokuments ist nicht wirklich ersichtlich.

Um nummerierte Überschriften zu erhalten, gibt es zwei Möglichkeiten:

• Man verwendet das veraltete Plugin NumberedHeadings und muss jede Überschrift manuell anpassen. Das ist zu aufwändig und fällt weg.
• Man verwendet CSS und überlässt dem Browser die Arbeit; ein entsprechendes CSS-Konstruk existiert bereits.

Das Problem mit dem CSS-Konstrukt ist jedoch, dass es aus dem Jahr 2008 stammt und auf das damalige Standard-Template ausgelegt ist. Mit Monobook funktioniert es so nicht. In der Beschreibung steht zwar, man muss bestimmte Dinge ersetzen, beim ersten Versuch vor einiger Zeit bin ich jedoch aufgrund mangelnder Kenntnisse gescheitert und habe den Ansatz wieder vergessen.

Bei einem neuen Versuch heute habe ich es aber doch geschafft und nun sind die Überschriften im Wiki nummeriert, was die Übersicht erhöht :)
Habe den angepassten CSS-Code im Wiki hinterlegt unter https://wikiarchiv.natenom.de/ueber/nummerierte_ueberschriften.

Hier der Eindruck ohne (links) und mit Nummerierung (rechts):

[][1]

Werde das zur Sicherheit auch noch durch einen Spezi prüfen lassen, falls ich in Unkenntnis etwas verpfuscht haben sollte.

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

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

    

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

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

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

    

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