In diesem Artikel möchte ich erläutern, wie es dazu kam, dass ich mich für ein Projekt nachhaltig mit MediaWiki auseinander gesetzt habe, was dabei heraus gekommen ist und was ich dabei gelernt habe.

Alles begann im letzten Jahr während einer coronabedingten Auftragsflaute in meinem Unternehmen, die mir über mehrere Monate Kurzarbeit bescherte. Was zunächst ganz erholsam und dank Kurzarbeitergeld auch finanziell abbildbar klang, führte mich doch recht bald zu einer wichtigen Frage: Was fängt man mit soviel Freizeit an?

Nachdem ich mich zunächst mit allerlei Sport und haushaltsnahen Tätigkeiten, wie z.B. Bärlauchpesto herstellen, beschäftigt habe, entschied ich mich kurzentschlossen ein neues Projekt mit MediaWiki zu starten.

Employees for Future

Hierfür muss ich zunächst erläutern, dass ich mich seit ca. einem Jahr bei den Employees for Future engagiere. Es handelt sich hierbei um einen gemeinnützigen Verein, der in Leipzig gegründet wurde, mit der Idee Nachhaltigkeit in Unternehmen zu fördern. Zunächst gestartet als eine Serie von Meetups zum Austausch zwischen Gleichgesinnten, entwickelte sich recht bald eine Art „harter Kern“ um die Gründerin herum und die Idee entstand, konkrete Angebote für Interessierte zu machen, die Lust haben das Thema Nachhaltigkeit voran zu bringen.

Nachdem ich mich zunächst nur für die Website engagiert hatte, nahm ich dann immer mehr die Idee eines Wissensspeichers in den Fokus, der die in den Meetups erarbeiteten Ansätze sammeln und für jeden zur Verfügung stellen sollte. Der Wissensspeicher sollte natürlich im Web stehen und überregional genutzt werden können, also auch unabhängig von den Meetups in Leipzig. Einen Namen gab es auch schon „ErWiN – Erfahrungs- und Wissensspeicher für Nachhaltigkeit“ :)

Nach ein paar anderen Ideen kam recht schnell dabei ein Wiki als sinnvolle technische Lösung ins Visier und da ich nunmehr Zeit hatte, beschloss ich das einfach mal auszuprobieren.

Recherche nach Wiki-Systemen

Nachdem ich die Idee eines Speichers auf Git-Basis als zu kompliziert für den Endnutzer verworfen hatte, machte ich eine kleine Evaluation möglicher Wiki-Systeme. Dabei habe ich unter anderem folgende Aspekte geprüft:

  • leichter Zugang und einfache Bedienung
  • Erweiterbarkeit, ggf. auch durch eigene Entwicklung
  • möglichst freie Software
  • eine aktive Entwicklercommunity
  • gute Dokumentation
  • möglichst LAMP-Stack
  • idealerweise große Verbreitung

Es gibt tatsächlich eine relativ große Liste von Systemen, daher konnte ich einige Kriterien früh als Must-Haves bewertet, etwa Open Source und weil meine Heimat nunmal PHP ist, landete ich schließlich bei MediaWiki. Dabei handelt es sich um die Software, die auch für Wikipedia genutzt wird, was eine hohe Verbreitung, gute Dokumentation und aktive Community aus meiner Sicht auch langfristig sicherstellen würde.

Auf der anderen Seite war aber die Fülle des Ökosystems und die Komplexität der Software auch ein wenig beängstigend. Ich hatte zu dem Zeitpunkt wenig eigene Erfahrungen mit einem solchen Open Source Kosmos.

Aber egal.. Versuch macht kluch ;)

Prototyp und GitLab Outing

Zunächst, wie bei allen meinen Projekten, werkelte ich allein ein paar Tage im stillen Kämmerlein. Wo fängt man an, wenn man keine Erfahrung hat? Das Aufsetzen selbst ging sehr zügig, das ist nicht viel anders als z.B. ein WordPress. Aber woraus besteht das System eigentlich? Und wie baut man das so auf, dass es gut wartbar bleibt, auch bei Updates? Wo liegen veränderliche Dateien? Und wie greift man am besten ins System ein ohne was kaputt zu machen?

