Blog

“Serien” entfernt

Es gibt in Hugo die Möglichkeit, sogenannte “Serien” zu erstellen, und Blogbeiträge diesen zuzuordnen. Das hatte ich z. B. für ältere Reiseberichte und für Dokumentation von Radwegen gemacht.

Das habe ich wieder deaktiviert und nutze stattdessen wieder nur die Kategorien für diese Dinge.

Der Vorteil ist, dass die kleine Box in der Seitenleiste jetzt wieder direkt die Kategorien anzeigt.

Vorher:

Nachher:

Kategorie ‘Musik’ entfernt

Ich habe fast alle Beiträge der Kategorie ‘Musik’ entfernt und die wenigen verbliebenen mit Musik-Kontext der Kategorie Allgemein bzw. Linux zugeführt.

Das waren durchweg nur sehr alte Beiträge, die nicht mehr von Interesse sein dürften. Insgesamt waren es um 180 Beiträge.

Vielleicht werde ich in Zukunft noch Beiträge weiterer Kategorien oder Tags entfernen, die schon alt und nicht mehr relevant für den Blog sind.

Urls zu Kategorien und Tags angepasst

Nach dem Umzug von WordPress nach Hugo Anfang 2022 hatte ich Weiterleitungen eingerichtet für:

• /tag/… nach /tags/…
• /category/… nach /categories/…

Bestehende Links auf meinen Websites habe ich entsprechend umgeschrieben.

Irgendwann in der Zukunft werde ich diese Weiterleitungen deaktivieren, was einen potenziellen Umzug wieder einfacher machen wird. Ordentliche Suchmaschinen schauen da eh nicht mehr nach, weil das schon seit Anfang 2022 mit 301 (Moved Permanently) weitergeleitet wird.

Relative Feed über das Feed-Icon

Bisher war es im Blog so, dass beim Feed-Icon immer der Hauptfeed angezeigt wurde. Das habe ich nun auf den Default-Wert des Themes eingestellt, sodass immer der aktuelle Feed angezeigt wird. Befindet man sich z. B. derzeit in der Übersicht der Kategorie mobilität, dann enthält das Feed-Icon die URL https://natenom.de/categories/mobilit%C3%A4t/index.xml. Dieser Feed enthält nur die Kategorie Mobilität.

So hat man nun einfachen Zugriff auf die Feeds der verschiedenen Kategorien und Tags (siehe vorheriger Abschnitt).

Das sind die Feeds, die es in meinem Blog gibt:

• /pages/index.xml
• /categories/index.xml
• /categories/<kategoriename>/index.xml
• /tags/index.xml
• /tags/<tagname>/index.xml
• /posts/index.xml
• /archiv/index.xml
• /archiv/<jahr>/index.xml

Blogroll

Es gibt jetzt einen Blogroll, also eine Liste von anderen Blogs, die ich gut finde und/oder selbst lese. Da ist aktuell noch nicht viel drin, aber ich werde da mit der Zeit Dinge hinzufügen.

Wenn jemand Vorschläge dafür hat, gerne melden.

Fast kein Github mehr

Ich habe meine Repos von Github schon vor mehreren Wochen gelöscht und alle Verlinkungen darauf im Blog und im Wiki entfernt.

Ich nutze Github nicht mehr für eigene Projekte und alles dort war veraltet und wurde nicht mehr gepflegt. Zum Erstellen von Issues für diverse Projekte werde ich den Account aber weiterhin behalten.

Falls es jemanden gibt, der irgendwas von den alten Repos haben will, so könnte ich die Git-Archive irgendwann mal auf meinen eigenen Server hochladen. Das halte ich aber für sehr unwahrscheinlich und bisher gab es keine Anfragen.

Zukünftige Abschaltung des archivierten Wikis

Da ich die alten Domains abgeschaltet hatte, will ich auch das alte, archivierte Wiki auf wikiarchiv.natenom.de in ferner Zukunft abschalten. Ich habe keinen konkreten Zeitplan, aber irgendwann soll es mal weg.

Dort liegt aktuell nur noch die mittlerweile in einigen Bereichen veraltete Mumble-Dokumentation, an der ich über viele Jahre geschrieben hatte und noch ein bisschen Dokumentation zu Minecraft und den Servern, die ich früher betrieben hatte.

Falls irgend jemand glaubt, dass die veraltete Mumble-Dokumentation noch Relevanz haben könnte und das statische HTML hosten möchte, so kann ich das demjenigen Menschen überlassen.

Jedoch waren der Einfachheit halber bis heute auch die migrierten Bereiche weiterhin im alten Wiki auf Dateiebene hinterlegt, aber wegen der Weiterleitungen nicht abrufbar.

Die Weiterleitungen führten für migrierte Inhalte via HTTP Status Code 301 zum neuen Wiki.

Heute war es endlich an der Zeit, die alten Inhalte aus dem archivierten, alten Wiki restlos zu löschen.

Damit ich auch in Zukunft noch nachlesen kann, wie ich das gemacht hatte oder falls jemand das selbst für ein eigenes Wiki machen möchte, habe ich hier die Anleitung dazu bereit gestellt.

Überlegungen zum Entfernen der migrierten Bereiche aus dem archivierten Wiki

Ein paar Gedanken dazu, ob es sinnvoll ist, die migrierten Bereiche zu entfernen:

• Im Seitenindex im Wiki und in der Sitemap fehlen die migrierten URLs. Diese wurden aber sowieso schon seit Monaten mit 301 weitergeleitet aufs neue Wiki und bleiben weiterhin via nginx-Konfiguration im Webserver, sodass auch alte Verlinkungen auf migrierte Inhalte weiterhin richtig zum neuen Wiki auflösen.
• Man kann jetzt nur nicht mehr im alten Wiki stöbern sondern muss dazu ins neue Wiki.
• Für Suchmaschinen ist es vermutlich besser, weil die meisten migrierten Inhalte nicht mehr nur aus Weiterleitungen bestehen. Zudem gucken Suchmaschinen dank 301 sowieso seit Langem nur noch im neuen Wiki.

Wenn jemand hierzu Gedanken hat, bitte anschreiben. 😊

Was wird in dieser Anleitung gemacht?

Auf dem lokalen Rechner wird:

• der Webserver Nginx installiert.
• eine temporäre lokale Domain eingerichtet und verwendet.
• das Wiki konfiguriert.
• das Wiki via wget heruntergeladen und das Ergebnis modifiziert.

Schließlich wird das Ergebnis auf den öffentlichen Webserver (wiki.natenom.de) hochgeladen und bleibt dort auf ewig liegen und wird nie wieder angetastet.

Vorbereitungen

Als Basis habe ich meine damalige Dokumentation verwendet, die beschreibt, wie man ein DokuWiki in eine statische Website umwandelt, siehe hier.

Installation der benötigen Debian-Pakete

apt install nginx php8.1 php-fpm php8.1-xml

Lokale Domain fürs Wiki

Man kann zwar auch die richtige Domain verwenden und diese auf den lokal Rechner verweisen lassen aber das birgt Probleme, falls man z. B. HSTS verwendet. Dann wird man jedes Mal auf https weitergeleitet, was hier in dieser Anleitung aber nicht eingerichtet wird.

Die lokale Domain habe ich einfach mal auf wiki.natenom.me festgelegt und verwende sie hier in allen Shell-Kommandos entsprechend.

In die Datei /etc/hosts trägt man dazu ein:

127.0.0.1 wiki.natenom.me

Lokalen Webserver konfigurieren

Hier die Konfiguration für den lokalen Nginx-Server:

 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

server {
    listen 80;

    server_name wiki.natenom.me;
    autoindex off;
    index index.html index.htm index.php doku.php;
    root /home/wiki.natenom.de/htdocs/;

    rewrite ^/_media/favicon.ico$ /_cdn/images/natenom_favicon_16x16.ico;
    rewrite ^/_media/wiki/apple-touch-icon.png$ /_cdn/images/natenom_favicon_512x512.png;
    rewrite ^/favicon.png$ /_cdn/images/natenom_favicon_16x16.png;

    location / {
        try_files $uri $uri/ @dokuwiki;
    }

    location ~ ^/lib.*\.(gif|png|ico|jpg)$ {
        expires 96h;
    }

    location = /robots.txt  { access_log off; log_not_found off; }
    location ~ /\.          { access_log off; log_not_found off; deny all; }
    location ~ ~$           { access_log off; log_not_found off; deny all; }

    location @dokuwiki {
        rewrite ^/sitemap.xml.gz /?do=sitemap;
        rewrite ^/_media/(.*) /lib/exe/fetch.php?media=$1 last;
        rewrite ^/_detail/(.*) /lib/exe/detail.php?media=$1 last;
        rewrite ^/_export/([^/]+)/(.*) /doku.php?do=export_$1&id=$2 last;
        rewrite ^/(.*) /doku.php?id=$1 last;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
        fastcgi_param  QUERY_STRING     $query_string;
        fastcgi_param  REQUEST_METHOD   $request_method;
        fastcgi_param  CONTENT_TYPE     $content_type;
        fastcgi_param  CONTENT_LENGTH   $content_length;
        fastcgi_intercept_errors        on;
        fastcgi_ignore_client_abort     off;
        fastcgi_connect_timeout 60;
        fastcgi_send_timeout 180;
        fastcgi_read_timeout 180;
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;
        fastcgi_temp_file_write_size 256k;
    }

    location ~ /(data|conf|bin|inc)/ {
        deny all;
    }
}

Altes Backup des Wikis ins lokale Webserver-Verzeichnis kopieren

Ich habe natürlich noch ein Backup des gesamten htdocs-Verzeichnisses meines alten Wikis. Dieses habe ich nach /home/wiki.natenom.me/htdocs/ kopiert und anschließend dem Benutzer www-data und der zugehörigen Gruppe zugänglich gemacht.

chown -R www-data: /home/wiki.natenom.de/htdocs/

Das Wiki sollte jetzt per Browser benutzbar sein via http://wiki.natenom.me/.

Lokales Wiki konfigurieren

TopBar

Um deutlich zu zeigen, dass dieses Wiki archiviert wurde, habe ich die TopBar-Funktion von DokuWiki genutzt, sodass oben am Rand auf jeder Seite dieser Text angezeigt wird:

Der Quelltext der Seite /topbar ist:

//Dieses Wiki wurde archiviert und wird nicht mehr gepflegt. Mein neues Wiki gibt es auf [[natwikic>|wiki.natenom.com]]. Details auf der [[:|Startseite]].//

Feeds

Ich habe dieses Mal die Feeds des Wikis deaktiviert.

Indexmenu

Das Indexmenü habe ich dieses Mal so eingestellt, dass weiterhin JavaScript genutzt wird. Der Quelltext von /wiki/sidebar dazu ist:

**Navigation**
{{indexmenu>..#2|js#indextheme useheading navbar tsort noscroll nsort notoc nomenu }}
\\
----
    * [[:datenschutz|Datenschutz]]
    * [[nblog>impressum/|Impressum]]
    * [[:lizenz|Lizenz]]
    * [[:ueber|Über]]

Parameter erklärt:

• Die #2 bewirkt, dass alle Seiten bis zur zweiten Ebene immer geöffnet sind. So sieht man auch mit deaktiviertem JavaScript noch die großen beiden Bereiche Minecraft und Mumble des Wikis in der Navigation.
• nomenu deaktiviert das Rechtsklick-Menü im Indexmenüs.

Da die Grafiken für das Indexmenü später nicht mit wget heruntergeladen werden, muss man sie manuell in /lib/plugins/indexmenu/images/ des heruntergeladenen Wikis platzieren. Die passenden Bilder gibt es in /lib/plugins/indexmenu/images/ des Webservers. Da ich das Default-Theme verwende, werden nur die im Hauptverzeichnis benötigt und dazu das Verzeichnis indextheme/.

    .
    ├── close.gif
    ├── empty.gif
    ├── indexmenu_toolbar.png
    ├── indextheme
    │   ├── base.gif
    │   ├── empty.gif
    │   ├── folder.gif
    │   ├── folderh.gif
    │   ├── folderhopen.gif
    │   ├── folderopen.gif
    │   ├── info.txt
    │   ├── joinbottom.gif
    │   ├── join.gif
    │   ├── line.gif
    │   ├── minusbottom.gif
    │   ├── minus.gif
    │   ├── page.gif
    │   ├── plusbottom.gif
    │   └── plus.gif
    ├── larrow.gif
    ├── msort.gif
    ├── rarrow.gif
    └── toc_bullet.gif

Bereiche entfernen

Jetzt werden die bereits migrierten Themenbereiche bzw. Namensräume aus dem Wiki entfernt.

In meinem Fall ist das alles innerhalb von /data/, das nicht zu Mumble, Minecraft oder dem Wiki selbst gehört.

Dazu löscht man die Namensräume (Verzeichnisse) und Dateien in diesen Bereichen:

• /data/cache/
• /data/media/
• /data/media_attic/
• /data/media_meta/
• /data/meta/
• /data/pages/

Danach könnte man sich im Wiki anmelden und den Suchindex neu erstellen lassen, falls man die Suche noch testweise verwenden möchte. Für die archivierte Seite ist der Suchindex jedoch irrelevant, da die Suche PHP benötigt und abgeschaltet sein wird.

Optional History entfernen

Da mit dieser Anleitung hier immer nur der aktuelle Status einer Seite heruntergeladen wird und die History deaktiviert ist, kann man diese komplett aus dem Wiki entfernen. Oder es einfach sein lassen, weil es darauf keinen Zugriff geben wird.

Ich will es trotzdem hier erwähnt lassen, weil man so Daten löschen kann, die sowieso keinen Zweck mehr haben auf einer statischen Website.

Dazu das Verzeichnis /data/attic/ leeren, aber nicht löschen. Genauso kann man mit /data/media_attic/, mit /data/media_meta/ und mit /data/meta/ verfahren.

Wiki vom lokalen Webserver herunterladen

Nun wird das Wiki vom lokalen Webserver heruntergeladen, die Startseite verfügbar gemacht, die sonst fehlt und die Sitemap heruntergeladen.

mkdir wiki_download
cd wiki_download

wget --recursive --no-clobber --page-requisites --html-extension --convert-links --restrict-file-names=unix --no-parent --reject-regex 'do=' -erobots=off --domains wiki.natenom.me http://wiki.natenom.me

cd wiki.natenom.me
cp index.html start.html
wget http://wiki.natenom.me/sitemap.xml.gz

Nachbearbeitung

Lokal verwendete Domain durch die spätere, richtige Domain ersetzen

Jetzt ersetzt man die massenhaft im heruntergeladenen Wiki hinterlegte lokal Domain durch die spätere, richtige Domain, die online verwendet wird.

Zuerst rekursiv in allen Dateien via sed und dann explizit in der sitemap.xml.gz und auch noch in lib/exe/manifest.php, wo aus irgendwelchen Gründen nur localhost steht.

cd wiki_download

shopt -s globstar ; for file in **/*; do test -f "${file}" && sed -i -e 's#http://wiki.natenom.me/#https://wiki.natenom.de/#g' "${file}"; done

gunzip sitemap.xml.gz
sed -i -e 's#http://localhost/./#https://wiki.natenom.de/#g' sitemap.xml
gzip sitemap.xml

sed -i -e 's#http:\\/\\/wiki.natenom.me\\/#https:\\/\\/wiki.natenom.de\\/#g' lib/exe/manifest.php

Eine 404-Seite

Zusätzlich habe ich noch eine 404-Seite hinzugefügt, die erwähnt, dass das Wiki archiviert wurde. Diese legt man im Hauptverzeichnis des heruntergeladenen Wikis als Datei 404.html ab und verweist in der Nginx-Konfiguration auf diese via error_page 404 /404.html;.

<html>
<body><h1>404 - File not found</h1>
<p>Das Wiki auf wiki.natenom.de wurde archiviert und in eine <a href="https://natenom.de/2022/03/dokuwiki-in-statische-website-umwandeln/">statische Website umgewandelt</a>.</p>
<p>Daher gibt es an vielen Stellen, f&uuml;r die PHP notwendig w&auml;re, eine 404 (File not found) Fehlermeldung.</p>
<p>Du kannst eine externe Suchmaschine benutzen, um Inhalte zu finden.</p>
</body>
</html>

Packen und hochladen

Das lokal heruntergeladene Wiki kann jetzt gepackt und hochgeladen werden.

cd wiki_download
zip -r wiki.natenom.me.zip wiki.natenom.me/

Dann lädt man es, wie auch immer, auf den Webserver hoch und entpackt es in das entsprechende htdocs-Verzeichnis, setzt die Berechtigungen passend und startet den Webserver neu.

Ergebnis

So sah die Startseite des archivierten Wikis bisher aus:

Und so sieht sie jetzt aus:

Und so sieht es ohne JavaScript aus:

Und so, falls der Browser so eingestellt ist, dass das Dark-Theme bevorzugt wird:

Anmerkungen für mich

• Im Gegensatz zu früher heißt /.cdn/ jetzt /_cdn/ und wurde entsprechend in den Konfigurationen angepasst.

Ziel war es, nur noch Webseiten zu haben, die statisch sind. D. h. sie werden nicht mehr auf einem Server mit PHP dynamisch erstellt sondern Zuhause einmalig vorgebaut, hochgeladen und dann bekommt jeder Benutzer immer die selben Dateien.

Dadurch benötigt man weder eine Scriptsprache auf dem Server noch eine Datenank (was DokuWiki aber auch so nicht benötigt, da es mit Text-Dateien statt einer Datenbank arbeitet).

Hier beschreibe ich alle notwendigen Schritte, um aus einem aktuellen DokuWiki eine statische Website zu erstellen, die man dann sorglos auf jeden Webspace werfen kann.

Das Werkzeug meiner Wahl ist wget, mit dem man ganze Websites oder Teile davon herunterladen kann. Dieses habe ich schon in der Vergangenheit genutzt, um mein altes MediaWiki in den Ruhestand zu schicken.

Ziel eines archivierten Wikis

Ich wollte den aktuellen Zustand des Wikis komplett mit allen Themenbereichen in einem Paket haben. Auch mit den Themenbereichen, die bereits im neuen Wiki enthalten sind. Damit die Informationen nicht doppelt vorhanden sind, sollten Weiterleitungen eingerichtet werden, sodass man beim “Öffnen/Anklicken” solcher Themenbereiche automatisch im neuen Wiki landet.

Das hat unter anderem den Hintergrund, dass man sehr einfach noch an die umgezogenen Themenbereiche dran kommt. Hätte ich sie im Wiki gelöscht, wären sie auch nicht mehr in der Sidebar links zu sehen.

Zudem besteht so die Möglichkeit, dass man das komplette archivierte Wiki weitergeben kann oder lokal zur Verfügung stellen. Als Archiv halt.

Vorbereitungen am Wiki vor dem Herunterladen mit wget

Damit später im archivierten Wiki möglichst selten 404-Fehlermeldungn erscheinen, habe ich alles deatkviert, was man nicht benötigt und/oder was ohne PHP nicht mehr funktionieren würde.

Deaktivierte ‘Aktionen’ von DokuWiki

In der Konfiguration von DokuWiki ist es möglich, bestimmte Aktionen zu deaktivieren. Einige davon waren bereits zuvor deaktiviert, ich habe dann noch alle anderen deaktiviert:

• Übersicht
• “Letzte Änderungen”
• “Links hierher”
• “Benutzerprofil”
• “Suche”, da sie PHP benötigt.
• “Setze neues Passwort”.
• “Diese Seite bearbeiten”
• Medien-Manager – Bei “Andere Aktionen (durch Komma getrennt)” media eingeben. Beim Aufruf von /start?do=media&ns= erscheint die Fehlermeldung Action disabled: media. Das hätte ich schon vor Jahren machen können, hätte ich es gewusst. Denn das war ein Bereich, der dauernd von Bots abgefragt wurde.

Indexmenü ohne Javascript

Ich habe das Indexmenu für die Sidebar (links) (Seitenname /wiki/sidebar) auf nojs umgestellt, damit kein JavaScript verwendet wird. Aus {{indexmenu>..#1|js#indextheme navbar tsort nsort notoc noscroll nocookie}} wird {{indexmenu>..#1|nojs#indextheme navbar tsort nsort notoc}}. Die Dokumentation dazu gibt es hier.

Die Liste der obersten Ebenen reicht in der Sidebar völlig aus, denn in jedem Namensraum ist am Ender der Startseite schon ein Indexmenü eingefügt, sodass man auf alle Seiten dort zugreifen kann. Zudem wird die Sidebar geöffnet dargestellt, sobald man sich auf einer Seite in einem der Unterbereiche befindet.

Weitere Änderungen

• DokuWiki-eigene Topbar-Seite gelöscht.
• Translation Plugin deaktiviert, da es sonst Links gibt auf z. B. start?id=linux/pulseaudio. Das wäre dann komplizierter geworden mit den ganzen Weiterleitungen (siehe unten) und es sind nur ein paar wenige Seiten in englischer Sprache in meinem Wiki (die ich später ins neue verschieben werde).
• Alle Benutzer außer Admin gelöscht
• Die Seite /wiki/syntax gelöscht. Die ist in jedem DokuWiki “vorinstalliert”.
• Namensraum en (English) aus dem Indexmenu ausgeschlossen.
• Startseite angepasst mit der Information, dass das Wiki archiviert wurde und nun statisch ist.

Es geht los – Wiki mit wget herunterladen

Während des Herunterladens habe ich sämtliche Weiterleitungen auf das neue Wiki temporär deaktiviert. Denn ich wollte das gesamte alte Wiki haben und nicht schon teiweise das neue.

Der Aufruf von wget zum Herunterladen des Wikis:

wget --recursive --no-clobber --page-requisites --html-extension --convert-links --restrict-file-names=unix --no-parent --reject-regex 'do=' --domains wiki.natenom.de https://wiki.natenom.de

-erobots=off

Ich habe das direkt auf dem Server ausgeführt, auf dem das Wiki läuft. Es hat circa 2 Minuten gedauert.

Die Befehlszeile habe ich von hier und die war hier verlinkt.

Zusätzlich habe ich noch die Sitemap heruntergeladen, die mit oberem Befehl nicht heruntergeladen wird:

wget https://wiki.natenom.de/sitemap.xml.gz

Wieso, weshalb, warum

• Man könnte --reject-regex noch erweitern mit 'do=|feed.php'. Ich möchte aber alle Feeds behalten, denn so kann man sehen, wenn man diese abonniert hat, dass es im Wiki nicht weiter geht. Und Programme und Suchmaschinen mögen es generell nicht, wenn Dateien plötzlich verschwinden. Dann lieber lassen und nichts neues eintragen.
• Dass URLs mit dem Parameter ?do= gefiltert werden, ist sinnvoll, weil man sonst zu jeder html-Datei noch einige weitere abc.html?do=def erhält. Z. B. für die Anmeldung, den Medien-Manager und einiges mehr. Hier der Unterschied zwischen einem Download mit wget mit --reject-regex 'do=' (links) und ohne (rechts):

  

DokuWiki durch statische Website ersetzen

Dann war der Zeitpunkt gekommen, das noch laufende DokuWiki durch das heruntergeladene archivierte Wiki zu ersetzen.

Das eine fliegt aus dem Webserver-Verzeichnis raus, das andere kommt rein. Dazu habe ich dann noch die zuvor heruntergeladene Sitemap hineinkopiert.

Backups sind immer wichtig, falls man doch noch mal an irgendwelche Dinge dran müsste.

Nacharbeiten in der Konfiguration des Webservers

Die Konfiguration des Webservers kann man nach dem Umzug deutlich vereinfachen, da nur noch das ausgeliefert wird, was auf dem Server liegt, ohne von PHP verarbeitet werden zu müssen. Darauf gehe ich hier nicht ein sondern werde nur ein paar Dinge nennen, die man ändern muss.

Mime Types wegen ‘Cache’-Anhang in Dateinamen

Da ein Dokuwiki einen Cachingmechanismus hat, werden einie Dateien, z. B. Bilder, je nach Art der Einbindung, mit ?cache= am Ende referenziert und beim Herunterladen entsprechend von wget benannt. Z. B. wird aus /url/zu/bild.jpg /url/zu/bild.jpg?cache=.

Klickt man auf eine solch referenzierte Datei, dann bietet der Webserver diese zum Download an, statt sie im Browser anzuzeigen. Das liegt daran, dass der Webserver nichts mit dieser “Dateiendung” anfangen kann.

Deshalb muss man dem Webserver mitteilen, was sich hinter diesen Endungen verbirgt. Das geht mit der folgenden Konfiguration: ¹

    location ~ \.jpg\?cache= {
        types { }
        default_type image/jpeg;
    }
    location ~ \.png\?cache= {
        types { }
        default_type image/png;
    }

Jetzt zusätzlich Auch auch .html am Ende achten

Die mit wget heruntergeladenen Dateien haben alle eine .html-Dateierweiterung bekommen. D. h. aus der vorherigen URL /android/ wurde /android.html.

Damit aber z. B. Links von extern noch richtig funkionieren, die ja auf /android/ verweisen, muss der Webserver angewiesen werden nicht nur auf /android/ zu prüfen, sondern auch auf /android.html und dann das Gefundene nutzen. Daher muss das in die config für das alte Wiki (wiki.natenom.de) das hier hinein:

    location / ...
        try_files $uri $uri.html $uri/ =404;

Der Webserver prüft also auf android, android.html und /android/ und gibt erst 404 zurück, wenn nichts davon gefunden wird.

Weiterleitungen mit .html auch am Ziel beachten

Da viele Inhalte meines alten Wikis schon in meinem neuen Wiki (wiki.natenom.com) enhalten sind und ensprechend verlinkt werden, musste ich auch dort noch die Konfiguration des Webservers anpassen.

Ich leite nach folgendem Muster von meinem alten Wiki ins neue Wiki weiter:

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

Das bedeutet, dass z. B. ein weitergeleitetes https://wiki.natenom.de/android im neuen Wiki wiki.natenom.com/ sowohl in der Form /android als auch in der Form /android.html ankommen kann. Damit letztere Form im neuen Wiki keine 404 verursacht, kann man den Webserver anweisen, die Dateiendung immer zu entfernen:

    location / {
        if ($request_uri ~ ^/(.*)\.html) {
            return 302 /$1;
        }
    }

Somit landen alle Formen der Weiterleitung am richtigen Ziel:

• /android -> wiki.natenom.com/android
• /android.html -> wiki.natenom.com/android.

Aufräumarbeiten

Dafür habe ich in den letzten Wochen und Monaten immer wieder sehr viel Arbeit investiert. Und nun war es endich soweit. Alle meine Webseiten waren statisch und so konnte ich (nachdem ich schon vor Monaten MySQL deinstallieren konnte, weil der Blog statisch wurde) endlich auch PHP von meinem Server deinstallieren:

systemctl stop php7.3-fpm
systemctl disable php7.3-fpm

apt remove --purge php*

php php-common php-fpm php-gd php-imagick php-mbstring php-sqlite3 php-xml php-zip php7.3 php7.3-cli php7.3-common php7.3-curl php7.3-fpm php7.3-gd php7.3-json php7.3-mbstring php7.3-opcache php7.3-readline php7.3-sqlite3 php7.3-xml php7.3-zip

Fertig 🙂

Hier das Ergebnis: Mein archiviertes Wiki, das jetzt auf wiki.natenom.de liegt.

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:

Hier erkläre ich, was ich alles gemacht habe, um mein neues Wiki so einzurichten, wie man es in ein paar Tagen online sehen wird.

Neue Website mit Hugo erstellen

hugo new site wiki.natenom.com

cd wiki.natenom.com
git init .

cd themes
git submodule add https://github.com/google/docsy.git

cd docsy
git submodule sync && git submodule update --init --recursive

Installation von PostCSS

npm install -D autoprefixer
npm install -D postcss-cli
npm install -D postcss

Dokumentation

Eigenes CSS

Eigenes CSS kommt in die Datei assets/scss/_styles_project.scss.

Dokumentation.

Shortcodes

Ich verwende einige meiner Shortcods aus meinem Blog.

Das Theme Docsy liefert viele Shortcodes bereits mit, siehe hier.

Alte Bilddateien

Alte Bilddateien habe ich erst einmal nach static/_media/ kopiert damit sie noch eine Zeit lang unter der selben URL zu erreichen sind wie bisher auch, wenn auch auf einer neuen Domain, zum Beispiel https://wiki.natenom.de/_media/minimalismus.jpg.

Keine externen Ressourcen

Per Voreinstellung bindet das Theme leider ein paar externe Ressourcen ein. Diese werden in den Dateien theme/docsy/layouts/partials/scripts.html und theme/docsy/layouts/partials/head.html referenziert.

JavaScript und CSS

Doch man kann die referenzierten Dateien auch herunterladen und selbst in Hugo vorhalten. ¹

Dazu kopiert man die eben genannte Datei nach hugo/layouts/partials/. Somit werden unsere eigenen Version verwendet statt der im Theme mitgelieferten.

Dann erstellt man in hugo/static ein Verzeichnis externals und lädt dorthin alle eingebundenen Dateien herunter und ändert anschließend die URLs der eingebundenen Dateien. Aus https://... wird /externals/....

Ursprüngliche Datei scripts.html:

[…]
<script
  defer
  src="https://cdn.jsdelivr.net/npm/katex@0.15.1/dist/katex.min.js"
  integrity="sha512-5ufNcHqOYgilGEHPfuRIQ5B/vDS1M8+UC+DESZ5CwVgGTg+b2Ol/15rYL/GiCWJ/Sx8oVo0FPFok1dPk8U9INQ=="
  crossorigin="anonymous"
></script>
[…]

Veränderte Datei scripts.html:

[…]
<script defer src="/externals/katex.min.js" crossorigin="anonymous"></script>
[…]

Das sind die Dateien, die von extern eingebunden werden:

• auto-render.min.js
• bootstrap.min.js
• katex.min.css
• markmap-autoloader
• mermaid.min.js
• mhchem.min.js
• popper.min.js

Schriften

Dann werden auch noch Fonts eingebunden in:

• docsy/assets/scss/rtl/_main.scss
  • Hierfür erstellt man die neue Datei assets/scss/rtl/_main.scss ohne Inhalt. Damit wird die Originaldatei vom Theme überlagert. Auch das habe ich bei OpenBikeSensor gefunden, siehe hier.
• docsy/assets/scss/_variables.scss.
  • Hierfür erstellt man die neue Datei assets/scss/_variables_project.scss mit folgendem Inhalt:

    $td-enable-google-fonts: false;

Schriften selbst hosten

Da mir die im Original-Theme verwendete Schriftart gefällt, binde ich sie lokal ein. Wie das geht, habe ich auf der Projektseite von OpenBikeSensor gefunden, siehe hier.

Hier eine Anleitung, wie man an die Schriftdateien kommt.

Dazu kommt zusätzlich in die Datei assets/scss/_variables_project.scss:

$font-family-sans-serif:
  "Open Sans",
  -apple-system,
  BlinkMacSystemFont,
  "Segoe UI",
  Roboto,
  "Helvetica Neue",
  Arial,
  sans-serif,
  "Apple Color Emoji",
  "Segoe UI Emoji",
  "Segoe UI Symbol";

/* open-sans-300 - latin */
@font-face {
  font-family: "Open Sans";
  font-style: normal;
  font-weight: 300;
  src:
    local(""),
    url("/fonts/open-sans-v27-latin-300.woff2") format("woff2"),
    /* Chrome 26+, Opera 23+, Firefox 39+ */
      url("/fonts/open-sans-v27-latin-300.woff") format("woff"); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

/* open-sans-500 - latin */
@font-face {
  font-family: "Open Sans";
  font-style: normal;
  font-weight: 500;
  src:
    local(""),
    url("/fonts/open-sans-v27-latin-500.woff2") format("woff2"),
    /* Chrome 26+, Opera 23+, Firefox 39+ */
      url("/fonts/open-sans-v27-latin-500.woff") format("woff"); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

/* open-sans-regular - latin */
@font-face {
  font-family: "Open Sans";
  font-style: normal;
  font-weight: 400;
  src:
    local(""),
    url("/fonts/open-sans-v27-latin-regular.woff2") format("woff2"),
    /* Chrome 26+, Opera 23+, Firefox 39+ */
      url("/fonts/open-sans-v27-latin-regular.woff") format("woff"); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

/* open-sans-700 - latin */
@font-face {
  font-family: "Open Sans";
  font-style: normal;
  font-weight: 700;
  src:
    local(""),
    url("/fonts/open-sans-v27-latin-700.woff2") format("woff2"),
    /* Chrome 26+, Opera 23+, Firefox 39+ */
      url("/fonts/open-sans-v27-latin-700.woff") format("woff"); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

Die acht heruntergeladenen woff- und woff2-Dateien kommen dann nach static/fonts/.

• open-sans-v27-latin-300.woff
• open-sans-v27-latin-300.woff2
• open-sans-v27-latin-500.woff
• open-sans-v27-latin-500.woff2
• open-sans-v27-latin-700.woff
• open-sans-v27-latin-700.woff2
• open-sans-v27-latin-regular.woff
• open-sans-v27-latin-regular.woff2

Die Dokumentation zu Fonts in Docsy gibt es hier.

Lokale Suche aktivieren

In die config.toml eintragen:

[params]
offlineSearch = true
algolia_docsearch = false

Dokumentation

Kaskadierung – “/docs/abc” vs “/abc”

Per Voreinstellung des Themes sollen alle Dokumentationsinhalt im Unterverzeichnis content/<sprache>/docs/ eingefügt werden und /docs/ ist dann überall in der URL zu sehen. Man landet auch immer auf einer Startseite, die per Voreinstellung leer ist und muss dann für mein Wiki erst einmal rechts oben auf den Eintrag Wiki klicken. Das liegt daran, dass für das Theme docs nur ein Inhaltstyp von mehreren ist. Daneben gibt es z. B. noch blog.

Da ich schon hier einen Blog betreibe und neben der Dokumentation keine weiteren Inhaltstypen im Wiki benötige, habe ich das Theme so umgestellt, dass content/<sprache>/docs/ nicht benötigt wird. Stattdessen liegen alle Inhalte direkt im Hauptverzeichnis content/<sprache>/.

Zuerst werden alle Dateien und Verzeichnisse aus content/<sprache>/docs/ nach content/<sprache>/ verschoben.

Dann erstellt man die Datei content/<sprache>/_index.md mit folgendem Inhalt: ²

---
title: "Wiki"
linkTitle: "Wiki"
type: "docs"
weight: 20
menu:
  main:
    weight: 20
cascade:
- _target:
    path: "/blog/**"
  type: "blog"
  # set to false to include a blog section in the section nav along with docs
  toc_root: true
- _target:
    path: "/**"
    kind: "page"
  type: "docs"
- _target:
    path: "/**"
    kind: "section"
  type: "docs"
- _target:
    path: "/**"
    kind: "section"
  type: "home"
---

Natenoms neues Wiki. Mein altes Wiki unter https://wiki.natenom.de wird weiterhin bestehen bleiben. Jedoch werde ich neue Inhalte nur noch hier erstellen und die alten Inhalte langsam nach hierher umziehen. Die ganz alten Sachen werden dauerhaft im alten Wiki verbleiben.

Dokumentation zu cascade auf docsy.dev und auf gohugo.io.

Verzeichnisstruktur

Die von DokuWiki exporierte Verzeichnisstruktur muss noch angepasst werden, damit sie in Hugo richtig angezeigt wird. Hier am Beispiel des Namensraums “Orte”.

Zuerst die Struktur, wie sie exportiert wurde (und wie sie auch in DokuWiki war):

.
├── orte
│   ├── enzkreis.md
│   ├── landkreis_calw.md
│   ├── neuhausen_enzkreis.md
│   └── pforzheim.md
├── orte.md

Und die angepasste Struktur:

.
├── orte
│   ├── enzkreis.md
│   ├── _index.md
│   ├── landkreis_calw.md
│   ├── neuhausen_enzkreis.md
│   └── pforzheim.md

Die Änderungen haben meinem Verständnis nach vor allem mit Page Bundles zu tun.

Während z. B. in DokuWiki der Hauptbereich orte aus dem Verzeichnis orte und einer auf gleicher Ebene liegenden Datei orte.txt besteht, so benötigt Hugo eine Struktur in der Form, dass es ein Verzeichnis orte gibt, in dem die Datei _index.md liegt, die der Datei orte.txt (bzw. orte.md im exportierten Verzeichnis) von DokuWiki entspricht.

Bilder zusammen mit Markdown-Dateien

In DokuWiki liegen Dateien in dokuwiki/media/ und Seiten in dokuwiki/pages/. In Hugo liegen Bilder, Videos, usw. in den selben Verzeichnissen wie auch die Markdown-Dateien. Würden sie in einer eigenen Verzeichnisstruktur liegen, wäre es z. B. nicht möglich, automatisiert kleinere Varianten dieser Bilder zu erstellen. Das hat was mit Page Bundles zu tun.

Ich glaube ich habe das Konzept von Page Bundles einigermaßen verstanden, so, dass ich es nutzen kann. Erklären kann ich es aber nicht. Bitte selbst die Dokumentation lesen.

Entwurfsmodus für ganze Namensräume

Fügt man in das Front Matter einer _index.md-Datei das Tag draft mit dem Wert true ein, dann befindet sich der gesamte Namensraum im Entwurfsmodus. D. h. er wird nur gerendert, wenn man hugo mit dem Parameter -D aufruft.

D. h. ich stelle die Namensräume, die noch nicht fertig sind, auf Entwurf um.

Man muss allerdings bedenken, dass es eine Fehlermeldung gibt, wenn man den Shortcode ref (Dokumentation) verwendet, um auf URL innerhalb der Website zu verlinken, die dann in der gerenderten Website gar nicht existieren wird.

Eine Liste aller im Entwurfsmodus befindlichen Seiten erhält man z. B. mit grep, wenn man nach draft: … sucht oder noch einfacher mit:

hugo list drafts

Das Kommando muss dabei im Basisverzeichnis der Hugo-Website ausgeführt werden.

Teilweiser Umzug

Sobald ein Namensraum der Hauptebene fertig ist, stelle ich draft: false ein, lasse die Website rendern und lade das Ergebnis hoch.

In der Nginx-Konfiguration richte ich dann Weiterleitungen für diesen Namensraum ein. Entweder einen Eintrag für den gesamten Namensraum, wenn sich an dessen URL-Struktur nichts verändert hat oder einzeln je Seite, wenn ich die Struktur verändert habe.

About-Seite

Wenn es eine Seite mit dem Namen about gibt, so wird diese automatisch unten im Footer aufgelistet.

Dies kann man in der config.toml abschalten mit:

    [params.ui]
    footer_about_disable = true

Impressum/Datenschutz

Ganz wichtig im Land, in dem Kennzeichen schützenswerter sind als Menschen: Man benötigt Links zu Impressum und zu Datenschutz.

Dazu habe ich das Verzeichnis content/de/ueber/ erstellt. Hier landen alle Inhalte, in denen es über mein neues Wiki geht.

Optional kann man die Seite im Seitenverzeichnis verstecken, in dem man ins Front Matter toc_hide: true einträgt. ³

Aus der Suche ausschließen

Mit dem Eintrag exclude_search: true im Front Matter kann man die Inhalte einzelner Seite von der Indexierung der Suchfunktion ausschließen.

Dokumentation

Liste aller Tags aus der Sidebar entfernen

Mir gefällt es gar nicht, dass im verwendeten Theme rechts immer alle vorhandenen Tags des gesamten Wikis angezeigt werden. Das ist meiner Ansicht nach unnötig und sehr störend, da es in meinem Wiki (noch) hunderte Tags gibt.

Um das zu entfernen habe ich die Datei hugo/themes/docsy/layouts/partials/taxonomy_terms_clouds.html aus dem Theme-Verzeichnis nach hugo/layouts/partials/ kopiert und den Inhalt gelöscht.

404 Fehlerseite

Es wird automatisch eine 404-Fehlerseite erzeugt. Diese kann man z. B. in der Nginx-Konfiguration aktivieren mit:

error_page 404 /404.html;

Interwiki-Links

Ich kann im neuen Wiki die Interwiki-Links nutzen, die ich gerade erst implementiert habe. Siehe hier.

Datenschutz und Impressum in den Footer

Die Datei hugo/themes/docsy/layouts/partials/footer.html nach hugo/layouts/partials/footer.html kopieren und in Zeile unten einfügen:

<p class="mt-2">
  <small>
    <a href="/impressum/">Impressum</a>
    <a href="/docs/ueber/datenschutz/">Datenschutz</a></small
  >
</p>

Icons links unten

Das Theme bietet die Möglichkeit, dass man links unten (und rechts unten) verschiedene Icons einfügt, die auf verschiedene andere Webseiten wie z. B. auf ein Maston-Profil verlinken.

In die config.toml eintragen:

[params.links]
[[params.links.user]]
        name = "Über Natenom"
        url = "/about/"
        icon = "fas fa-user-circle"
        desc = "Über Natenom"
[[params.links.user]]
        name = "Mumble"
        url = "https://wikiarchiv.natenom.de/ueber/natemologie-zentrum"
        icon = "fa fa-mobile"
        desc = "Mumble"
[[params.links.user]]
        name = "E-Mail"
        url = "mailto:user@tld.org"
        icon = "fa fa-envelope"
        desc = "E-Mail"
[[params.links.user]]
        name = "Github"
        url = "https://github.com/natenom"
        icon = "fab fa-github"
        desc = "Github"
[[params.links.user]]
        name = "Twitter"
        url = "https://twitter.com/natenom"
        icon = "fab fa-twitter"
        desc = "Github"
[[params.links.user]]
        name = "Mastodon"
        url = "https://social.anoxinon.de/users/natenom"
        icon = "fab fa-mastodon"
        desc = "Mastodon"

So sieht es aus:

Damit die Icons rechts landen, nutzt man statt params.links.user die Zeichenkette params.links.developer.

Videos (extern) hosten

Im alten Wiki sind einige Videos enthalten. Diese werde ich in Zukunft auf f.natenom.de hosten, damit das Git-Repo des Wikis nicht unnötig groß wird. Außerdem will ich nicht, dass die Videos für immer im Repo verbleiben.

Dauer fürs Rendern

Das neue Wiki braucht aktuell circa 10 Sekunden, um komplett gerendert zu werden:

                |  DE
-------------------+-------
Pages            | 1289
Paginator pages  |    0
Non-page files   |  143
Static files     |  105
Processed images |  102
Aliases          |    0
Sitemaps         |    1
Cleaned          |    0

Built in 9771 ms

Ergebnis

Und so sieht derzeit mein neues Wiki aus:

Todo

Was mir noch fehlt:

• Nummerierung der Überschriften (Inhalt und Inhaltsverzeichnis).
• Favicons einrichten (Dokumentation)

Ich habe mich für Pandoc entschieden.

Export mit Hilfe von Pandoc

Der grundsätzliche Aufruf für den Export via Pandoc ist:

find path/to/pages/ -iname "*.txt" -exec pandoc --wrap=none -s --from=dokuwiki --to=gfm -o "{}.md" '{}' \;

Der Parameter --wrap=none ist wichtig, weil sonst Zeilen immer nach 72 Zeichen einen Zeilenumbruch bekommen. Dokumentation hierzu siehe hier im Bereich “wrap”.

Die erstellten .md-Dateien liegen jetzt immer an der selben Stelle wo auch die .txt-Datien liegen.

.txt-Dateien löschen

Die alten .txt-Dateien können jetzt gelöscht werden mit:

find path/to/pages/ -name "*.txt" -execdir rm '{}' \;

Front Matter

Damit Dateien überhaupt in Hugo gerendert werden, müssen sie ein rudimentäres Front Matter haben, das zumindest z. B. den Titel enthält:

---
title: Müllsammeln
---

Für das Hinzufügen dieses rudimentären Front Matters (mit dem Dateinamen als Titel) habe ich das Script von hier angepasst und hinzugefügt, dass auch die erste H1-Überschrift in jeder Datei entfernt wird, da Hugo diese beim Rendern der Website automatisch aus dem titel: generiert. Zusätzlich wird noch das .txt aus den Dateinamen entfernt.

#!/bin/bash

filepath="$1" #path/to/filename.md
file_name=$(basename $filepath) #filename.md

md='.txt.md'
title=${file_name%$md} #filname
newname="${title}.md" #filename.md

TEMPLATE="---
title: $title
---

# Remove first line of file (with # Title)
sed -i '1d' "${filepath}"

echo "$TEMPLATE" | cat - "$filepath" > temp && mv temp "${filepath%$md}.md"
rm ${filepath}

Der Aufruf ist:

find pages/ -name "*.md" -print0 | xargs -0 -I file path/to/prepend.sh file

Fertig

Im Ergebnis erhält man die komplette Verzeichnisstruktur eines DokuWiki mit Dateien im Markdown-Format.

Zusätzlich benötigt man aber noch die Medien-Dateien (Fotos, Screenshots, Videos, usw.) aus dem DokuWiki.

Verzeichnisstruktur der .md-Dateien

Hier ein Auszug aus der Verzeichnisstruktur meines exportierten Wikis:

.
└── pages
    […]
    ├── sport
    │   ├── fahrrad
    │   │   ├── hunde.md
    │   │   ├── kleidung
    │   │   │   ├── armlinge_und_beinlinge.md
    │   │   │   ├── baselayer.md
    │   │   │   ├── handschuhe.md
    │   │   │   ├── hose.md
    │   │   │   ├── lenkerstulpen
    │   │   │   │   ├── 45nrth.md
    │   │   │   │   └── einfache_variante.md
    │   │   │   ├── lenkerstulpen.md
    │   │   │   ├── schuhe.md
    │   │   │   ├── sicherheitsweste.md
    […]

Verzeichnisstruktur der Medien-Dateien

Zusätzlich benötigt man natürlich noch die Dateien aus media/.

Auch hier ein Auszug aus den entsprechenden Verzeichnissen meines alten Wikis:

    […]
├─ sport
│   └── fahrrad
│       ├── 2019-06_kamera_befestigung_am_rueckspiegel_1.jpeg
│       ├── 2019-06_kamera_befestigung_am_rueckspiegel_2.jpeg
│       ├── 2020-07_kamera_setup_vorne_1.jpg
│       ├── 2020-07_kamera_setup_vorne_2.jpg
│       ├── 2020-07_kamera_setup_vorne_3.jpg
│       ├── 2020-12_kamerabefestigung_lenkertaschenhalter_01.jpg
        […]

Es gibt zwar Export-Tools von DokuWiki nach Markdown (und damit hin zu Hugo), doch der Einsatz solcher Tools ist mit sehr viel Mehrarbeit nach dem Export der Daten verbunden. Hier habe ich bereits die verfügbaren Lösungen ausprobiert.

Und in meinem Fall ist es extrem viel Mehrarbeit, da mein Wiki aus vielen hundert Seiten besteht. Alleine meine Mumble-Dokumentation besteht aus über 350 Seiten.

Daher habe ich mich für Folgendes entschieden:

• Ich fange ein neues Wiki an. Mit Hugo und einem Theme, das für Dokumentationen gemacht wurde, wie z. B. Docsy, mit dem auch die Dokumentation des OpenBikeSensors zur Verfügung gestellt wird.
• Neue Inhalte werde ich ab sofort nur noch ins neue Wiki einfügen.
• Inhalte aus dem alten Wiki, die noch “aktiv” sind, werde ich nach und nach umziehen und am alten Ort auf den neuen Ort verlinken.
• Diese aktuell “aktiven” Inhalte werden dann erst einmal “Sport” bzw. “Fahrrad” und “Verkehr” bzw. “Mobilität” sein. Danach vermutlich “Müllsammeln”.
• Irgendwann werde ich das alte Wiki auf “Readonly” umstellen oder sogar mit Hilfe von z. B. wget in eine statische Website umwandeln, so wie damals mit meinem alten MediaWiki.

Was das alte Wiki hat und was das neue Wiki erfüllen muss

Ich habe angesehen, welche Formatierungen im alten Wiki verwendet werden, welche Plugins installiert sind, welche Funktionen ansich wichtig sind und was ein Theme für das neue Wiki können sollte.

Basis-Formatierungen

Alle Basis-Formatierungen aus DokuWiki (solche, für die keine Plugins benötigt werden), die ich in meinem bisherigen Wiki verwende, stehen so auch von Haus aus in Hugo zur Verfügung und werden auch von entsprechenden Tools automatisch konvertiert.

Verwendete Plugins von DokuWiki, deren Funktionalität ersetzt werden muss (oder nicht)

Das hier ist die Liste der Plugins, die in meinem DokuWiki verwendet werden. Ich bin sie durchgegangen und habe geprüft, ob es einen Ersatz für Hugo gibt oder ob ich die Funktionalität überhaupt noch benötige.

• Anchor – Damit kann man Anker an bestimmten Punkten erstellen. Ich nutze das für Überschriften, auf die ich von extern verlinken möchte. In Hugo ist das automatisch für jede Überschrift möglich.
• DokuTeaser – Verwende ich nur auf der Startseite und brauche das im neuen Wiki gar nicht mehr.
• Gallery – Eine Bildergalerie. Gibt es für Hugo, aber wäre schön, wenn das Theme das selbst könnte und ich es nicht implemtieren müsste. Habe ich aber bisher im Wiki auch nur aus Faulheit verwendet in ein paar Fällen. Brauche ich eigentlich nicht. Einbindung von Einzelbildern hintereinander ist ausreichend.
• hidden – Klappt einen Bereich erst nach einem Klick auf “Anzeigen” aus. Hier habe ich einen eigenen Shortcode für den Blog erstellt mit dem Namen details, den ich auch im Wiki verwenden kann, falls ich ihn irgendwann doch mal benötigen sollte.
• Imagebox – Einfache Box für Bilder mit der Option für Untertitel. Hier kann ich einen eienen figure shortcode aus meinem Blog benutzen.
• Include – Verwende ich nur für, um in bestimmten Seiten über Produkte den Disclaimer einzufügen. Hier kann ich den Shortcode disclaimer aus dem Blog verwenden.
• Indexmenu – Wunderschöne Baumansicht fürs Wiki. Leider ist die schöne Ansicht nur mit JavaScript verfügbar. Hier werde ich die Defaultansicht des Hugo-Themes nutzen, die mir dann ausreichen wird.
• keyboard – Zum Verdeutlichen von Tastenkombinationen – Kann ich sehr einfach als Shortcode selbst umsetzen.
• Move Plugin – Kümmert sich beim Verschieben von Seiten innerhalb des Wikis um das Anpassen der relativen Links auf andere Seiten und Bilder im Wiki. Kann man selbst implementieren für Hugo.
• Pagelist – Dieses Plugin wird benötigt, damit die Liste der Tags im Wiki funktioniert.
• Page Navigation Plugin – Habe ich nur ganz selten und ausschließĺich früher in der Mumble-Dokumentation verwendet und benötige das nicht mehr. Ließe sich einfach als Shortcode erstellen.
• Page Query Plugin – Das könnte mir fehlen. Ein sehr mächtiges Plugin, um z. B. alle Seiten eines besimmten Namensraums als Liste in einer Wikiseite einzufügen, deren Seitennamen bestimmte Bedingungen erfüllen. Möglicherweise könnte ich für rudimentäre Funktionen sowas wie ToC nutzen (siehe unten). Ein interessanter Shortcode dafür könnte toc-tree sein.
• Redirect Plugin – Hugo hat von Haus aus Aliases, die man im Front Matter eintragen kann, um eine Seite nach dem Umzug noch am alten Ort erreichbar zu haben.
• SocialCards Plugin – Kümmert sich um das Hinzufügen von Metadaten für Twitter Cards und Open Graph. Sollte das Theme in Hugo unterstützen, da wichtig fürs Teilen von Inhalten auf SocialMedia.
• sortablejs – Damit wird ermöglicht, dass Tabellen sortierbar werden. Kann ich drauf verzichten, da nicht unbedingt notwendig. Eventuell sogar selbst anhand des Codes implementierbar.
• Tag Plugin – Tags gibts in Hugo von Haus aus.
• Translation Plugin – Gibts in Hugo von Haus aus. Muss nur vom Theme unterstützt werden.
• Wrap Plugin – Infobox, Warnbox, … und auch ein clear Container. Für das alles habe ich schon selbst im Blog einem Shortcode umgesetzt, den ich auch hier verwenden kann.

Versionierung

DokuWiki hat eine Versionshistory für jede einzelne Seite. Das geht auch mit Git, zwar nicht über die Website sondern nur in der Shell, aber das reicht mir. Im DokuWiki hatte ich die Funktion für unangemeldete Benutzer sowieso deaktiviert und selbst nie genutzt.

Optional kann man in Hugo aktivieren, dass Daten aus Git auslesbar werden und innerhalb verschiedener Seiten angezeigt werden können, wie z. B. die letzte Änderung einer Seite. Details siehe Git in Hugo.

Funktionen, die ein Theme für Hugo haben sollte

• Inhaltsverzeichnis für jede Seite.
• Hell- und Dunkel-Modus wären schön. Im aktuellen Wiki wird das verwendet, was im Browser eingestellt wurde, es lässt sich aber nicht in einem Menü des Wikis umschalten.
• Mehrsprachigkeit – Aus historischen Gründen habe ich ein paar Seiten in Englisch im Wiki. Ist keine Notwendigkeit, aber Hugo hat das eh schon von Haus aus.
• Breadcrumbs wären schön.
• Keinerlei Einbindungen von externen Elementen.

Getestete Themes

Ich wollte hier nachvollziehbar machen, weshalb ich mich für ein Theme entschieden habe. Da ich aber direkt mit Docsy anfing und das (fast) alles kann, was ich brauche, gibt es zum Vergleich nur noch Geekdocs. Vielleicht hilft es ja jemandem 🙂, der ein Theme sucht.

Neue Möglichkeiten

Wenn das Repo des neuen Wikis z. B. auf Github liegen würde, dann könnte jeder Mensch mit einem Account dort einen Fehler im Wiki melden oder direkt selbst korrigieren.

Entscheidung

Ich habe mich für das Theme Docsy entschieden.

DokuWiki-to-Markdown-Converter

Link zum Konverter

Aufruf:

find path/to/pages/ -name "*.txt" -exec php convert.php '{}' \;

Danach gibt es sowohl die alten .txt-Dateien als auch die neuen .md-Dateien in pages/. Jetzt können wir die alten Dateien löschen:

find path/to/pages/ -name "*.txt" -execdir rm '{}' \;

Das Ergebnis ist eine Verzeichnisstruktur von pages, die nur noch .md-Dateien ohne Front Matter enthält.

Pro und Kontra von DokuWiki-to-Markdown-Converter

• Pro
  • Konvertiert Tabellen
  • Konvertiert ins Github flavored Markdown
  • Konvertiert eingebettete Bilder, auch mit Bildbeschreibungen.
• Kontra
  • Das Tool erstellt kein Front Matter.
  • Keine Konvertierung von Fußnoten.
  • Leerzeile auch zwischen zusammen gehörigen Listen
  • Hat Probleme bei Titeln von Tabellen (gibt es keine Überschrift, dann wird die erste Zeile zur Überschrift).

DokuWiki-to-Hugo

Link zum Konverter

Aufruf:

python src/main.py --dir='path/to/pages/'

Das Ergebnis ist eine neue Verzeichnisstruktur von pages, die nur noch .md-Dateien ohne Front Matter enthält.

Pro und Kontra von DokuWiki-to-Hugo

• Pro
  • Erzeugt Front Matter, allerdings im TOML-Format
• Kontra
  • Bei mir wurde nur das Front Matter zur exportierten Datei hinzugefügt, jedoch keinerlei Konvertierung der Dateiinhalte vorgenommen.
  • Selbst wenn es funktionieren würde, so gibt es nur Konvertierungen für relativ wenige Elemente.

Pandoc

Link zum Konverter

Aufruf:

find path/to/pages/ -iname "*.txt" -exec pandoc --wrap=none -s --from=dokuwiki --to=gfm -o "{}.md" '{}' \;

Der Parameter --wrap=none ist wichtig, da sonst in jeder Zeile nach 72 Zeichen ein Zeilenumbruch eingefügt wird. Dokumentation dazu gibt es hier im Bereich “wrap”.

Pro und Kontra von Pandoc

• Pro
  • Konvertiert Fußnoten und viele andere Dinge.
• Kontra
  • Kein Front-Matter (natürlich nicht, ist ein Konverter, kein Hugo-Exporter). Der lässt sich aber rudimentär selbst einfügen.
  • Konvertiert eingebettete Bilder in img-Tags statt in die Markdown-Syntax.

Fazit

Pandoc gefällt mir von den getesteten Möglichkeiten am besten. Wie ich das genau benutzt habe, um die Inhalte meines Wikis zu exportieren, schreibe ich in einem eigenen Blogbeitrag und werde diesen hier verlinken.

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.

• Jetzt in Listenform.

  • Weil. :)

• Fertig, wenns fertig ist

  • Ich hatte mir vorgenommen, den Linkdump einmal die Woche zu veröffentlichen, weil es mir damals noch mit WordPress schwer fiel, das überhaupt zu machen.
  • Mit meinem aktuellen Workflow ist es aber ziemlich einfach und ich kann neue Links direkt beim/nach dem Lesen einfügen, sowohl am PC als auch auf dem Smartphone. Da kommt dann viel zusammen, weshalb ich den Linkdump unregelmäßig veröffentlichen werde. Nämlich dann, wenn ich den Eindruck habe, dass genug Links enthalten sind. Das kann dann einmal die Woche sein oder auch mehrmals die Woche, oder auch seltener.
  • Namensschema: “Linkdump NR/Jahr”, dieser Linkdump hier ist somit “Linkdump 2/2022”.

Los gehts:

• Fahrradteile sind derzeit teilweise rar. Und anscheinend besonders wertvoll.
• Beispiel, wie man anhand eines Fotos und öffentlich verfügbaren Daten herausfinden kann, wo genau ein Foto entstanden ist, sofern es erkennbaŕe Objekte gibt, wie z. B. einen bekannten Turm.
• Tempo spart keine Fahrzeit
• Roboterhunde für den Grenzschutz
• Eine schöne Zusammenfassung der Neuerungen im Highway-Code in Großbritannien, der der StVO (Straßenverkehrsordnung) in Deutschland entspricht.
• Radiosendung zum Thema “Wem gehört die Straße”?
• Fernseh-Interview mit Ansgar Hegerfeld (ADFC Hessen) zu motorisierter Gewalt
• MediathekView ist eine Java-Anwendung fûr den Desktop, um Sendungen vom Öffentlich-rechtlichen zu finden und herunterzuladen. Das gibts aber auch direkt als Website unter mediathekviewweb.de.
• Ich würde gerne auch mein DokuWiki nach Hugo konvertieren, bin aber noch unsicher. Hier gibts aber schonmal ein viel versprechendes Python-Tool für die Konvertierung.
• Wie viel Waldfläche braucht man für Windkraftanlagen?
• Bericht über einen Menschen, der auch Müll sammelt :)

Also fing ich an, die Dokumentation in meinem eigenen DokuWiki zu schreiben. Und ich schrieb viel und investierte extrem viel Zeit. Das Ergebnis war die damals (und vermutlich heute immer noch) umfangreichste Dokumentation zur Mumble Software. Aktuell besteht die Dokumentation aus über 350 Wikiseiten mit teilweise sehr detaillierten Informationen. Über viele Jahre hatte ich auch die Entwicklung der Software verfolgt und die Dokumentation gepflegt, war dann irgendwann auch im Team des Projekts.

In den letzten Jahren haben sich meine Prioritäten jedoch verändert. Aus “Sachen am PC machen” wurde “draußen sein”, “Fahrrad”, “Mobilität”. Für mich persönlich war das ein extrem großer Zugewinn an Lebensqualität, der bis heute anhält. Für die Mumble-Dokumentation war es ein langsames Aus. Ende 2020 war das Thema Mumble dann durch meine anderen Interessen fast gänzlich verdrängt worden.

Und so steht es auch schon von Anfang an in meinem Wiki, weil es schon immer so war, dass sich Interessen ändern:

Willkommen im Wiki von Natenom. Hier findet man viele verschiedene Informationen zu Themen, die mich seit 2010 interessiert haben und zu solchen, die mich aktuell interessieren.

Der erste Satz auf der Startseite meines Wikis

wiki.natenom.de

Ich habe immer wieder mal Ansätze gehabt, die Dokumentation auf den aktuellen Stand bringen zu wollen, es aber nie geschafft, denn es bedeutet sehr viel Arbeit und Zeit, die ich lieber draußen verbringe.

Spätestens seit dem aktuellen Mumble-Release der Version 1.4 habe ich die Dokumentation nicht mehr an die Neuerungen angepasst. Und ich werde es aller Wahrscheinlichkeit auch nicht mehr tun. Wer weiß, was die Zukunft bringt, aber aktuell habe ich es nicht vor. Draußen sein ist wichtiger für mich.

Daher habe ich mich heute entschieden, das gar nicht mehr zu versuchen und mit dem Thema “Mumble-Dokumentation” abzuschließen. Ich interessiere mich zwar weiterhin für die Entwicklung des Mumble-Projekts und werde auch immer noch noch davon berichten, nur eben meine Dokumentation nicht mehr pflegen.

Die bestehende Mumble-Dokumentation wird natürlich online bleiben und ich werde die anderen Bereiche meines Wikis auch weiterhin mit Inhalten füllen, nur eben mit anderen. Auch mein Mumble-Server wird online bleiben, auch wenn es in den letzten Jahren immer leerer geworden ist.

In diesem Sinne: Es war schön, hat Spaß gemacht, war sehr viel Arbeit und jetzt sind andere Dinge dran.

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.

Habe trotzdem mein eigenes Wiki erfolgreich auf die neue Version aktualisiert.

Dabei gab es ganz wenige kleine Probleme, die ich in meinem Wiki aufgelistet habe inklusive Lösungen, siehe hier.

Mit dem Plugin Include kann man beliebige Seiten eines Wikis oder Teile davon in andere Seiten einfügen. Ich habe deshalb eine Disclaimer-Seite erstellt und diese danach manuell in alle Wikiseiten eingefügt, in denen es um Produkte geht.

Für den Fall, dass mal jemand in meinem Wiki darüber stolpert, habe ich auch dokumentiert, wie man das selbst in ein Wiki einfügen kann, siehe hier. Denn Dokumentation ist wichtig :)

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.

Alle relevanten Inhalte verschob ich damals in mein “altes” Wiki unter wiki.natenom.de, das DokuWiki nutzt.

Jetzt nach weiteren zwei Jahren habe ich heute das alte Wiki komplett vom Netz genommen. Laut Google Search Console verirrten sich nur noch jeweils unter fünf Benutzer pro Monat auf dieses Wiki.

Ich hätte es einfach dort liegen lassen können, es war nur statisches HTML, aber ich räume gerade auf und es gibt für mich keinen Grund, das online zu lassen, die Inhalte sind ja gesichert.

Somit bleiben noch drei Webseiten von mir, die ich auch in Zukunft aktiv betreiben werde:

• Mein Blog unter natenom.de
• Mein Wiki unter wiki.natenom.de
• Meine Übersichtsseite/Startseite unter www.natenom.com

Ich habe ein lokales Wiki, für das ich meist nur dann den lokalen Webserver anwerfe, wenn ich eine Seite z. B. als PDF exportieren möchte oder die Informationen etwas „schöner“ angezeigt bekommen möchte.

Für alles andere starte ich einfach nur einen Texteditor, der mir die Verzeichnisstruktur anzeigen kann, und mit dem ich Zugriff auf alle Wikiseiten habe.

Dazu gesellt sich noch ein Dateimanager, damit ich auch Dateien in den entsprechenden Unterverzeichnisse im Wiki ablegen kann. Mit dem richtigen Pfad kann man diese auch in Wikiseiten einbetten.

Somit habe ich einen gut struktierten Ort für Notizen, Bookmarks, Erlebnisse und sonstige Informationen.

Vor vielen Jahren habe ich dafür übrigens basket von KDE benutzt. Dieses gibt es mittlerweile nicht mehr bzw. es wird nicht mehr entwickelt.

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

Ohne Plugin:

Und mit Plugin:

Ich habe bereits alle Tasten-Anweisungen im Wiki entsprechend umgeschrieben.

Das Plugin gibt es hier.

Für mein mittlerweile stillgelegtes MediaWiki hatte ich für solche Tastenkombinationen eine eigene Vorlage erstellt.

Doch obwohl ich im Wiki nichts mehr gemacht hatte, musste ich mich doch immer wieder um Sicherheitsupdates für MediaWiki kümmern, auf dem dieses Wiki basiert.

Deshalb wollte ich schon mehrmals dieses Wiki mit Hilfe von wget herunterladen und dann als statische Version nur mit HTML-Dateien wieder hosten. Bei meinen letzten beiden Versuchen, das zu tun, bin ich immer an etwas gescheitert. Heute habe ich es endlich geschafft nach mehreren Stunden Arbeit und daher soll der Ablauf hier hinterlegt sein.

Ausgangspunkt war dieser Blogbeitrag. Jedoch musste ich den Aufruf für mein Wiki etwas anpassen und noch weitere Arbeiten erledigen.

Weiterleitungen temporär deaktivieren

Wichtig bezüglich meines Wikis ist hier der Punkt, dass ich früher bereits viele Seiten manuell in mein Dokuwiki verschoben und auch entsprechende 301-Weiterleitungen gesetzt habe. Deshalb habe ich diese Weiterleitungen temporär entfernt und dann erst die Seite heruntergeladen.

Man könnte sie auch aktiv lassen und stattdessen noch bei wget diesen Parameter nutzen:

--max-redirect 0

Damit würden Weiterleitungen generell ignoriert werden. Mir war es aber wichtig, alle Seiten des Wikis im Archiv zu haben.

wget

Los gehts mit wget:

wget --recursive --domains=wiki.natenom.com --html-extension --page-requisites --convert-links --no-parent -R "*action=*" -R "*printable=*" -R "*oldid=*" -R "*title=Talk:*" -R "*limit=*" "https://wiki.natenom.de/w/Main_Page"

Erklärung der Parameter:

--recursive

Das ganze Wiki soll heruntergeladen werden.

--domains=wiki.natenom.com

Es sollen nur URLs von der Domain des Wikis heruntergeladen werden.

--html-extension

Alle URLs werden in Dateien mit .html am Ende lokal abgespeichert, aus „https://wiki.natenom.de/w/Blaseite“ wird w/Blaseite.html

--convert-links

Alle internen Links werden so konvertiert, dass auf die jeweiligen relativen .html-Dateien verlinkt wird, statt auf Originalwebseite.

-R ...

Überspringt URLs, die bestimmte Strings enthalten, z. B. den Namensraum Talk und weitere.

-erobots=off

Ein Archiv mit der ganzen Webseite

Nach dem Herunterladen des Wikis gibt es im aktuellen Verzeichnis ein neues Verzeichnis mit dem Namen „wiki.natenom.com“.

Dieses wird gepackt und dann auf den Server hochgeladen und ersetzt in Zukunft die dynamische Variante des Wikis.

Für mein Wiki ist das komplette Archiv gerade mal ~60MiB groß.

Weiterleitungen einrichten, damit Links von draußen weiterhin funktionieren

wget hat im erstellen Archiv bereits alle heruntergeladenen URLs in Dateien mit der Endung .html umbenannt und alle vorhandenen Wiki-internen Verlinkungen angepasst. D. h. im fertigen, statischen Wiki enden alle URLs (außer Bilder) auf „.html“.

Wenn jedoch jemand von „außen“ über einen Link auf mein Wiki kommt, würde er ohne die Endung .html keine URL mehr abrufen können, daher muss man sich selbst darum kümmern, dass solche URLs weitergeleitet werden.

Dafür benötigt man eine RewriteRule:

Options +FollowSymlinks

RewriteEngine On RewriteBase / RewriteCond %{REQUEST_URI} !.html$ RewriteRule w/(.*) w/$1.html [R=302,L]

Da es unterhalb von /w/ nur Seiten gibt und keine Grafiken, gibt es auch keine Probleme, dass versehentlich Bilder nach .html umgeleitet werden.

Alle anderen RewriteRules werden aus der alten Konfiguration gelöscht.

Für die anfangs erwähnten 301-Weiterleitungen bereits früher verschobener Inhalte musste ich jetzt noch die URLs anpassen, damit diese auf .html reagieren und diese entsprechend in die neue .htaccess-Datei des statischen Wikis übernehmen.

Z. B. wurde aus:

RedirectMatch permanent ^/w/Android$ https://wikiarchiv.natenom.de/en/android

dieses hier:

RedirectMatch permanent ^/w/Android\.html$ https://wikiarchiv.natenom.de/en/android

Startseite des Wikis verfügbar machen

Jetzt sollte man noch einrichten, dass man die Startseite des Wikis auch dann erhält, wenn man auf die Hauptseite aufruft. Dies erledigt man am besten per Weiterleitung, weil die Startseite sonst mehrfach existiert mit gleichem Content. Jedoch würden dann die relativen URLs nicht passen, weil das /w/ am Anfang fehlen würde.

Daher trägt man in die .htaccess noch ein:

RedirectMatch ^/$ /w/Main_Page.html

CSS verfügbar machen

cd /xxx/htdocs/

cp load.php?debug=false&lang=en&modules=ext.cite.styles%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.sectionAnchor%7Cmediawiki.skinning.interface%7Cskins.vector.styles&only=styles&skin=vector.css “load.php%3Fdebug=false&lang=en&modules=ext.cite.styles%257Cmediawiki.legacy.commonPrint%252Cshared%257Cmediawiki.sectionAnchor%257Cmediawiki.skinning.interface%257Cskins.vector.styles&only=styles&skin=vector.css”

Sitemaps

In meinem Fall musste auch noch das Verzeichnis mit den Sitemaps kopiert werden.

Was nicht funktioniert

Bis auf wenige Seiten sieht alles aus, wie es soll. Hier ist die Liste aller Seiten im Wiki, falls jemand etwas bestimmtes sucht. Die Suche selbst funktioniert natürlich nicht mehr, so wie auch alles andere, was dynamisch generiert wurde, wie z. B. der Namensraum Talk.

Die richtigen Seiten mit Inhalten sind aber alle verfügbar und das war mein Ziel.

Informieren

Für mögliche 404 Fehler im jetzt statischen Wiki habe ich ein eigenes ErrorDocument für den Webserver erstellt, das kurz die Situation erklärt, damit der Besucher weiss, wieso es viele URLs nicht mehr gibt.

Die Datei heißt 404.html und über diese Direktive kann man sie aktivieren:

ErrorDocument 404 /404.html

Navigiert man zu einer URL, die es nicht mehr gibt, dann sieht man das Folgende:

Das lässt sich auch in schön machen, aber mir reicht es aus.

Das wars dann mit MediaWiki

Jetzt muss ich mich nicht mehr um unregelmäßige Updates meines nicht weiter geführten Wikis auf MediaWiki Basis kümmern und muss mir auch keine Sorgen machen, dass es irgendwann eine Sicherheitslücke geben könnte.

Nochmal zur Klarstellung: MediaWiki ist eine tolle Software und man kann sehr viel damit machen. Aus meiner Sicht ist es für einen einzelnen Menschen administrativ aber zu komplex. Deshalb habe ich mich lieber wieder auf mein DokuWiki  unter [wiki.natenom.de][2] konzentriert.

Perfekt :)

Ich hatte geplant dieses in Zukunft als Ersatz für wikiarchiv.natenom.de zu verwenden, welches DokuWiki nutzt.

Vor allem Englisch-sprachige Inhalte sind/(waren) dort zu finden, aber auch einige Deutsch-sprachige.

Hauptgründe für das neue Wiki waren die Möglichkeit, Vorlagen zu verwenden und auch die Erweiterung SemanticMediaWiki. Mit letzterem habe ich mich lange beschäftigt und mit der Zeit auch viele Metadaten im Wiki hinterlegt. Auch einige schöne Vorlagen habe ich selbst erstellt und zu Anfang gefiel es mir sehr gut.

Die Kombination aus MediaWiki und SemantiMediaWiki hat sehr viel Potenzial. Sie ist aber auch sehr komplex. Besonders, wenn es darum geht, die Metadaten in den Wikiseiten zu hinterlegen und sie dann auch im Wiki richtig und schön zu nutzen.

Für große Projekte mit vielen aktiven Benutzern mag das interessant und benutzbar sein, aber für mich alleine ist das nicht zu schaffen, zumindest nicht, wenn ich den Anspruch habe, es einigermaßen gut zu machen.

Es gibt auch noch ein paar andere Dinge, die mir an MediaWiki nicht (mehr) gefallen, aber die werde ich hier nicht ausführen. Wer sie wissen möchte, der kann fragen.

Seit langem habe ich daher auf wiki.natenom.com nichts mehr gemacht und mich vor ein paar Tagen dazu entschlossen, dieses Wiki in den Ruhestand zu schicken.

Es wird weiterhin online bleiben. Aber für alle Inhalte, die in den letzten Tagen in mein DokuWiki verschoben wurden, habe ich Weiterleitungen eingerichtet.

Man wird vermutlich noch die eine oder andere Weiterleitung finden, die noch sehr merkwürdig aussieht. Dies liegt daran, dass ich manche der Seiten nur ins DokuWiki kopiert habe, ohne die Syntax zu ändern. In ein paar Tagen wird alles fertig sein.

Tschüss wiki.natenom.com, ich konzentriere mich jetzt wieder voll auf mein ursprüngliches Wiki unter wiki.natenom.de :)

Habe mich schon vor längerem darüber mit jemandem unterhalten, der diese Probleme aktuell nicht kennt und mir den aktuellen Entwicklungsstand des Move-Plugins angesehen. Da hat sich einiges getan seit 2011.

Mittlerweile soll es sehr gute Dienste tun und bietet sogar Drag&Drop, siehe github.com/michitux/dokuwiki-plugin-move/pull/6.

Und im Gegensatz zu „früher“ kümmert sich das Plugin jetzt auch um die Aktualisierung der Links zu dieser Seite. Habe das erfolgreich getestet bei einer Seite, auf die mehrere andere Seiten verlinken :)

Tipp: Soll trotzdem noch von der alten URL auf die neue weitergeleitet werden, bietet sich das Plugin Redirect an. Vor allem, wenn die alte URL lange existiert hat, sollte man so vorgehen.

Das Plugin gibt es hier.

• www.natenom.com
• natenom.de
• wiki.natenom.de
• wiki.natenom.com
• piwik.natenom.com
• f.natenom.de
• and a few old websites mostly to forward to the new ones

The other domains will follow as soon as whitelisted by Letsencrypt. Got the email today; done :)

The default is still HTTP because nobody except me needs to login on any of my websites and everything is public anyway. After reading this I decided to make HTTPS the default and thus enabled HTTP Strict Transport Security (HSTS) as described in this tutorial :)

The results is an A+ rating on SSLLabs.com :)

WordPress

In this WordPress blog I had to change both „WordPress-Address (URL)“ and „Website-Address (URL)“ to https://…

Then I used the WordPress plugin „Search Regex“ to replace every http://-URL to images in this blog and to my other websites with https://.

Trouble with Piwik

Because of a self hosted Piwik instance I had some trouble and had to do a bit of configuration stuff in order to make https AND http work.

Instead of setting http or https in the Piwik URL one has to set it without a protocol prefix, so instead of  „https://piwik.natenom.com“ or „https://piwik.natenom.com“ set it to „//piwik.natenom.com“.

