MediaWiki

Issue Tracker in MediaWiki integrieren

von

Screenshot: IssueTracker Extension für MediaWiki

Wikis und Issue Trackers sind zwei unverzichtbare Werkzeuge, wenn man in einer Gruppe an einer Website oder an einer Software arbeitet. Wer MediaWiki nutzt und keinen Issue Tracker mit allen Schikanen braucht, sollte sich die Extension IssueTracker anschauen: Ist sie einmal installiert, so kann man durch blosses Hinzufügen des Tags <issues /> auf jeder beliebigen Wiki-Seite einen Issue Tracker einfügen.

Pro Issue kann man dann einen Titel, einen Text, einen Typ (konfigurierbar), einen Status (konfigurierbar) sowie den verantwortlichen MediaWiki Users erfassen. Das ist nicht eben viel, reicht aber in der Praxis oft aus. Die Liste der Issues kann nach allen Spalten sortiert, gefiltert und durchsucht werden. Ein bestehender Issue kann editiert oder archiviert werden.

Die Installation der Extension erfordert – wie so oft bei MediaWiki-Extensions – etwas Handarbeit: Die Source Files müssen einzeln heruntergeladen werden, und die erforderliche Datenbanktabelle wird per SQL-Skript angelegt. Sodann sind noch einige Known Bugs zu beheben, die kleine Änderungen an den Source Files erfordern. All dies ist aber gut dokumentiert, und es ist die Mühe wert: Schon oft hätte ich mir eine solche Lösung gewünscht, statt von Hand im Wiki To-do-Listen zu pflegen.

Discussion: Kommentar-Plugin für DokuWiki

von

 image

Erstmals aufgefallen ist mir das Konzept vor Jahren in der offiziellen PHP-Dokumentation: Unten an der Seite können alle Besucher Anmerkungen anfügen, auch wenn sie für den normalen Seiteninhalt keine Schreibberechtigung haben. Oft findet man dort wertvolle Ergänzungen und Beispiele, an welche die Autoren der Dokumentation nicht gedacht haben.

Discussion ist ein Plug-in für DokuWiki, welches eine vergleichbare Kommentarfunktion bereitstellt. Nun könnte man zwar argumentieren, dass dies in einem Wiki – wo jeder Besucher den normalen Seiteninhalt umschreiben kann – nicht wirklich sinnvoll ist. Drei Gründe sprechen trotzdem für dieses Konzept:

  1. Es gibt Wikis, in denen nur ein beschränkter Kreis von registrierten Benutzern schreiben soll. In diesem Fall kann man die Inputs von Autoren und Besuchern sauber trennen.
  2. Es gibt Besucher, die zwar gerne einen kurzen Kommentar hinterlassen, die sich aber niemals die Mühe machen würden, den Seiteninhalt umzuschreiben (zumal dies Kenntnisse in der Wiki-Syntax verlangt). Das Kommentarformular ist dann eine niederschwellige Möglichkeit, um das Wissen solcher Besucher nutzbar zu machen.
  3. Das MediaWiki (das man von der Wikipedia her kennt) bietet zu jeder Seite eine Diskussionsseite, so dass der eigentliche Inhalt und die Diskussion darüber sauber getrennt sind. DokuWiki bietet keine solchen Diskussionsseiten, aber das Discussion-Plug-in leistet letztlich dasselbe.

Discussion ist eines der populärsten Plug-ins für DokuWiki – zu recht, kann ich da nur sagen.

Nachtrag zum Spam-Schutz (11. Juli 2009)

Kommentarformulare sind ein beliebtes Ziel von Spammern. Damit Ihr Wiki nicht verslumt, sollten Sie entweder Kommentare moderieren (das Plug-in bietet hierzu ein übersichtliches Backend sowie E-Mail-Benachrichtigung) und/oder das CAPTCHA-Plug-in installieren.

MediaWiki-Tuning: Default-Text für neu erstellte Seiten

von

image

Viele Wikis kennen Regeln, wie ihre Seite aufgebaut sein sollen. Mit rein technischen Mitteln lassen sich solche Vorgaben allerdings nicht durchsetzen – hier ist man darauf angewiesen, dass die Wiki-Benutzer die Regeln kennen und auch einhalten. Unterstützen kann man dies dadurch, dass beim Anlegen einer neuen Seite automatisch häufig benutzte Textbausteine eingefügt werden. MediaWiki beherrscht dies nicht von Haus aus, kann aber mit der Extension NewArticleTemplates entsprechend nachgerüstet werden. Der Standardtext für neue Seiten kann dann auf der Seite MediaWiki:NewArticleTemplate eingetragen werden. Falls erforderlich lassen sich pro Namespace individuelle Standardtexte erfassen. Eine ebenso einfache wie effektive Lösung, die viel Tipp- und Korrekturarbeit ersparen kann.

Inhalte aus einem MediaWiki als PDF exportieren mit der Collection Extension

von

image

Schon seit längerem beschäftigt mich die Frage, wie man den Inhalt eines Wikis mit vernünftigem Aufwand und in guter Qualität ausdrucken kann (vgl. Wie druckt man ein MediaWiki aus?). Inzwischen habe ich eine Lösung gefunden, die zumindest in meinem eigenen Setup sehr gut funktioniert.

Der Schlüssel zur Lösung ist die Extension Collection, welche von PediaPress entwickelt wird. Wie bei den meisten MediaWiki-Extensions ist zwar etwas Handarbeit erforderlich, im Prinzip ist die Installation aber nicht schwierig. Die Skripts der Extension kann man als Snapshot herunterladen (richtige MediaWiki-Version auswählen!), anschliessend sind noch einige Einträge in den LocalSettings.php sowie im Skin-File erforderlich. Wenn man das README.txt beachtet, kann eigentlich nichts schiefgehen.

Der Clou an der Sache ist, dass man die Phython-Libraries mwlib und mwlib.rl, welche für das Parsen der Wiki-Seiten und die Konvertierung in ein PDF zuständig sind, nicht unbedingt auf dem eigenen Server installieren muss, sondern dass man den Server von PediaPress benutzen kann. Für Wikis mit beschränktem Traffic reicht dies vollkommen aus.

image In der Anwendung ist Collection sehr elegant: In der Navigation erscheint ein neuer Befehl, mit dem man beliebige Seiten in eine Kollektion aufnehmen kann. Lässt man sich später die Kollektion anzeigen (vgl. obigen Screenshot), so kann man noch die Reihenfolge der Seiten anpassen und Kapitel einfügen. Anschliessend lässt sich aus der gesamten Kollektion ein einziges PDF generieren. Alternativ kann man auch ein Textdokument im OpenOffice.org-Format erzeugen, das man dann nicht nur drucken, sondern ggf. auch noch editieren kann.

Wie druckt man ein MediaWiki aus?

von

image

MediaWiki eignet sich hervorragend, um im Team-Work Informationen zusammenzutragen, zu strukturieren und zu überarbeiten. Aber was, wenn man das Resultat in Form eines PDFs exportieren oder ausdrucken möchte? Die Frage beschäftigt mich schon länger, und die perfekte Lösung habe ich noch nicht gefunden. Im Moment zeichnen sich zwei Favoriten ab:

  • PDF Book: Diese Extension erlaubt es, alle Seiten einer bestimmten Kategorie in einem einzigen Arbeitsgang als PDF zu exportieren. Dabei wird automatisch ein Inhaltsverzeichnis erstellt, pro Wiki-Seite wird ein Kapitel angelegt. Diese Lösung setzt allerdings voraus, dass HTMLDOC auf dem Server installiert ist.
  • Collection: Bei dieser Extension wird das PDF aus einer sogenannten Collection erstellt. Eine Collection ist vergleichbar mit einer persönlichen Bookmark-Sammlung, die direkt im Wiki abgelegt ist. Auf der Website WikiEducator kann man das in einem öffentlichen Beta-Test selbst ausprobieren. Und wie einer Medienmitteilung der Wikimedia-Foundation vom letzten Dezember zu entnehmen ist, handelt es sich bei dieser Extension um eine Entwicklung, welche strategische Bedeutung für MediaWiki hat und im Verlaufe des Jahres 2008 auch auf Wikipedia eingebaut werden soll. Vielversprechend ist auch die Ankündigung, dass bis Mitte 2008 zusätzlich ein Export im OpenDocument-Format möglich werden soll. Was mich dagegen irritiert ist die Tatsache, dass die Collection-Extension zwei Python-Libraries voraussetzt, während MediaWiki ja in PHP geschrieben ist. Ob diese Lösung auch für einfache Shared-Hosting-Accounts mit LAMP-Umgebung funktioniert?

Neben den beiden erwähnten Extensions gibt es noch eine ganze Reihe anderer Ansätze (vgl. die Liste der alternativen Parser sowie die Data Extracation Extensions), die mir allerdings – aus verschiedensten Gründen – weniger überzeugend scheinen. Gibt es tatsächlich keine Extension, die allein mit den Mitteln von PHP den Export einer ganzen Kategorie im PDF-, OpenDocument- oder RTF-Format erlaubt?

EasyTimeline: Timelines in MediaWiki

von

image