Tatsächlich hab ich mich hierbei mit einer abwechselnden Folge von „nachlesen“ und „einfach ausprobieren“ entlang gehangelt, bis ich einen stabilen Grundansatz für System, farblich angepasstes Template und ein paar Extensions hatte, die ich über ein Makefile automatisiert bauen konnte. Den Stand hab ich dann intern ein paar Leuten präsentiert und vorgeschlagen, dies als Grundstein für den ErWiN zu nutzen.

Da alle recht begeistert waren, ging das Projekt in die nächste Phase und etwa zwei Wochen lang habe ich fast täglich weiter an der Basis gearbeitet, bis ich bereit für mein „Outing“ auf GitLab war.

Dafür hab ich dann noch die Git-Historie zurückgesetzt (wie genau, hab ich mittlerweile vergessen) und dann wurde das ganze Ende Mai zum ersten Mal publik. Wobei publik meint innerhalb des kleinen Kreises von Mitstreitern, von denen ich Feedback einholte und die mir neue ToDos mit auf den Weg gaben.

Notwendige Funktionen

Für den geplanten Einsatz waren neben grundlegenden Funktionen, wie z.B. Seiten editieren oder Bilder hochladen, vor allem ein ausgefeilteres Nutzerrollenkonzept erforderlich. Wir haben uns hierbei entschieden, dass anonyme Nutzer zur Vorbeugung von Spam- oder sonstigem Missbrauch kein Schreibrecht erhalten.

Aus Sicherheitsgründen wurden auch die Rechte zum Upload von Files und der Freigabe von Beiträgen nochmal separiert. Für letzteres wurde die Erweiterung ApprovedRevs integriert, die sich in einer Evaluation von vier möglichen Erweiterungen für diesen Aspekt als am geeignetsten erwies.

Zudem gab es erweiterte Funktionen für Social Media Markup und für die Darstellung von Spalten mit responsiver Logik implementierte ich eine erste einfache Extension, die entsprechende Parser Funktionen – zusätzliche Tags, die man im Editor nutzen kann, um bestimmte Elemente anzuzeigen – ergänzten.

Weiterhin wurde mit DynamicPageList eine Erweiterung hinzugefügt, die eine automatische Erzeugung von Listen von Artikeln einer Kategorie ermöglicht.

Mit diesem technischen Stand sowie einer Grundbefüllung an Beiträgen ging ErWiN Ende September live.

Sicherheitsfunktionen

Grundsätzlich habe ich ErWiN so angelegt, dass er in der Grundkonfiguration möglichst gut gegen Missbrauch aller Art geschützt ist. Es gibt hierzu lange Beschreibungen in der Dokumentation, die zahlreiche Hinweise geben, wie man Spam in MediaWiki bekämpfen kann.

Weiterhin habe ich auch viele Standardfunktionen abgeschaltet, die ErWiN nicht benötigt, z.B. Benutzer-Javascript oder Mails zwischen Benutzern. Darüber hinaus wurden im Backend-Bereich einige Funktionen ausgeblendet, die Benutzer nicht verändern sollten.

Auch die Benutzerrechte wurden stark beschränkt und müssen über ein Whitelisting aktiviert werden. Zudem wird sowohl in MediaWiki selbst als auch in der .htaccess https erzwungen. Für Cookies gilt zudem die SameSite-Direktive.

Technische Anpassungen

Auf technischer Seite habe ich vor allem die Konfiguration angepasst. Die Grundidee ist hier, dass ErWiN per Code quasi vollständig konfiguriert wird und nur noch die serverbezogenen Einstellungen in der zentralen Konfiguration stehen. Hierbei habe ich es so implementiert, dass in den zentralen Konfiguration die Einstellungen aber jederzeit überschrieben werden können, so dass Anpassungen nur in einer Datei notwendig sind. Im Hinterkopf hatte ich hier – neben der Unterscheidung zwischen lokaler Instanz und Live-Instanz – auch ein mögliches Szenario, bei dem der Kern von ErWiN für andere Seiten (z.B. eine Version in einer anderen Sprache) genutzt werden kann. Tatsächlich gab es seit dem Start von ErWiN hierzu auch schon eine Anfrage, allerdings ohne mir bekannten Fortschritt.