If the client uses http it will use http for Piwik, too. Same goes for https.

Where to change the Piwik URL:

• MediaWiki:
  $wgPiwikURL in LocalSettings.php
• DokuWiki:
  Admin section -> Configuration -> „plugin -> piwik -> piwik_url“
• WordPress: Don’t know as there were no problems with it :)

In Piwik itself, I also added the https:// URLs to the list of valid URLs of every single website but I don’t know if this was needed.

HTTP/2

While working on the setup of my websites I also enabled HTTP/2 (for https only).

\o/

Z. B. wird in meinem DokuWiki der Eintrag

[[nblog>categories/mumble|Mumble-Kategorie in Natenoms Blog]]

automatisch umgewandelt in

Mumble-Kategorie in Natenoms Blog

Vorteil: Wenn sich die Domain irgendwann ändert, muss man nur den einen Interwiki-Eintrag in der Konfiguration anpassen und nicht jeden Link einzeln.

Mir war das Prinzip von Interwiki zwar vorher schon bekannt, aber ich bin leider erst nach dem manuellen Ändern von Hunderten von Links auf die Idee gekommen, auch für das Verlinken von Nicht-Wiki-Webseiten solche Interwiki-Links zu verwenden.

Vielleicht erspare ich hiermit jemandem unnötige Arbeit :)

Die Dokumentation zu Interwiki-Links gibt es hier für MediaWiki und hier für DokuWiki.

Man sollte aber bedenken, dass je nach Wiki-System solche Interwiki-Links per Voreinstellung – im Gegensatz zu allen anderen Links – kein nofollow-Attribut erhalten (Details siehe hier). Dies lässt sich aber einstellen.

Zum Beispiel hier:

Ohne die Metadaten für „Twitter Cards“ wäre nach dem Link zum Wiki Schluss.

Für DokuWiki benötigt man dafür das Plugin socialcards.

Zusätzlich muss man den „Dienst“ für jede eigene Domain bei Twitter aktivieren; wie das genau geht, ist hier beschrieben.

Enthalten im Update sind diverse Bugfixes, die Unterstützung von externen Audio- und Videoquellen und eine coole History-Funktion.

Alle Änderungen stehen im Changelog.

Neue History-Funktion

Natürlich war es bisher auch möglich, den alten Status einer Seite anzusehen, jedoch nur von jeweils einzelnen Seiten. Mit der neuen History-Funktion kann man sich das gesamte Wiki eines bestimmten Zeitpunktes anzeigen lassen. Klickt man auf einen Wiki-internen Link innerhalb einer Seite, so wird auch davon die ältere Version angezeigt.

