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.

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

Vrifox hat mir daraufhin heute abend eine schönere Version dieser Fehlerseite erstellt.

Hier mein diletantischer Versuch:

Und hier das Ergebnis von Vrifox:

Sieht ein bisschen besser aus :)

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

Schließlich wird in diesem Wiki nichts Neues mehr hinzugefügt werden und es soll nur der letzte Stand verfügbar sein.

Außerdem ist mir aufgefallen, dass einige Crawler immer wieder verschiedene veraltete Versionen von Seiten abrufen. Diese Anfragen werden dann ins Leere laufen.

Zur Not habe ich aber auch noch ein Backup der Datenbank.

Am liebsten wäre es mir übrigens, wenn es eine Möglichkeit gäbe, das ganze MediaWiki mit allen relevanten Seiten einmal komplett als statisches HTML zu exportieren und dann online zu stellen. Wenn jemand sowas kennt, bitte melden :)

Alte Versionen löschen

MediaWiki bietet ein eigenes Script dafür an, siehe hier.

php maintenance/deleteOldRevisions.php --delete                            

Delete old revisions Searching for active revisions…done. Searching for inactive revisions…done. 4586 old revisions found. Deleting…done. Searching for active text records in revisions table…done. Searching for active text records in archive table…done. Searching for inactive text records…done. 4338 inactive items found. Deleting…done.

Gelöschte Seiten endgültig löschen

Und man kann auch noch gelöschte Seiten entgültig löschen, siehe hier.

php maintenance/deleteArchivedRevisions.php --delete

Deleting archived revisions… done. 1135 revisions deleted. Searching for active text records in revisions table…done. Searching for active text records in archive table…done. Searching for inactive text records…done. 1101 inactive items found. Deleting…done.

Passt :)

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

• 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.

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…

Um nachvollziehen zu können, ob alles richtig läuft, wurde die folgende Endlosschleife ausgeführt:

while true; do ps aux | grep convert ; sleep 0.2; done

Dann wurde die Erzeugung einer neuen Grafik erzwungen, indem die SVG-Datei eingebunden wurde mit der Festlegung einer bisher noch nicht vorhandenen Größe, z. B. 400 Pixel; dabei tauchte die entsprechende Zeile auf; convert (aus dem ImageMagick-Paket) wurde wie folgt aufgerufen:

convert -background white -thumbnail 800x282! /path/to/file.svg PNG:/path/to/output.png

Beispiel mit ImageMagick

Das Ergebnis der Konvertierung von der Datei Publicdomain.svg sieht so aus:

Ich wollte nicht glauben, dass das wirklich sein kann und habe das auf dem Rechner zuhause nachvollzogen; dort sieht es genauso aus.

Wieso wird das als Voreinstellung verwendet?

Lösung

Wikipedia verwendet statt ImageMagick den Converter rsvg; um diesen auf einem aktuellen Debian stable nutzen zu können, installiert man das Paket „librsvg2-bin“:

apt-get install librsvg2-bin

Es werden eine Menge Abhängigkeiten mitinstalliert.

Danach steht das Binary „rsvg“ zur Verfügung, welches ein Symlink auf „rsvg-convert“ ist. Nun ändert man die Variable „$wgSVGConverter“ in der Datei LocalSettings.php auf den Wert „rsvg“ um.

Das Ergebnis überzeugt:

Danach wurden im Verzeichnis images/thumb der MediaWiki-Installation alle Dateien des Musters „*svg*png“ im Namen gelöscht. Sobald man eine Seite mit solchen Dateien speichert, werden diese neu erzeugt, siehe hier.

\o/

Passt :)

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.

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.