Für die Visualisierung von zeitgebundenen Fakten bieten sich Zeitleisten (Timelines) an. Von Haus aus hat MediaWiki hier keine Unterstützung zu bieten, aber mit der Extension EasyTimeline kann man Grafiken wie die oben gezeigte per Wiki-Text erstellen und editieren. Diese Methode ist natürlich – wie bei Wikis üblich – relativ technisch und setzt voraus, dass man sich in die Syntax der Extension einarbeitet. Der Aufwand lohnt sich aber, wenn man beispielsweise ein Wiki mit historischen Themen betreibt, einen Projektplan direkt im Wiki pflegen möchte oder (wie oben gezeigt) die Geschichte alle Apple-Macintosh-Computer nachzeichnen will.

Elgg: Social Networking Platform als Open Source Software

von

image

Ist eine Website mit einem Diskussionsforum bereits eine Social Networking Platform? Oder sind Tagging und Blogging zwingende Voraussetzungen? Oder ist die Freundesliste im persönlichen User-Profil das entscheidende Kriterium? Wer dem Begriff der Sozialen Software nachspürt begreift schnell, dass die Grenzen fliessend sind. Klar ist einzig, dass Social-Networking-Plattformen ein zentrales Element des Web 2.0 darstellen, und dass sie mit klassischen Content-Management-Systemen nur wenig Gemeinsamkeiten haben.

Natürlich gibt es auch dafür Open-Source-Lösungen, und Elgg dürfte eine der besten sein. Die Feature-Liste umfasst das, was man von einer solchen Software erwartet. Zudem kann Elgg gut mit MediaWiki, Moodle, Drupal oder Vanilla Forum kombiniert werden, und es stehen eine ganze Reihe von Plug-Ins zur Verfügung. Die Website der Elgg-Community vermittelt einen guten Eindruck der Möglichkeiten, die sich dadurch bieten. Und wer sein Social Network auch in der realen Welt pflegen möchte, kann dies im Rahmen des ElggJam in London tun.

Elgg setzt einen LAMP-Server (PHP und MySQL) voraus und unterliegt der GNU General Public Licence.

Deki Wiki: Das Wiki für jedermann

von

image

Ich erinnere mich noch gut, wie ich anfänglich auf Wikis reagierte: Zwar begeisterte mich die Schnelligkeit, mit der ich eine Website bearbeiten konnte, doch wollte mir nicht in den Kopf, warum ich dafür eine neue Markup-Syntax lernen sollte, statt einen WYSIWYG-Editor zu benutzen.

Inzwischen arbeite ich täglich und gern mit MediaWiki (nur einen Tabelleneditor wünsche ich mir nach wie vor). Trotzdem kann ich verstehen, dass sich nicht jeder auf die Wiki-Markup einlassen mag. Gerade in Projekten, in denen nicht nur Tekkies, Geeks und Nerds zusammenarbeiten, besteht Bedarf für eine möglichst niederschwellige, gepflegte Wiki-Software. Deki Wiki von MindTouch ist so eine.

Der vielleicht banalste und doch wichtigste Punkt: Deki Wiki besitzt einen WYSIWYG-Editor, wie man ihn von jedem CMS her kennt, inklusive Tabelleneditor. Im Hintergrund erzeugt dieser Editor nicht etwa Wiki-Markup, sondern XHTML (und wer unbedingt möchte, kann auch den XHTML Source Code bearbeiten).

Ein zweiter bemerkenswerter Punkt: Anders als in den meisten Wikis (die einen klassischen Hypertext mit Netzstruktur erzeugen) gibt es einen Seitenhierarchie, die sich auch in einer Navigation in der linken Randspalte niederschlägt. Persönlich finde ich das keine schlechte Idee, denn in fast jedem Wiki sehe ich die Autoren mühsam ein hierarchisch gegliedertes Inhaltsverzeichnis pflegen.

Auch nicht zu unterschätzen: Die Suchmaschine (Apache Lucene) durchsucht nicht nur Wiki-Seiten, sondern auch Dateien (PDF, Office-Formate). Nicht für alle Zwecke gleich sinnvoll ist dagegen die Möglichkeit, Seiten zu kommentieren und mit Tags zu versehen.

Alles zusammengenommen geht Deki Wiki schon fast in Richtung CMS oder Blog-Software. Die Bedienung ist intuitiv, allerdings zahlt man einen Preis für den Bedienungskomfort: Verglichen mit dem spartanischen Benutzer-Interface von MediaWiki ist die hübsche Benutzeroberfläche von Deki Wiki spürbar träger.