Weiterhin habe ich im Build-Prozess ein paar Funktionen eingebaut, die die Größe des Builds durch Weglassen nicht genutzter Sourcen deutlich reduzieren. Hierbei werden automatisch u.a. nicht genutzte Sprachdateien, aber auch Dokumentationen oder Relikte von anderen Buildprozessen entfernt. Das reduziert die Uploadgröße um etwa 100 MB auf etwas weniger als 40 MB.

Für den Upload setze ich wieder auf git-ftp, was ich schon in einem früheren Artikel beschrieben habe. Das ist nicht ideal, weil ich dadurch httpdocs/ ins Git mit einchecken muss, aber so kann ich auch leichter Änderungen im Build erkennen. Es widerspricht auch dem Gedanken mehreren Instanzen mit dem Git zu versorgen. Aber solange es nur eine Instanz gibt, ist das noch kein Problem.

Interessant ist noch der Autobuild-Modus. Ich habe mir ein kleines Script geschrieben, welches selbstständig Änderungen in einem Teil der Anwendung prüft und dann einen Abschnitt im Makefile aufruft, der die Änderungen direkt im Build aktualisiert. Dadurch kann ich Änderungen in meinem src/ machen und noch bevor ich in den Browser wechsle ist der Stand schon auf httpdocs/ übernommen.

Noch mehr Informationen und den vollständigen Quellcode zum ErWiN findest du hier auf GitLab: https://gitlab.com/gruniversal/erwin

Segen und Fluch von MediaWiki

Nachdem ich nun gut ein halbes Jahr im MediaWiki Kosmos aktiv bin, kann ich schon ein erstes Zwischenfazit geben, ob die Entscheidung für MediaWiki im Nachgang richtig war und wo Vor- und Nachteile der Software liegen.

Auf jeden Fall positiv ist, dass es sich um ein mächtiges System handelt, mit einer Vielzahl an Erweiterungsmöglichkeiten und einer wirklich umfassenden Dokumentation. Mit genügend Zeit kann man sich an jedes Problem heranwagen und es letztlich auch lösen. Da es Open Source ist, kann man dabei auch noch zur Verbesserung der Software beitragen, von der letztlich alle Nutzer profitieren.

Zumindest in der Theorie. In der Praxis fällt unter den vielen Anleitungen und Möglichkeiten oft erst einmal die Orientierung schwer und teilweise veraltete Dokumentationen tun ihr übriges. Das sind offenbar die Schattenseiten von Open Source, wo letztlich viele Freiwillige nur so viel einbringen, bis ihr eigenes Problem gelöst ist bzw. wo Funktionen nur insofern gepflegt werden können, wie es die eigenen Zeitressourcen erlauben. Damit muss man letztlich wohl leben.

Bisschen schade finde ich allerdings schon, dass selbst dann, wenn man Patches bereitstellt, diese nicht berücksichtigt werden. Ich habe z.B. Ende September einen einfachen Fix für ein Problem bereitgestellt, welches seit 2011 besteht und abgesehen von Jenkins und Gerrit – zwei fleißigen Bots – hat sich bisher niemand das Thema gezogen. Deshalb muss ich in meinem Makefile weiterhin diese Stelle beim Build immer automatisch patchen, damit die Bildersuche auch mit Umlauten funktioniert.

Ein einfacher Fix für ein fast 10 Jahre altes Problem

