Nach circa 12 Jahren habe ich mein gern genutztes DokuWiki auf wikiarchiv.natenom.de in den Ruhestand geschickt. Bereits zuvor hatte ich fast alle Themenbereiche in mein neues Wiki auf wiki.natenom.de verschoben.

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.

Disabled actions in DokuWiki

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.

Hinweis
Ich habe getestet, wie es aussieht, wenn ich zumindest den kompletten Seitenbaum für die Bereiche Mumble und Minecraft immer geöffnet lasse. Dann ist das Wiki auf mobilien Geräten nicht mehr zu gebrauchen, da die Liste aller Seiten extrem lang ist. Schon meine Mumble-Dokumentation besteht aus ca. 330 Seiten.

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
Update

Wenn es Probleme gibt und eine Meldung in der Form no follow attribute found, dann benötigt man zusätzlich noch diesen Parameter:

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

    Links mit do= und rechts ohne

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

    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.

  1. Für weitere Dateitypen beliebig erweiterbar. ↩︎