Ein Feature für Power Users sei ebenfalls nicht verschwiegen: Dank DekiSkript kann man mit einigen wenigen Code-Zeilen dynamischen Content, Mashups mit Widgets oder SQL-Queries in Wiki-Seiten integrieren. Das lernt man nicht in fünf Minuten, mit etwas Einarbeitung kann ein Deki Wiki Administrator aber trotzdem in kurzer Zeit multimediale, interaktive Seiten aufbauen. Videos von YouTube, Fotogalerien von Flicker oder Anfahrtspläne mit Google Maps sind dabei die einfacheren Anwendungen.

Deki Wiki ist Open Source (GPL), baut auf MySQL und PHP auf – und doch läuft es nicht auf klassischen Shared Hosting Accounts, weil die Kernfunktionalität in C# entwickelt wurde und .NET bzw. dessen Open-Source-Portierung Mono voraussetzt. Soweit die schlechte Nachricht. Die gute ist: Unter www.wik.is kann man ein Deki Wiki als Hosted Service betreiben lassen, in der Basis-Version auch kostenlos.

DokuWiki: PHP-Wiki ohne Datenbank

von

image

Nebst dem bei der Wikipedia eingesetzten MediaWiki gibt es noch diverse andere Wiki-Lösungen – gegen 100 Namen listet die Website WikiMatrix auf, wo man alle Produkte über Dutzende von Kriterien miteinander vergleichen kann.

Eines der zentralen Unterscheidungskriterien betrifft die Frage, ob ein Wiki seine Daten in einer Datenbank oder in Dateien ablegt. Für grosse Wikis mit vielen Besuchern ist eine Datenbank sicher die richtige Lösung. Kleinere Wikis mit einem beschränkten Benutzerkreis kommen dagegen gut mit einer datei-basierten Datenspeicherung aus und lassen sich dadurch wesentlich einfacher auf einem Webserver installieren.

Ein populärer Vertreter der zweiten Gattung ist DokuWiki: Es bietet eine gute Grundausstattung und ist zudem über eine Plug-In-Architektur einfach erweiterbar (vgl. WikiMatrix Feature List). Hervorzuheben wären folgende Features:

  • History aller Änderungen mit Vergleichsmöglichkeit früherer Versionen
  • Einbindung von Bildern und anderen Media-Elementen
  • Namespace-Konzept
  • automatisch generiertes Seiteninhaltsverzeichnis
  • Benutzerverwaltung und Rechtemanagement
  • index-basierte Volltextsuche
  • Template-Konzept ermöglicht eine individuelle Optik
  • über 100 Plug-Ins verfügbar (beispielsweise für Musiknoten, chemische Formeln, Google Maps, Umfragen und Charts)

image

Das einzige, was ich spontan vermisse, ist ein echter WYSIWYG-Editor. Zwar gibt es oberhalb des Eingabefelds Buttons für die wichtigsten Formatierungsoptionen, aber diese erzeugen nur Plaintext mit der klassischen Wiki-Syntax. Was für Wiki-Puristen genau das Richtige ist, könnte eine unnötige Hemmschwelle für weniger technisch orientiert Anwender sein. Ansonsten ist DokuWiki aber ein fast ideales System, um im Team online Dokumentationen aller Art zu erstellen.

DokuWiki ist in PHP entwicklet und unterliegt der GNU General Public Licence v2.

JumpBox: Server-Software ohne Installationsaufwand testen

von

Eine datenbank-basierte Web-Applikation zu testen ist in der Regel deutlich aufwändiger als ein Desktop-Programm: Zunächst benötigt man Web-, Application- und Datenbank-Server, anschliessend sind meist diverse Konfigurationsarbeiten notwendig. Dass es heute auch einfacher geht, verdanken wir Packages wie beispielsweise XAMPP (vgl. Apache Friends: Umfrage zu XAMPP 2.0), WOS (vgl. WOS Portable und WOS X: Der WAMP-Server für den USB-Stick) und natürlich den diversen Virtual Appliances (vgl. Freie Betriebssysteme auf Virtuellen Maschinen).

Auch JumpBox nutzt das Konzept von Virtual Appliances. Aktuell stehen Packages mit den Open-Source-Programmen MediaWiki, WordPress, PunBB und vTiger zum Download bereit. Die virtuellen Maschinen laufen nicht nur mit dem Open Source Produkt Xen, sondern auch mit der kommerziellen VMware (wobei der erforderliche VMware Player kostenlos verfügbar ist). Wie das Video auf der JumpBox-Homepage zeigt, funktioniert das Ganze sehr einfach. Um eine relevante Grösse in der Open-Source-Szene zu werden müsste JumpBox allerdings die Auswahl der verfügbaren Applikationen noch deutlich grösser werden.