Es gibt auch ein chronisches Problem mit der Session, welches vor allem beim Editieren dazu führt, dass der Inhalt einer Seite beim Bearbeiten manchmal nicht gespeichert wird. Hierzu gibt es seit 2017 eine umfassende Wikiseite, die mögliche Gegenmaßnahmen beschreibt. Letztlich konnte ich das Problem bisher nicht final lösen und nur durch einen Workaround fixen. Dabei setze ich automatisch das „Remember me“ Häkchen beim Login und durch ein erneutes Klicken auf den Speichern-Button kommt dann die Sitzung wieder. Funktioniert soweit, aber erfordert eine extra Schulung für alle Autoren, damit diese dadurch nicht irritiert sind und hinterlässt eher ein mittelgutes Gefühl. Zumal das Bearbeiten in einem Wiki eine Hauptfunktion ist.

Beim Blick in den Code finden sich m.E. auch relativ viele Legacy-Themen. Klar, die Software hat schon eine längere Geschichte, aber m.E. sollten neue Versionen hier konsequenter alte Zöpfe abschneiden um Komplexität durch zu viele Optionen zu reduzieren. So lassen sich z.B. Extensions auch in der neuen Version 1.35 LTS über zwei Wege laden: entweder über die modernere Einbindung per wfLoadExtension() oder aber über den alten Weg durch require_file("$IP/extensions/.."). Ich fände es besser, wenn hier gerade bei größeren Versionsupdates mehr Altlasten über Bord geworfen würden. Vermutlich will das Core-Team hier die Extension-Entwickler nicht überfordern, andererseits gibt es den neuen Weg seit Mai 2015, da wäre also genug Zeit geblieben, dort mal aufzuräumen.

Bisschen befremdlich fand ich zunächst auch die Konfiguration. Praktisch alle Einstellungen werden durch Variablen der Form $wgXXX abgebildet, wobei XXX einen CamelCase-Begriff darstellt, z.B. $wgDefaultSkin. Das betrifft Einstellungen am Kern, aber auch für Extensions z.B. $wgConfirmAccountContact. Das Verrückte daran ist, dass diese Variablen global sind und entsprechend überall eingebunden und auch überschrieben werden können. Das ist in gewisser Weise praktisch, aber öffnet natürlich in vielerlei Hinsicht die Tür für Probleme, etwa durch Kollisionen von Variablennamen oder unsichtbaren Abhängigkeiten.

So habe ich schon im letzten Jahrtausend nicht mehr programmiert :)

David

Aber OK, alle Entwickler halten sich offenbar an ein gewisses Namensschema, welches den Extension-Namen vorn in die Variablen einfügt und bisher hatte ich auch noch keine praktischen Probleme dadurch.

Und noch ein anderer Punkt ist mir negativ aufgefallen. Es gibt keine einheitliche Template-Engine und in Extensions werden Markup und Code regelmäßig durch HEREDOC-Blöcke vermischt. Auch das finde ich sehr unübersichtlich. Mein erster Impuls war hier eine Engine wie z.B. Twig einzufügen und auch andere sind schon auf diesen Gedanken gekommen. Leider ist es auch hier nicht weiter gegangen.

Insgesamt sind meine Erfahrungen also durchwachsen. Ohne Zweifel ist MediaWiki eine umfassende Anwendung, die alle notwendigen Anforderungen erfüllt und auch recht gut wartbar ist. Auf der anderen Seite fühlt es sich hier und da an wie ein Dino, bei dem der Höhepunkt schon überschritten ist, und die Entwickler-Community nicht die Kraft aufbringt, notwendige Modernisierungen durchzusetzen.

Ob ich es trotzdem wieder mit MediaWiki wagen würde? Ja, wahrscheinlich schon. Ich hab’s irgendwie lieb gewonnen mit all seinen kleinen und größeren Macken ;)

Meine Learnings

Nach soviel Manöverkritik zu MediaWiki noch eine kleine selbstkritische Reflektion. Gemäß der ganzen Vorgeschichte war es für mich ein Sprung ins kalte Wasser voller fehlender Erfahrung und potenzieller Stolperfallen. Wie sehr bin ich eigentlich mit mir selbst zufrieden und was hab ich dabei gelernt?