Ausgenommen sind jedoch Dinge wie das Indexmenü in meinem Wiki oder auch automatisch generierte Listen von Seiten, die immer aktuell sind.

Für die neue Funktion gibt es kein Frontend, man muss manuell den Parameter ?at=DATUMSANGABE an die URL anfügen.

Es können Datumsangaben verwendet werden, die von der PHP-Funktion strtotime verstanden werden, z. B. auch „-2 years„.

Ein paar Beispiele sind hier dokumentiert.

Z. B. kann man sich die Seite über Mumble im Wiki vom Stand 30.03.2010 mit folgender URL ansehen:
wikiarchiv.natenom.de/mumble?at=2010-03-30

Oder die Startseite des Wikis wie sie vor drei Jahren aussah:
wikiarchiv.natenom.de/?at=-3 years

Existierte eine anzuzeigende Seite zu einem gewählten Zeitpunkt noch nicht, so wird angezeigt, wann sie erstellt wurde.

Upgrade

Mit dem Upgrade-Plugin für DokuWiki kann man das Upgrade über das Admininterface das Wikis selbst mit wenigen Klicks erledigen.

Das eigene Wiki ist jetzt auf dem aktuellen Stand, Probleme beim Upgrade gab es keine.

Nützliches zu DokuWiki

Siehe hier.

Da ich mich gerade damit beschäftigt habe, hier eine Liste der Möglichkeiten für die drei genannten Systeme, nofollow komplett oder gezielt zu deaktivieren:

• DokuWiki * Hier kann man nofollow nur für alle Links im Wiki deaktivieren, über die Einstellung relnofollow.
  •  MediaWiki
    • Über die Einstellung $wgNoFollowDomainExceptions kann man Domainnamen angeben für die das nofollow-Tag nicht gesetzt wird, per Voreinstellung ist hier nur mediawiki.org aufgeführt.
    • Bei Interwiki-Links wird generell kein nofollow gesetzt.
    • Ganz abschalten lässt sich nofollow über die Einstellung $wgNoFollowLinks.
  • WordPress
    • Es gibt mehrere Plugins, die nofollow entweder für bestimmte oder für alle Teile des Blogs deaktivieren; siehe hier für Details.

Habe mir zum Thema noch kein abschließendes Urteil gebildet und bisher z. B. im Wiki (en) nur bestimmte Domains von nofollow ausgeschlossen. Da aber bis auf den Kommentarbereich hier im Blog auf allen Seiten jeder Link von mir eingefügt wird, ist es vermutlich sinnvoller, nofollow nicht zu verwenden.

Mal sehen…

Die Lösung gibt es in den Kommentaren des Bugreports, siehe hier. Es gibt je ein Vorkommen beider Strings in der genannten Datei und die Anführungszeichen gehören dazu.

Weitere Informationen zum Plugin gibt es hier und zum DokuWiki-Update hier.

Videounterstützung

Es ist mit dem neuen DokuWiki möglich, hochgeladene Videos einzubetten und mit dem mitgelieferten Player abzuspielen. Es werden die Formate .ogv, .mp4 und .webm unterstützt.

Hier in der Seite eingebettet:

[][3]

Und hier im Vollbildmodus:

[][4]

Zu sehen ist übrigens dieses Video.

Zum selbst ausprobieren, [siehe hier][6]. Je nach Browser funktioniert nicht alles.

Audiounterstützung

Auch Audiodateien lassen sich ins Wiki hochladen und einbetten, es werden .ogg, .mp3 und .wav unterstützt.

[][7]

Zum selbst ausprobieren, [siehe hier][6]. Auch hier funktioniert je nach Browser nicht alles.

Erweiterungen verwalten

Einer meiner Wünsche wurde erfüllt und es gibt eine ordentliche Verwaltung für Plugins und Templates (Skins). Dort kann man auch nach existierenden Plugins suchen und diese direkt installieren, so wie z. B. auch in [WordPress][8]. Auch wird angezeigt, ob es neue Versionen gibt.

Plugins verwalten:

[][9]

Templates (Skins) verwalten:

[][10]

Plugins suchen und installieren:

[][11]

Händisch installieren:

[][12]

Ansicht der „Versionsgeschichte“ verbessert

Lässt man sich zwei Zustände in der Versionsgeschichte einer Seite anzeigen, so kann man für beide unabhängig voneinander zur nächsten bzw. vorherigen Revision blättern und bekommt dann interaktiv die Unterschiede der beiden Zustände angezeigt:

[][13]

Damit kann man vermutlich leichter den Zeitpunkt bestimmter Änderungen finden. (?)

Namen

Mit der neuen Variable [showuseras][14] lässt sich einstellen, wie der Name des Nutzers angezeigt werden soll, der zuletzt eine Seite bearbeitet hat (rechts unten auf einer Seite); entsprechend wird auch die Anzeige in der Versionsgeschichte angepasst. Dafür gibt es die folgenden Möglichkeiten:

[][15]

Upgrade durchführen

Habe das Upgrade des eigenen Wikis übrigens wieder mit dem Plugin [Upgrade][17] durchgeführt und es hat wunderbar funktioniert. Wie immer muss man selbst getätigte Änderungen erneut einfügen, wie z. B. [diese hier][18].

\o/

Die komlette Liste der Neuerungen gibt es auf der Projektseite von DokuWiki, [siehe hier][19].

Eine Beschreibung von DokuWiki gibt es [hier][20].

Das verwendete DokuWiki Logo stammt von hier und ist unter der GPL lizenziert.

[6]: https://wiki.natenom.de/docs/sammelsurium/dokuwiki/updates/ponder_stibbons “DokuWiki Update/Upgrade auf “Ponder Stibbons” [Natenom´s Wiki]” [7]: /wp-content/uploads/2014/05/dokuwiki_update_2014_ponder_stibbons_audio_support.png [8]: /tags/wordpress “Wordpress hier im Blog” [9]: /wp-content/uploads/2014/05/dokuwiki_update_2014_ponder_stibbons_extension_manager.png [10]: /wp-content/uploads/2014/05/dokuwiki_update_2015_ponder_stibbons_extension_manager_templates.png [11]: /wp-content/uploads/2014/05/dokuwiki_update_2016_ponder_stibbons_extension_manager_search_and_manage.png [12]: /wp-content/uploads/2014/05/dokuwiki_update_2017_ponder_stibbons_extension_manager_by_hand.png [13]: /wp-content/uploads/2014/05/dokuwiki_update_2014_ponder_stibbons_version_history.png [14]: https://www.dokuwiki.org/config:showuseras “config:showuseras [DokuWiki]” [15]: /wp-content/uploads/2014/05/dokuwiki_update_2014_ponder_stibbons_showuseras.png [17]: https://www.dokuwiki.org/plugin:upgrade “plugin:upgrade [DokuWiki]” [18]: https://wiki.natenom.de/docs/sammelsurium/dokuwiki “Nützliches zu DokuWiki [Natenom´s Wiki]” [19]: https://www.dokuwiki.org/changes “changes [DokuWiki]” [20]: https://www.dokuwiki.org/dokuwiki “dokuwiki [DokuWiki]”

Dies möchte ich im eigenen Wiki vermeiden und habe deshalb selbst Templates erstellt, die hier kurz vorgestellt werden; teilweise sind diese an die Funktionalität bestimmter Plugins im eigenen, seit Jahren verwendeten DokuWiki (DW) angelehnt.

Wer möchte, kann diese Templates in sein eigenes Wiki übernehmen.

Box begin und Box end – Ersatz für das WRAP-Plugin

Siehe unter /w/Template:Box_begin. Es gibt auf der Seite viele Beispiele mit verschiedenen Einstellungen.

Hier ein Auszug der verschiedenen Typen:

WikiTeaser

Im eigenen DokuWiki gibt es auf der Startseite eine Übersicht der Hauptthemen mittels des Plugins DokuTeaser, im MW wurde der Ersatz WikiTeaser genannt, siehe hier.

Video link

Dies ist eine kleine Box mit einem Display-Symbol und dem Video Link. Hier möchte ich später noch eine optionale Einbettung hinzufügen, mal sehen.

Software information box

Hier habe ich mich komplett am Aussehen der „Infobox software“ von Wikipedia orientiert und gerade diese war einer der Hauptgründe, mich mit MW zu beschäftigen. In meinem Fall ist die Infobox absolut unkomplex – im Gegensatz zum Original – welches mehrere Dutzend Abhängigkeiten hat, wie man hier sehen kann. Hier könnte man vielleicht noch einige der Punkte optional machen, da jedes Software-Paket, um das es im eigenen Wiki geht, andere wichtige Punkte beinhaltet, die in dieser Box genannt werden sollten. Trotzdem gefällt mir das des Templates schon ziemlich gut, auch wenn der Quelltext noch unschön ist.

Hier gehts zum Template.

Anker – sehr wichtig

Von DW bin ich es gewohnt, mittels des Plugins Anchor an beliebigen Stellen sogenannte Anker zu setzen, die man dann von woanders direkt anspringen kann, auch ohne eigene Überschrift. Statt mit einem „a“ Tag zu arbeiten nutzt man dafür bei MW das „id“ Tag, siehe hier.

Hier ist das Template.

Indexmenu

Dieses Template zeigt alle Unterseiten eines bestimmten Pfades als Liste an, siehe hier. In Anlehnung an das gleichlautende, sehr mächtige Plugin von DW.

Es ist aber in einem MW vermutlich eher nicht sinnvoll, über Pfade bzw. Verzeichnisse etwas zu strukturieren; habe dies zu Beginn jedoch teilweise getan.

IndexCategory

Wie Indexmenu, jedoch wird mittels der Extension DynamicPageList eine Liste aller Seiten einer bestimmten Kategorie erstellt.

Siehe hier.

Shortcut

Dies wird genutzt, um im Wiki einen Shortcut besser zu kennzeichnen, indem vor der Tastenkombination ein Tasten-Symbol angezeigt wird. Später könnte man hier noch bestimmte Tasten wie Ctrl oder Alt durch entsprechende Grafiken ersetzen.

Hier ist das Template.

\o/

Passt bisher, es werden aber noch mehr Templates folgen…

Im weiteren Text werden für beide Wikis nur noch Abkürzungen verwendet, DW für DokuWiki und MW für MediaWiki.

Editor

Der als Erweiterung mitgelieferte Editor WikiEditor bietet nur die wichtigsten Elemente an, wie auch der Editor in DW; macht aber nichts, schließlich kann man sich an die neue Syntax ziemlich schnell gewöhnen.

Syntax-Highlighting von Haus aus gibt es in keinem der Wiki-Systeme. Für DW kann man sich dafür z. B. den Ace-Editor installieren.

Für MW bietet sich wikEd an. Es gibt mehrere Möglichkeiten, diesen Editor System-weit, pro Benutzer, etc. zu installieren, siehe hier. Den WikiEditor benötigt man dann nicht mehr und kann diesen in LocalSettings.php deaktivieren.

Das Ergebnis sieht zwar etwas altbacken aus, aber dafür gibt es viele nützliche Funktionen:

[][8]

Durch das Script von wikEd werden externe Daten im Wiki eingebunden, auch wenn man das Wiki nur betrachtet. Daher sollte man aus Datenschutzgründen die Installation pro Benutzer vorziehen. Hierfür muss die Einstellung wgAllowUserJs aktiviert werden.

Wer einen WYSIWYG-Editor benötigt kann sich z. B. den noch in der Beta-Phase befindlichen VisualEditor installieren. Dann muss aber zusätzlich noch ein Daemon namens Parsoid auf dem Webserver installiert werden.

Responsive Design

Der Standard-Skin namens Vector ist nicht „responsive„, d. h. die Anordnung der Elemente ändert sich nicht auf kleinen Bildschirmen von Mobilgeräten; bei DW ist dies Standard.

Als umständliche Lösung kann man auf die Erweiterung MobileFrontend zurückgreifen, die über PHP anhand des User Agents herausfindet, ob es sich um ein Mobilgerät handelt. Ist dies der Fall, wird die mobile Variante des MediaWikis angezeigt, die man auch von Wikipedia.org kennt:

[][16]

Alternativ können Benutzer selbst die mobile Variante aufrufen.

In der Liste der verfügbaren Skins gibt es nur einen, der als „stable“ gekennzeichnet und „responsive“ ist, dieser hier.

Navigationsbaum

Am meisten fehlt mir eine Art Navigationsbaum, wie z. B. Indexmenu von DW. Hier konnte ich bisher nur die Erweiterung TreeandMenu finden, habe mich aber noch nicht weiter damit beschäftigt.

Tags

Von DW kenne und nutze ich gerne sogenannte Tags, die es z. B. auch in WordPress gibt. Dadurch lassen sich gleichartige Artikel sehr gut gruppieren. Bei MW gibt es diese Funktionalität gar nicht.

Kategorien

Dafür kann man in MW Seiten mittels Kategorien gruppieren, die es wiederum in DW nicht gibt bzw. nur sehr umständlich.

Wie man eine sinnvolle Struktur mit Kategorien aufbaut hat sich mir noch nicht offenbart, vielleicht kommt das noch nach dem Studium der umfangreichen Dokumentation. Hier gibt es ein paar Überlegungen dazu.

Es gibt auch Unterkategorien, siehe hier.

Eine interessante Erweiterung für Kategorien ist CategoryTree.

Templates / Vorlagen

Einer der gewichtigsten Gründe, wieso ich mich mit MW beschäftigen wollte, sind Templates. Diese arbeiten im Prinzip wie eine Funktion, der man Werte übergeben kann. Die Ausgabe erscheint dann an der Stelle, an der das Template in anderen Seiten verwendet wird.

Mit Templates hat man ein gutes Mittel, um z. B. Infoboxen zu erstellen, Videos einzubetten usw. In DW wird dafür je ein eigenes Plugin benötigt.

Es gibt zwei Möglichkeiten, um an Templates zu kommen…

Möglichkeit 1 – Templates aus anderen Wikis exportieren

Über die Export-Funktion von MW kann man sich prinzipiell aus jedem MW die gewünschten Templates exportieren und in das eigene Wiki importieren. Dies funktionert optional mitsamt Abhängigkeiten von anderen Templates und Modulen ziemlich gut. Es fehlen jedoch Style Sheets (CSS), JavaScript und Bilder. Diese muss man sich selbst besorgen. Vielleicht geht es doch und ich habe es nur nicht gefunden.

Mitsamt Abhängigkeiten importiert man z. B. für das Template Infobox von Wikipedia eben mal um die 50 weitere Templates und Module, um in meinem Fall festzustellen, dass es am Ende doch nicht funktioniert. Schade, denn dieses Template war einer der Gründe, dass ich mich näher mit MW beschäftigen wollte.

Möglichkeit 2 –Templates selbst erstellen

Wegen der Problematik mit den Abhängigkeiten bin ich ziemlich schnell dazu übergegangen, Templates selbst zu erstellen. Das bedeutet jedoch ziemlich viel Arbeit und ich habe diesbezüglich noch Einiges vor mir.

Man kann es durchaus als Vorteil ansehen, wenn man sein Wiki dadurch individueller gestalten kann, z. B. mit an das Wrap-Plugin angelehnten Boxen:

[][31]

Die verwendeten Icons stammen übrigens vom Oxygen Projekt (siehe hier).

Programmierung

Ist die Erweiterung ParserFunctions installiert, kann man sogar aus der Programmierung bekannte Dinge wie if, switch und mehr verwenden – in Templates und auch in normalen Seiten. Noch mehr Möglichkeiten erhält man durch die Erweiterung Scribunto, mit der es möglich ist, die Scriptsprache Lua zu nutzen.

Verschieben

Mir gefällt es, dass beim Verschieben von Inhalten per Voreinstellung eine Weiterleitung von der alten Position zur neuen erstellt wird, egal ob man Seiten, Templates oder Dateien verschiebt bzw. umbenennt. In DW muss man dazu die Ursprungsseite löschen, die Zielseite erstellen und dann z. B. mit dem Plugin Redirect eine Weiterleitung einrichten. (Für experimentierfreudige Menschen gibt es für DW ein in Entwicklung befindliches Plugin namens Move, siehe hier.)

Mit Dateien arbeiten

Habe mir für DW öfters die Möglichkeit gewünscht, bestimmte Informationen direkt an die Datei zu binden; in MW geht dies, da letztlich die Übersichtsseite einer Datei auch nur eine normale Seite ist. Außerdem sieht man dort auch, auf welchen Seiten die Datei verwendet wird.

Was mir gar nicht gefällt ist die Tatsache, dass alle hochgeladenen Dateien aus Wiki-Sicht in demselben Pfad liegen (auf dem Server natürlich nicht). Es ist nach meinem aktuellen Kenntnisstand nicht möglich, Dateien über Verzeichnisse zu strukturieren. Das bedeutet, dass jeder Dateiname eindeutig im gesamten Wiki sein muss. (Habe ich da etwas übersehen?)

SpecialPages

Im Bereich „Special:SpecialPages“ findet man Vieles, was man in DW nur teilweise über Plugins realisieren kann, z. B. Listen von ungenutzen Dateien, gewünschten (weil in einer Seite verwendeten aber nicht existierenden) Seiten, sehr kleinen Artikeln, Seiten ohne Kategorie usw.

Upgrade

Ein Upgrade ist bei MW etwas aufwendiger, siehe hier. In DW lässt sich das gesamte Update mittels des Plugins Upgrade im Interface selbst erledigen.

Update: Mit dem richtigen Weg per Patchfile lässt sich ein MW sehr viel einfacher upgraden als ein Dokuwiki; habe das erst später erfahren dürfen :)

Feeds

In MW lässt sich bei Ansicht der Versionsgeschichte jeder Seite über das kleine RSS-Symbol in der Toolbox ein eigener Feed abrufen:

[][42]

In DW geht das zwar auch, jedoch nur umständlich, da man sich den URL für den Feed selbst zusammenstellen muss, wenn man nicht das ganze Wiki beobachten möchte, siehe hier.

Änderungen an CSS und JS

In DW muss man für Änderungen am Design die entsprechenden CSS- oder JavaScript-Dateien direkt auf dem Webserver bearbeiten. In MW dagegen lässt sich dies im Wiki selbst erledigen (z. B. im Bereich „MediaWiki:Vector.css“) und man erhält dadurch auch eine Versionierung der Dateien; das gefällt mir sehr gut.

\o/

Habe ich schon gesagt, dass ich MediaWiki und DokuWiki mag?

Passt.

Da bestimmt noch mehr zu MediaWiki kommen wird, gibt es jetzt eine neue Kategorie hier im Blog.

Die beiden Icons im Artikelbild stammen von hier und hier.

Deshalb verwendet ich schon sehr lange das Plugin „Ace Editor“ von „Albert Gasset“, das beim Bearbeitung von Inhalten zwar immer noch den Quelltext anzeigt, den Bearbeiter jedoch mit Syntax-Highlighting, Farbschemata, Tastenkürzeln und neuen Funktionen unterstützt.

Änderungen im Editor

• Links sind unterstrichen und die Link-Beschreibungen werden farbig dargestellt
• Die aktuelle Zeile wird hervorgehoben
• Zeilennummern werden angezeigt
• Verbesserungen beim Bearbeiten von Tabellenstrukturen, siehe unten

Farbschemata

Verwende selbst das Farbschema „Terminal“, welches zusätzlich noch den Hintergrund des Editors dunkel darstellt; es gibt viele weitere Farbeschemata, die man über die Einstellungen des Plugins aktivieren kann.

Vergleich

Hier zwei Screenshots, erst mit dem Standard-Editor von DokuWiki, dann mit dem „Ace Editor“:

[][4]

[][5]

Sehr viel übersichtlicher – vorausgesetzt man kennt die Syntax :)

Der neue Editor lässt sich beim Bearbeiten jederzeit über das kleine Wolken-Icon rechts unten deaktivieren.

Die Einstellungen, die man rechts unten ändern kann, werden übrigens per Cookie gespeichert.

Tastenkürzel

Interessant sind ein paar Tastenkürzel, von einige leider einige nicht nutzbar sind, da sie bereits vom Browser verwendet werden. So z. B. [Strg]+[R], was schade ist, da man damit „Suchen und Ersetzen“ nutzen könnte. Habe für Firefox schon diverse Addons ausprobiert, mit denen es möglich sein soll, Tastenkürzel zu deaktivieren – bisher hat keines davon funktioniert.

Update: Wenn man zweimal [Strg]+[F] nacheinander drückt, erreicht man auch den Ersetzen-Dialog.

Nutze z. B. folgende Tastenkürzel:

• [Strg] + [L] – springe zu einer bestimmten Zeilennummer
• [Strg] + [D] – löscht die aktuelle Zeile
• [Strg] + [T] – vertauscht die Positionen der beiden Buchstaben, zwischen denen sich der Cursor aktuell befindet

Andere genannte Tastenkürzel in der Referenz funktionieren dagegen mit allen Editoren und sind Standard.

Etwas nervig ist zu Beginn die geänderte Funktionsweise von [Strg]+[Cursor links] und [Strg]+[Cursor rechts], hier springt der Cursor normalerweise zum Ende/Anfang des letzten/nächsten Wortes. Beim Ace-Editor wird das Ende eines Wortes, dann der Anfang des nächsten Wortes angesprungen, usw. Die Navigation mit diesen Tastenkürzeln dauert deshalb etwas länger; aber daran gewöhnt man sich.

Unterstützung in Tabellen

Beim Bearbeiten von Tabellen gibt es zusätzliche Tastenkürzel, die sehr hilfreich sind. Abgesehen davon werden Tabellen schön formatiert dargestellt, wenn man über das kleine Pfeil-Symbol rechts unten den automatischen Zeilenumbruch deaktiviert:

[][8]

Ist die Tablle noch normal zu sehen, reicht das Drücken der [Enter]-Taste innerhalb einer Zelle aus, um die verbesserte Ansicht zu erhalten.

Ganz besonders zu empfehlen sind die Tastenkürzel [Alt]+[Cursor links] und [Alt]+[Cursor rechts], mit denen man die Reihenfolge von Spalten ändern kann; mit solche „kleinen“ Änderungen ist man sonst ewig beschäftigt.

Erweiterte Suche

Die Suchfunktion ([Strg]+[F]) ermöglicht eine normale Suche, eine nach Regulären Ausdrücken, einem ganzen Wort oder unterschieden nach Groß-/Kleinschreibung.

[][9]

Einstellungen

[][10]

\o/

Das Plugin gibt es hier; es funktioniert mit der aktuellen Version „Binky„.

Sehr zu empfehlen :)

[][2]

Dieser kommt vom Plugin DW2PDF; früher musste man selbst dafür sorgen, irgendwo solch einen Button zu erzeugen, seit DokuWiki „Binky“ vom Dezember 2013 können Plugins auch eigene Buttons in die Pagetools eintragen.

Sehr schön :)

BTW: Wäre schön, wenn DokuWiki die Möglichkeit bieten würde, alle Plugins regelmäßig selbständig zu aktualisieren…

Was nicht hilft…

Nach dem Löschen des DokuWiki-Caches (auf dem Server) wird nur beim ersten Aufruf die richtige Version angezeigt, dann wieder die falsche.

Auch das „ungültig machen“ des gesamten Caches im Wiki (siehe hier) hilft nur beim ersten Aufruf.

Beim Anhängen von „?purge=true“ an die Adresse wird einmalig die richtige Version angezeigt, beim erneuten Aufruf ohne den Anhang jedoch wieder die alte.

Die Lösung

Die Lösung bringt das Löschen der zur Seite gehörenden .meta-Datei im Verzeichnis „/data/meta„.

Ob dadurch irgendwelche Informationen verlorengehen, hat sich mir noch nicht erschlossen. Bisher sieht alles gut aus und in der Liste der gespeicherten Metadaten sehe ich nichts, was nicht erneut aus bestehenden Daten generiert werden kann.

Alternativ lässt sich auch ein „NOCACHE“ in die Seite einfügen; dies ist jedoch nicht sehr performant.

Infos zu Metadaten

Hintergrundinformationen zu den Metadaten eines DokuWiki gibt es hier und hier.

Eigenschaften des Plugins:

• Der Slider verwendet immer die volle zur Verfügung stehende Breite, man kann jedoch z. B. einen WRAP-Container mit verringerter Breite nutzen
  • Werden verschiedene hohe Bilder verwendet, muss man beachten, dass das erste Bild in der Reihe die maximale Höhe des Sliders bestimmt
  • Klickt man auf ein bestimmtes Bild oder auf die Navigation, so bleibt das aktuelle Bild stehen
  • Für jede „Seite“ gibt es am unteren Rand je ein Symbol zum direkten Anspringen

Im Wiki gibt es eine kleine Demo-Seite dazu: https://wiki.natenom.de/docs/sammelsurium/dokuwiki/slider.

