Media-Wiki 1.16 Review

Eine ganze Reihe von Herausforderungen mussten bewältigt werden, um ein existierendes, auf MediaWiki basierendes Wiki aufzufrischen. Die gesammelten Erfahrungen werden hier in einem schnellen Review des aktuellen MediaWiki-Ökosystems zusammen gefasst.

Konkret mussten folgende Aufgaben gelöst werden:

  • Update von MediaWiki 1.13 auf MediaWiki 1.16 (MediaWiki ist die Wiki-Software, die bei den wikipedia Projekten Verwendung findet)
  • Vereinigung von bisher 3 getrennte Wikis für deutsch, englisch, polnisch in ein mehrsprachiges Wiki von einer Codebasis
  • Vereinigung der 3 genutzten Datenbanken
  • Kompatibilität der genutzten Extensions und manuellen Änderungen:
    • FlaggedRevs (Markierung einzelner Artikel als geprüft / entsprechende GUI)
    • RSS
    • News
  • Einpflegen neuer Funktionen:
    • nur durch ausgewählte Nutzer änderbare Textelemente
    • Darstellung dieser Textelemente
    • Begrenzung der Artikeltitellänge

Die Zusammenfassung der Codebasis

Als umfangreichste Arbeit stellte sich erwartungsgemäß die Vereinigung der bisher getrennten Wikis in neuer Version heraus. Statt ein Update der alten Version vorzunehmen, wurde statt dessen die neue Version getrennt installiert und die Strukturen und verschiedenen Daten der alten Wikis dort schrittweise importiert. Das hat geklappt.
Aber:

Die Multi-Domain-“Installation” von MediaWiki besteht in der Erzeugung eigener Verzeichnisse für die Domains und SymLinks auf alle Elemente des eigentlichen Installationsordners. Danach werden dann in den einzelnen Verzeichnissen je eigene Config-Dateien angelegt. Dieses Muster funktioniert zwar, ist in seinen Möglichkeiten und dem nötigen Aufwand aber natürlich von Multi-Installations-Referenzen wie beispielsweise Drupal meilenweit entfernt. Bei der Datenbank, bzw. den Datenbanken gestaltete sich die Arbeit einfacher – es genügte den Tabellen je ein Präfix voran zu stellen und dies in den Config Tabellen zu berücksichtigen.

Die Wikis arbeiten damit auf der gleichen Verzeichnisbasis, was zu Konflikten führen kann, dafür funktionieren aber beispielsweise alle Extensions diskussionslos über alle Wikis hinweg. Die naheliegende Einrichtung von InterWiki Links zur Verlinkung von Inhalten über die Wikis hinweg muss dennoch manuell und je Wiki in einem SQL Statement erfolgen, und zwar für jedes andere Wiki, also in |Wiki|*|Wiki-1| Schritten, also exponentiell. Gott bewahre jeden vor der Aufgabe der Verlinkung von mehr als 20 Wikis untereinander.

Im Zuge dieses Codewechsels wurden dann auch eine Reihe ursprünglich manueller Änderungen an der Codebasis umgangen, um zukünftige Updates drastisch zu vereinfachen. An erster Stelle stand dabei die Auslagerung der vorher am Standardtemplate “Monobook” vollzogenen Änderungen in ein eigenes Template. Ändert man Standarddateien, werden diese beim nächsten Update wieder überschrieben. Das gilt für jede Software und ist nicht MediaWiki anzukreiden. Zudem war die Erstellung eines eigenen Templates, welches 99% von Monobook erbt (und zwar wörtlich über ein

CustomTemplate extends MonobookTemplate {...}

) zwar arbeitsintensiv, aber das vor allem um den doppelten Code zu löschen. Arbeitet man so von vorherein, ist es schnell gemacht.

Eine Reihe anderer Änderungen wurden zudem über JavaScript vorgenommen (siehe unten), dessen Einbindung ist über ein eigenes Template trivial, seit MediaWiki 1.16 auf Wunsch übrigens auch mit eingebautem jQuery ab Werk.

Zum Schluss mussten die existierenden Extensions überprüft werden. Dabei fällt als erstes auf, dass das Zusammenspiel von Extensions für 1.13 mit 1.16 keineswegs voraus gesetzt werden darf. Gleichwohl dazwischen nur 3 Point Releases stehen, haben sich (Extension-)API und Struktur offenbar zum Teil deutlich verändert. Das liegt wohl im primären Daseinszweck von MediaWiki, nämlich Softwarebasis für Wikipedia zu sein. Dort findet sich quasi die HEAD-Version im Einsatz und die Extensions ziehen bei Änderungen schrittweise dorthin nach (oder auch nicht). Diese Erfahrung, dass die breite Massennutzung von MediaWiki eher ein Nebeneffekt der Entwicklung für Wikipedia ist, zieht sich durch die gesamte Arbeit mit diesem hat eine ganze Reihe spürbarer Auswirkungen. In diesem Fall die Notwendigkeit das Zusammenspiel von Extensions (-versionen) und MediaWiki (-version) vor Einsatz zu testen.