Nun zunächst bin ich der einzige Entwickler auf dem Thema und ohne Vorerfahrungen war und ist die Lernkurve eher mäßig steil. Es wäre gerade am Anfang hilfreich gewesen, jemanden an der Hand zu haben, der einem Orientierung gibt, denn so ein großes System kann durch seine schiere Komplexität schon verunsichern. Andererseits hatte ich nur wenig Momente, in denen ich dachte, ich sei der Aufgabe vielleicht nicht gewachsen. Am Ende lässt sich mit Geduld und Disziplin fast jedes Problem beheben. Am kritischsten empfinde ich nach wie vor das Login-Problem, weil es so zentral ist und vermutlich so tief im Kern sitzt, das ich es nicht finden werde, zumal es nur sporadisch auftritt.

An die Unzulänglichkeiten mit dem Open Source Kosmos habe ich mich in der Zwischenzeit gewöhnt. Wenn man nicht zu viel erwartet, kann man auch nicht enttäuscht werden und im Zweifel kann man alles ja auch selbst irgendwie lösen. Außerdem ist es spannend an einer Extension zu arbeiten, an der schon Entwickler aus einem halben Dutzend Länder mitgewirkt haben. Für mich sind das die ersten Schritte in so einer Form der Zusammenarbeit und ich bin immer sehr neugierig auf Feedback zu meinen Beiträgen. Ich kann aber noch dazulernen damit umzugehen, wenn das Feedback erst sehr spät kommt oder sogar komplett ausbleibt :)

Codetechnisch habe ich wie immer noch viele Ideen das ganze besser aufzubauen. So gefällt mir das Ladeverhalten der Settings noch nicht so richtig und dass der Upload über git-ftp nicht ideal ist, hatte ich ja oben schon erwähnt. Ich überlege auch einen Teil des Buildprozesses über Composer zu steuern, hab das bisher aber nicht gemacht, weil ich nicht sicher bin, ob ich alle notwendigen Extensions auch darüber einbinden kann. Zudem bin ich mit dem Makefile sehr zufrieden, was auch als sehr gute Dokumentation des ganzen Build-Prozesses dient. Das werde ich sicherlich in anderen Projekten wieder ähnlich aufbauen.

Die Idee den Build zu verkleinern, finde ich auch ganz sinnvoll, weil es wirklich Ressourcen auf dem Server einspart. Ich hatte hier die Überlegung, ob es rechtlich legitim ist, da ich ja auch z.B. Lizenzinformationen lösche. Da es aber innerhalb des Gits alles vorhanden ist und Entwickler ja diesen Teil sehen, ist das für mich OK.

Nicht so zufrieden bin ich mit dem Dryad Skin. Zum einen, weil das Skin-System von MediaWiki auf Grund der fehlenden Template-Engine irgendwie sehr kompliziert wirkt, zum anderen aber auch weil der Skin nicht Standalone funktioniert, sondern auf Timeless basiert, so dass ich beide Skins laden muss. Aber das anzupassen, übersteigt meine zeitlichen Ressourcen und Fähigkeiten im Moment deutlich.

Zu guter Letzt ist das auch das erste Projekt seit langem, welches ich vollständig in englisch dokumentiere und nach anfänglichen Wortfindungsstörungen, klappt das mittlerweile relativ flüssig. Auch das aus meiner Sicht ein kleiner Erfolg.

Fazit

Stichpunkt Erfolg. Nach diesem doch relativ langen Artikel wird es Zeit für ein Fazit.

Insgesamt kann ich sagen, dass trotz oder gerade auf Grund der vielen kleinen und größeren Hindernisse und den bestehenden Unzulänglichkeiten in MediaWiki und bei mir selbst das ganze für mich eine Erfolgsgeschichte ist. Über Monate hinweg ist eine solide Basis für ein spannendes Projekt entstanden, dass nach dem Livegang jetzt erst so richtig beginnt und hoffentlich dazu beitragen kann, die Welt ein wenig nachhaltiger zu machen.

Wenn du nach all der Vorrede ErWiN jetzt gern einmal persönlich kennenlernen willst, folge diesem Link: http://erwin.employeesforfuture.org/

Darüber hinaus freue ich mich gern über konstruktives Feedback zum Code und meinen Ausführungen und natürlich auch zum Projekt insgesamt.