Die Anleitung dazu gibt es hier: https://www.dokuwiki.org/tips:topbar.

Die Seite topbar muss sich auf der Hauptebene befinden, kann jedoch bei Verwendung von Indexmenu in den Einstellungen ausgeblendet werden (skip_file).

Bei einer Breite des Browserfensters unter 480 Pixel verschiebt sich die Leiste ans untere Ende der Seite.

Das, was vorher im Wiki links in der Seitenleiste war befindet sich nun in der Leiste oben:

[][3]

Vielleicht kann man auch versuchen, die Leiste so umzustellen, dass sie beim Herunterscrollen mitgenommen wird, die gesamte Breite verwendet usw., mal sehen…

Die Startseite auf DokuWiki.org z. B. gefällt mir sehr gut und diesen Blockaufbau wollte ich im eigenen Wiki auch haben. Man verwendet dort ein eigenes Plugin namens DokuTeaser, welches unter der GPL lizenziert ist und das von GitHub heruntergeladen werden kann. Das Plugin wurde zwar für die interne Verwendung auf der DokuWiki Web-Seite entwickelt und es gibt keinerlei Einstellungen, jedoch passt es genau auf die Bedürfnisse im eigenen Wiki.

Nach der Installation des Plugins kann man um jeden zukünftigen Block diese Tags setzen:

<dokuteaser>...</dokuteaser>

URLs im Text selbst sollte man nicht verwenden, da diese immer in einer eigenen Zeile angezeigt werden. Listen mit Links sind kein Problem. Bilder sollten rechts ausgerichtet werden, da bei linker Ausrichtitung z. B. Listenpunkte zu nahe an den Grafiken sind. Die letzte URL innerhalb eines Blocks wird rechts ausgerichtet.

Hier der Vergleich, zuerst die alte Startseite

[][5]

und die neue

[][6]

Das sieht sehr viel besser aus.

Passt :)

Zur Installation von neuen Themes öffnet man unter Administration im Bereich „Weitere Plugins“ die „Indexmenu Werkzeuge“ und klickt auf den „Anzeigen“-Button der unteren Zeile. Dadurch werden für jedes vorhandene Thema die Icons/Symbole angezeigt:

Hier kann man neue Themen direkt installieren.

Bei der Verwendung des Plugins gibt man dann noch das neue Thema in der Syntax mit an; z. B.:

{{indexmenu>..#1|js#human.png navbar tsort nsort notoc noscroll}}

Da die Icons alleine noch keinen Eindruck machen, habe ich in einer Testseite die für mich interessanten Themen eingebunden:

Habe mich letztlich für das zweite Thema (indextheme) entschieden.

Die Hervorhebung der aktuell geöffneten Seite im Indexmenü lässt sich übrigens nicht einstellen sondern bedarf einer kleinen Änderung im CSS, siehe hier.

Habe selbst vor ein paar Tagen festgestellt, dass es ziemlich nervig ist, hier bevormundet zu werden. Dazu kommt, dass man so die „Zurück-Funktion“ des Browsers sinnvoll nutzen kann.

Wie ein Link geöffnet wird, entscheidet das Attribut target, siehe unter http://www.w3schools.com/tags/att_a_target.asp.

Es folgt eine Liste der Dienste und wie die Umstellung bei diesen funktioniert.

DokuWiki

Es reicht aus, unter Konfiguration -> Link-Konfiguration den Wert von target>extern auf „_self“ oder einen leeren Wert zu setzen:

[][2]

WordPress

Hierfür gibt es ein gutes Plugin namens Search-Regex, mit dem man Suchen und Ersetzen kann. Dann dauert das Ganze ca. 1 Minute. Man ersetzt dann einfach die Zeichenkette ‚target=“_blank“‚ durch ‚target=“_self“‚, was die Standardeinstellung für das Öffnen von Links ist.

Ohne dieses Plugin müsste man jeden Artikel öffnen und bei den „Link einfügen“-Eigenschaften den Haken bei „Link in neuem Fenster oder Tab öffnen“ entfernen.

Gallery3

Bei Gallery3 muss man nichts ändern, es ist bereits per Voreinstellung alles so eingerichtet, dass Links im aktuellen Fenster/Tab geöffnet werden.

PDF-Export

Habe leider erst gestern bemerkt, dass seit der Umstellung der Link zum exportieren der aktuellen Seite in eine PDF-Datei fehlte.

Auf der Web-Seite des dw2pdf-Plugins steht zwar beschrieben, wie man den PDF-Export-Button/-Link einfügt, diese Methode funktionierte allerdings nicht, da immer nur die Startseite exportiert wurde, egal wo im Wiki man sich befunden hat.
Daher wurde ein einfacher Link unter das Indexmenü in die sidebar gepackt:

<html><img src='/lib/images/fileicons/pdf.png'> <a href='?do=export_pdf'>Aktuelle Seite als PDF exportieren</a></html>

Und das Ergebnis:

site_notice

Auch ist mir direkt nach der Umstellung des Templates nicht aufgefallen, dass die von monobook bekannte site_notice nicht im neuen Template verfügbar ist. Wenn benötigt, kann man diese Leiste selbst erstellen und z. B. in die Datei lib/tpl/dokuwiki/pageheader.html packen, damit sie im Hauptbereich angezeigt wird, direkt über der Seitenüberschrift auf Höhe des Inhaltsverzeichnisses. Um die Leiste jedoch vom Inhalt visuell zu trennen, wurde sie später in die Datei _lib/tpl/dokuwiki/header.html _verschoben, und befindet sich damit ganz oben auf der Seite:

Bilder

Bilder werden übrigens automatisch verkleinert, wenn das Browser-Fenster kleiner wird. Das war mir damals noch nicht bekannt, sollte aber unbedingt noch erwähnt werden.

\o/

Insgesamt ist das neue Standard-Template immer noch sehr sehr angenehm fürs Auge und es macht Spass, damit zu arbeiten :)

Vorteile

Einige Vorteile des neuen Templates gegenüber monobook:

• Angepasste Ansichten für mobile Geräte, siehe unten

  • Rechts am Rand befindet sich eine Leiste, die mitscrollt und sich somit immer auf derselben Höhe befindet. Sie beinhaltet folgende Links:

    

    Wenn man angemeldet ist, kann man die „Seite bearbeiten“ und die „Aboverwaltung“ öffnen.

  • Rechts neben dem Logo können ein Titel und ein Slogan (tagline) angezeigt werden
  • Suche und andere Tools sind rechts oben erreichbar

  Anpassungen allgemein

  Informationen zu Anpassungen am Template gibt es unter https://www.dokuwiki.org/template:dokuwiki.

  Neue Farben

  Per Voreinstellung sind im Text verwendete Links, die auf Seiten innerhalb des Wikis verlinken, grün und externe Links blau. Externe Links haben vorne ein entsprechendes URL-Symbol.

  Habe jedoch die internen Links wieder auf blau gesetzt, wie sie auch bei monobook waren.

  Änderungen an CSS und JavaScript

  Die bisher im Wiki verwendeten Änderungen müssen für das neue Template etwas angepasst werden; die Informationen dazu sind im Wiki hinterlegt, siehe unter:

  • Lange Seitennamen in der Navigation anzeigen
  • Aktuelle Seite in der Navigation hervorheben
  • Nummerierte Überschriften

  Mehr Breite

  Statt der festen Breite kann man auch die volle Breite des Browsers nutzen, siehe unter DokuWiki-Template – ganze Breite nutzen.

  Seiten-Notiz

  Um wie auch in monobook eine kleine Seiten-Notiz (wiki/site_notice) anzuzeigen, wird innerhalb von lib/tpl/dokuwiki/ eine Datei namens pageheader.html erstellt und mit Inhalt befüllt; dieser wird dann in jeder Wiki-Seite angezeigt.

  Kleine Bildschirme

  Das neue Template sieht auch auf kleinen Displays richtig gut aus. Vielen Dank an Darcade für die drei folgenden Screenshots (dort steht noch 0.1 Inhaltsverzeichnis, der Fehler ist mittlerweile behoben).

  Im bisherigen monobook-Template nahm z. B. auf einem kleinen Monitor die Navigation den größten Teil des Bildschirms ein:

  [][2]

  Beim neuen Standard-Template „DokuWiki“ wird bei Unterschreitung einer bestimmten Mindestbreite die Sidebar mit der Navigation nach oben versetzt und das Inhaltsverzeichnis darunter, jeweils eingeklappt:

  [][3]

  Navigation/Sidebar und Inhaltsverzeichnis lassen sich getrennt einblenden/ausblenden:

  [][4]

  Große Bildschirme

  Und hier Vergleichsbilder auf einem Monitor mit Full-HD-Auflösung, zuerst das alte Template:

  [][5]

  Und das neue Template:

  [][6]

  Passt

  Insgesamt ist das Aussehen des neuen Templates sehr angenehm, passt :)

  http://wiki.natenom.de.

Die komplette Liste der Änderungen gibt es unter www.dokuwiki.org/changes.

Zwei interessante Änderungen sind:

• Ein neues, HTML5 konformes, Standard-Template mit Unterstützung für mobile Geräte
  • Das Inhaltsverzeichnis und die Suchergebnisse wurden verbessert

Das Template Monobook wurde bereits aktualisiert.

Habe unser Wiki auch bereits mit dem Upgrade-Plugin aktualisiert. Damit die verwendete Überschriftennummerierung wieder passt und „Inhaltsverzeichnis“ nicht „0.1 Inhaltsverzeichnis“ heißt, muss man folgende Zeile in die Datei lib/tpl/monobook/user/style.css eintragen:

div#content div#dw__toc h3:before{content:""}

Danke an den Unbekannten für diese Zeile :)

Weitere Probleme gab es beim Upgrade nicht.

Ansonsten beginnt die Nummerierung sowohl im Inhaltsverzeichnis als auch im Text erst bei der zweiten Ebene (h2); der Seitenname steht also für sich.

Hier ein Screenshot:

Das entsprechend angepasste CSS-Konstrukt gibt es hier.

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.

Um die Ausgabe dieses Plugins zu erhalten, erstellt man eine Seite mit folgendem Inhalt:

~~NOCACHE~~

~~ORPHANSWANTED:all~~

Auf dieser Seite werden dann folgende Informationen angezeigt:

• Orphans – Seiten, die nicht verlinkt sind.
  Im Wiki sind dies sehr viele, was aber auch daran liegt, dass z.B. Links in generierten Indexseiten (mittels indexmenu oder pagequery) nicht mitgerechnet werden.
• Wanted – Seiten, auf die zwar verlinkt wird, die aber noch nicht existieren.
  Dieser Abschnitt ist z.B. hilfreich, wenn man die Struktur eines Wikis verändert.
• Valid – Anzahl der gültigen Links zu einer existierenden Seite mit der Möglichkeit, diejenigen Seiten anzuzeigen, in denen verlinkt wird.

Ich war doch sehr überrascht, wie viele Seiten nicht verlinkt waren (ca. 180); mittlerweile sind es nur noch ca. 140. Der Rest wird auch noch stärker verknüpft werden :)

Z. B. bewirkt

<sortable r2 1=numeric 2=alpha 3=nosort>
^ Spalte 1 ^ Spalte 2 ^ Spalte 3 ^
| 5 | bla | beliebigsdf |
| 3 | blup | sdf2lkjdi |
| 1 | blau | ssadf3jdssdi |
</sortable>

, dass  die Tabelle anhand der zweiten Spalte umgekehrt sortiert wird. Interaktiv kann ein Benutzer auch nach der zweiten Spalte sortieren lassen, nicht jedoch nach der dritten. Dabei wird die erste Spalte numerisch, die zweite Spalte nach Text sortiert.

[][1]

Wie der Name vermuten lässt, muss JavaScript aktiviert sein, damit sortiert wird.

Sinnvolle Beispiele für sortierbare Tabellen sind z.B. die Servereinstellungen des Mumble-Servers.

Damit wird für die Links in der Navigation nicht der Seitenname verwendet, sondern die erste Überschrift der Seite.
Man kann zusätzlich noch einstellen, dass interne Links auch den Seitennamen verwenden.

Eigentlich schade, dass der Wert per Voreinstellung auf 0 gesetzt ist.

Das sieht sehr viel schöner aus (rechts) als der Standard (links):

Mit diesem Plugin kann man Seiten aus einem DokuWiki als PDF-Datei exportieren.

Das Ergebnis sieht ziemlich schön aus.

Hier als Beispiel die exportierte Mumble-Seite zur Erstellung eines Musikbots mit VAC als PDF-Datei mit Okular geöffnet:

Auf der letzten Seite befinden sich die Informationen zur exportierten Wiki-Seite und ein QR-Code:

Man kann sich nun jede Seite im Wiki als PDF exportieren, indem man rechs oben auf Export: PDF klickt:

Damit dieser Link verfügbar ist, muss man wie in diesem Beispiel das Monobook-Template bearbeiten, siehe hier.

[][1]

Hochladen

Im MediaManager, mit dem man jetzt auch mehrere Dateien auf einmal ohne Flash-Uploader hochladen kann, gibt es nun auch Drag-and-Drop Unterstützung:

[][2]

Man kann also direkt aus einem Dateibrowser Dateien hochladen.
Außerdem gibt es jetzt beim Hochladen eine Fortschrittsanzeige:

Betrachten

Zum Durchsehen der Bilder gibt es nun zwei Ansichten; eine mit relativ großen Vorschaubildern und eine Liste mit einer sehr kleinen Vorschau; außerdem kann man nach Name oder Datum sortieren:

[][3]

[][4]

Dateiversionen

Zusätzlich gibt es nun eine Versionierung von Mediendateien; man kann also z.B. eine neue Version eines Screenshots hochladen während die alte immer noch verfügbar bleibt.

Wenn man z.B. einen neuen Screenshot der neuen Mumble-Version hochlädt und den bestehenden ersetzt so ist der alte Screenshot weiterhin verfügbar. Man kann sich sogar mit drei verschiedenen Methoden die Unterschiede zweier Versionen ansehen:

1. Nebeneinander
   Wie zu erwarten werden beide Bilder nebeneinander angezeigt; man kann hier auch die alte Version wiederherstellen:

2. Überblenden
   Mittels eines Schiebereglers kann man die beiden Grafiken überblenden:

   

• Übergang
  Auch hier stellt man mit einem Slider ein wieviel man vom jeweiligen Bild sehen möchte:

  [][7]

Das Löschen von alten Versionen funktioniert in meiner Installation leider noch nicht :/

Die alten Versionen der Dateien werden übrigens in WIKIDOCROOT/data/media_attic/wiki-pfad gespeichert.

Alleine schon für den neuen MediaManager lohnt sich ein Update auf den RC1 bei dem ich bisher noch keine Bugs in der alltäglichen Nutzung gefunden habe.