Extension Repository

Für zusätzliche Funktionen, wie die oben genannten neuen Anforderungen, empfiehlt es sich, das Extension Verzeichnis von MediaWiki zu durchsuchen. Dort finden sich sehr sehr viele Erweiterungen. Die Sortierung ist allerdings noch nicht völlig ausgereift. Ebenso die Dokumentation einzelner Extensions sowie die Verzahnung untereinander, sowohl in der Darstellung im Extension Verzeichnis als auch in der technischen Umsetzung komplementärer Funktionen. Hier darf wieder auf vorbildliche Äquivalent bei Drupal verwiesen werden. Die Ursache findet sich wohl wieder in der weniger starken Fokussierung auf eine breite Einsatzbasis als in der Weiterentwicklung für die wikipedia.

Trotz der Kritik: es fand sich eine Extension “ProtectSection” die eben die Einbindung einzelner geschützter Textblöcke ermöglicht und damit eine Anforderung ad hoc erledigt. Die Installation und Einrichtung erfolgt dabei weitestgehend manuell und durch Eintragungen in config-Dateien. Dies erfordert ein Studium (der hoffentlich vorhanden und aktuellen) Doku, ermöglicht aber wenn nötig auch komplexe und vor allem flexible Konfigurationen, denen ein Wizard im Wege stehen könnte. Die Visualisierung dieser geschützten Blöcke erfolgte durch eine Kombination aus CSS und (Fallback-sicherem-) JavaScript.

Eigene Extension

Die Begrenzung der Titellänge einzelner Artikel ist seltsamer Weise nicht über eine Config-Einstellung möglich, genauso wenig wie sich eine entsprechende Extension fand. Dieser Wunsch scheint nicht häufig zu bestehen. Dadurch kam einer der Glanzpunkte des MediaWiki zum tragen: die schnelle Erweiterbarkeit durch eigene Extensions.  Der Verzicht auf ein umfassendes Administrationsinterface oder entsprechendes GUI-Framework macht die Entwicklung von Erweiterungen sehr einfach und verhindert vor allem nahezu jeden Overhead. Wo andere CMS viel Code für Installer, Wizards und GUI benötigen, ist es bei MediaWiki mit einem include(); in der LocalConfig.php getan.

In der eingebundenen Datei dürfen dann an die zahlreich vorhandenen Hooks nach Belieben eigene Funktionen gehängt werden. Hooks sind Punkte im Programmablauf, die bei einer (langen) Liste von Ereignissen, in den Extensions  nach auszuführenden Funktionen suchen. Beispielsweise wird der Hook ArticleSave ausgeführt, wenn ein Artikel gespeichert werden soll. Die anzubindende Funktion muss die entsprechenden Parameter (per Referenz) übernehmen und abschließend true oder, um den Programmablauf zu unterbrechen false, zurück geben. Simpler und schneller geht’s kaum. Dazu kommt bei den Kernkomponenten, also Hooks und jeweilige Parametern eine hervorragende technische Dokumentation. Die Titelbegrenzungsextension umfasst so kaum 20 Zeilen Code und tut, was sie tun soll.

Fazit

Wer ein Wiki benötigt, das sehr hohen Belastungen begegnen muss, sehr viel Traffic, sehr viele Artikel, sehr viele Nutzer, ist bei MediaWiki richtig. wikipedia ist Beweis genug. Zudem kann es auch von Vorteil sein, Nutzern die sich mit wikipedia auskennen einen gewohnte Oberfläche und Funktionsweise zu bieten. Schließlich lässt sich MediaWiki an sehr vielen Stellen an eigene Bedürfnisse anpassen, wenn auch zuweilen unter Bruch der Kompatibilität beim nächsten Update.

Entgegen steht dem allerdings sehr viel Handarbeit und Lernaufwand. Selbsterklärend ist wenig und wer ungern in Config-Dateien arbeitet, hat ein Problem. Geht es also um überschaubare Wikifunktionen lohnt sich ein Blick auf administrationsfreundlichere Alternativen wie DokuWiki oder MoinMoin.

Vorteile:

  • weitgehende Anpassung möglich
  • sehr mächtig (siehe wikipedia)

Nachteile:

  • steile Lernkurve
  • Anpassungen auch eher simpler Dinge (Menüs) nur über Vorlagen/Spezialseiten, dadurch äußerst umständliche, völlig dezentrale Administration

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *