Aufrüsten zu neueren Versionen von MediaWiki

Im Januar 2012 war die aktuelle Version von MediaWiki (MW) 1.18. Die von mir betreuten Wikis waren jedoch auf dem Stand von 1.15 (eines sogar noch bei 1.11). Bisher hatte ich immer manuell aufgerüstet, d.h. per FTP die Ordner "extensions, images skins" und die LocalSettings.php herunter geladen, ein komplettes Paket an die Stelle des alten Wikis mit den heruntergeladenen Ordner und der php-Datei hochgeladen und danach lief die Sache.

Die offizielle Lösung

Die bei MediaWiki beschriebene Lösung sieht etwas anders aus, je nachdem ob es nur einen FTP Zugang oder einen Shell-Zugang gibt. Es wird empfohlen, ein volles Backup zu machen. Das geht bei einem Shell-Zugang mit den Kommandos in einem Terminal recht flott. Nachdem ich mich über ssh user@domain eingewählt habe, ginge es z.B. mit dem Befehl "copy" (cp). Damit wird in der Regel eine Datei kopiert. Wenn ein Ordner kopiert werden soll, wird die "-r" Option (recursive) gebraucht, die alle Dateien innerhalb eines Ordners mit kopiert. Ein komplettes Backup könnte also so aussehen

cp -r wiki wikibackup-2012

In Nautilus könnte ich auch kopieren, aber das dauert ungleich länger. Da ich anschließend aber die neue Version hochladen würde, könnte ich den Ordner umbenennen, einen Ordner mit dem Namen des alten Wiki erstellen und alles dort hinein kopieren (dauert bei Nautilus aber eine halbe Stunde).

In jedem Fall ist natürlich auch die Datenbank zu kopieren (ein Backup erforderlich). Dazu habe ich immer PHPAdminMysql benutzt, bzw. existieren wöchentliche Backups per Cronjobs in einem gesonderten Ordner. Auch hierfür existieren Befehle für das Terminal, die ich aber noch nicht verstanden habe. Neben der grundlegenden Seite gibt es noch eine Seite mit Skripten, die zum Backup der Datenbank führen sollen.

Die notwendigen Dateien zum Aufrüsten, bzw. die komplette neue Version von MW gibt es im Terminal mit dem Befehl

svn checkout http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_18/phase3

Nach der Empfehlung habe ich die in ein neues (sauberes wird bei MW gesagt) Verzeichnis gepackt, wobei es danach hieß: "If using Subversion, export the files into a clean location. Replace all existing files with the new versions, preserving the directory structure. The core code is now up to date." Hier habe ich nicht verstanden, warum ich ein neues Verzeichnis brauche, wenn ich danach alle alte Dateien mit den neuen Dateien ersetzen soll.

Einfacher ist es vermutlich, den Befehl

svn switch http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_18/phase3/

zu benutzen, der allerdings nur funktioniert, wenn in dem Ordner schon einmal ein "checkout" gemacht wurde.

Virtuelles Experimentieren auf der Festplatte

Es gibt eine ziemlich lange Anleitung wie Apache, MySQL und PHP unter Ubuntu installiert werden kann. Schließlich kann ich auch AppacheMySQLPHP installieren und dort Datenbanken anlegen, etc. Die Anleitung ist u.a. deswegen so lang, weil viele Einstellungen vorgenommen werden müssen und vieles schief laufen kann. Ich denke daher, dass ich mögliche Experimente dann doch lieber auf meinem Notebook unter Verwendung von WikiOnAStick (Mowes) ausprobieren sollte.

Was ich noch nicht verstanden habe ist, warum ich eine mysqldump Datei erstellen soll und wieso eine mögliche Wiederherstellung von beschädigten Datenbanken einfacher gehen soll, als mit "exportieren" und "importieren".

Upgrade der betreuten Websites

Der Provider des DTF (Demokratisches Türkeiforum) in Berlin weigerte sich, einen Shell-Zugang einzurichten, angeblich aus Sicherheitsgründen. Von amnesty international gab es erst einmal keine Rückmeldung, so dass ich in beiden Fällen mit einem FTP-Zugang gearbeitet habe. In der Oberfläche des bei mir unter Ubuntu verwendeten FTP-client "File-Zilla" ging das Hoch- und Runterladen recht flott. Ich habe dabei mit der Umbenennung der Ordner und dann dem Hochladen der neuen Version von MW in den "alten Ordner" (nannte ihn auf der Festplatte um und lud ihn dann hoch) gearbeitet. Danach mussten alle Dateien aus dem Verzeichnis "images" hoch geladen werden. Am Anfang habe ich das auch mit den Erweiterungen ("extensions") gemacht, bis ich merkte, dass einige mit der neuen Version nicht mehr kompatibel waren.

Da ich in den jeweiligen Ordnern nun mw-config/index.php aufrufen musste, um das "upgrade" durchzuführen, habe ich auch in dem Verlauf dann lieber eine neue LocalSettings.php erstellen lassen, anstatt die "alte" Datei einfach in das neue Verzeichnis zu setzen. Es gab dabei immer einen Stolperstein, bei dem Schritt, wo nicht empfohlen wurde, eine neue Datei erstellen zu lassen, es sei denn es gebe Probleme mit dem Wiki. Wenn ich den Schritt überspringen wollte, wurde immer gesagt, dass ich mit dem "upgrade" weiter machen muss, bevor ich Zugang zur Seite habe.

Ich habe dann entweder gegen die Empfehlung gehandelt oder mit "Seite zurück" im Browser die Schritte gefunden, um auch die jeweiligen Datenbanken auf den neuesten Stand zu bringen. Die am Schluss angebotenen erweiterten Einstellungen waren durchaus lohnend, denn damit konnte ich inzwischen als Standard angebotene Erweiterungen installieren und auch den Zugang zum Wiki festlegen. In jedem Fall war es besser, die dann am Schluss doch erzeugte LocalSettings.php runter- und dann hoch zu laden, da es hier erst einmal nur funktionierende Erweiterungen gab.

Das Anlegen eines neuen Administrators war ein Punkt, der nicht übersprungen werden durfte, aber angelegt wurde er nicht wirklich (konnte ihn später nicht unter den Benutzern entdecken).

Das Skin

Alle Wikis des DTF und der Kogrupppe hatte ich mit einem Skin von Paul Gu, die er Gumax nennt und nach

• horizontal
• drop down
• vertical

unterscheidet, gestaltet. Mit dem upgrade auf MW 1.18 gibt es aber nur noch ein skin mit horizontaler Navigation, das mit der aktuellen Version von MW kompatibel ist.

Prinzipiell funktionierten die Seiten auch mit dem "veralteten" vertikalen Skin "Gumax 3.2.1" bzw. 3.3. Jedoch wollte z.B. die Erweiterung "collection" nicht mehr funktionieren und der Platz für die Kategorien auf einer Seite sah seltsam aus, bzw. wurde auf ungewöhnliche Weise "populiert" (alles untereinander als Liste, wobei Seiten ohne Kategorien mit leeren Kästen versehen waren).

Ich habe mich lange und vergeblich bemüht, die horizontale Navigation auf eine vertikale Navigation umzustellen. Mit einem schmutzigen Trick kriegte ich unter Gumax3.2.1 zwar die Erweiterung "collection" zum Laufen, da aber bei weiteren Erneuerungen weitere Probleme zu erwarten waren, habe ich nach einer besseren Lösung gesucht.

Banner auf die Seite setzen

Mit der Seite "MediaWiki:Sitenotice" wird eine Art Kopf ("header") für alle Seiten in einem Wiki gestaltet. Das kann bei Kampagnen wie die Spendenaufrufe von Wikipedia oder ähnlichem sinnvoll sein. Dabei kann auch ein Banner in der Form von

 [[File:banner.jpg]] 

auf die Seite gesetzt werden. Darunter wird evtl. aber Text und/oder Links gebraucht. Jedoch ist es auch hier vermutlich sinnvoller, den eigentlichen "Kopf" der Seite in einem eigenen Skin zu gestalten (s.u.)

Abschalten von Schaltflächen

Mit Angaben in der "MediaWiki:Common.css" (normal in einem Wiki aufzurufen) lassen sich bestimmte Schaltflächen "verstecken". Falls auf dieser Seite z.B. steht:

/* CSS placed here will be applied to all skins */
li#ca-edit { display: none; }
li#ca-nstab-main { display: none; }
li#ca-talk { display: none; }
li#ca-view { display: none; }
li#ca-viewsource { display: none; }
li#ca-history { display: none; }

werden alle Bearbeitungs-Schaltflächen in allen "skins" gelöscht.

Das eigene Skin

Ich hatte es noch nie versucht, aber dieses Mal habe ich ein eigenes Skin erstellt. Dazu bin ich den Schritten auf der Seite bei MediaWiki gefolgt und habe das "skin" Vector kopiert und es "Cogroup" genannt. Einige auf der entsprechenden Seite beschriebenen Schritte (ich glaube 3c und 4) waren nicht möglich und konnten übersprungen werden.

Schaltflächen "entfernen"

Ich könnte in der nun existierenden Datei Cogroup.php bestimmte Passagen löschen, die jeweils mit

div id="irgendwas" beginnen und mit /div 

aufhören. Hier fehlen jeweils die Klammer <vorne und hinten>. Wenn an die Stelle von irgendwas

p-personal kommt verschwindet Anmelden (Login)
p-namespaces = Seite und Diskussion verschwindet
p-views = Bearbeiten und Versionsgeschichte verschwindet
p-cactions = Optionen "löschen", "verschieben", "schützen" und "beobachten" verschwindet

Ich kann aber auch die Seite MediaWiki:Cogroup.css nach dem Muster der oben beschriebenen Seite "...Common:css" bearbeiten. Jedoch waren noch ein paar andere Dinge vorzunehmen. Zusätzlich habe ich eingegeben:

#p-cactions { display: none; } Optionen "löschen", "verschieben", "schützen" und "beobachten" werden unsichtbar
#p-personal { display: none; } Anmelden (Login) und Optionen für Benutzer werden unsichtbar
#p-tb { display: none; } Werkzeuge (toolbox) werden unsichtbar. 

Nachdem in LocalSettings.php nun das eigene Skin "cogroup" als Standard festgelegt wurde, sehen BesucherInnen nicht mehr, dass an den Seiten gearbeitet werden kann. Je nach weiteren Einstellungen in der LocalSettings.php kann die Bearbeitung von Seiten durch unangemeldete BenutzerInnen und anderes verhindert werden. Nun müssten die Leute, denen die Bearbeitung von Seiten erlaubt wurde, aber mitgeteilt werden, dass die Anmeldung über Spezial:Anmelden und die Auswahl eines Skins über Spezial:Einstellungen vorgenommen werden kann. Sobald sie sich dann ein anderes Skin ausgesucht haben, sehen sie wieder alle Möglichkeiten der Bearbeitung.

Das Aussehen verändern

Die Seite MediaWiki:Cogroup.css kann auch dazu benutzt werden, bestimmte Teile der Seiten anders aussehen zu lassen. Auch hier müssen zunächst einmal die Stellen gefunden werden, die anders gestaltet werden sollen. So kann ich in den durch das "Abschalten" der Schaltflächen frei gewordenen Bereich eine Art Banner als Hintergrund setzen.

#mw-head-base {
background-image: url("");
background-color: transparent;
background-repeat:no-repeat;
background-position:center; 
height: 40px;
}

Es ist dabei zu berücksichtigen, dass der Banner nicht sehr hoch sein sollte (Maximum vielleicht 48 Pixel, weil sonst der Hintergrund unter das Suchfeld rutschen könnte. Ich kann aber auch eine Hintergrundfarbe definieren, keine Höhe festsetzen und dabei noch die Ecken rund machen.

#mw-head-base {
background-color:#6699FF; /hier blau, könnte auch "blue" geschrieben werden)
border:1px solid;
border-radius:25px;
-moz-border-radius:25px; /* Firefox 3.6 and earlier */
}

Für die Kogruppe waren weitere Einstellungen sinnvoll, um das Aussehen an die Seiten der deutschen Sektion und des Internationalen Sekretariats von amnesty international anzupassen. Das war zum Einen, die in der MediaWiki:Sidebar definierte Navigation im Schriftbild zu vergrößern und gelb zu hinterlegen. Das geschah mit

#p- {
color: black;
background: yellow;
font-size:150%
}

Optional könnten auch alle Titel der Seiten gelb hinterlegt werden. In MediaWiki:Cogroup.css stünde dann

h1 {
color: black;
background: yellow;
}

Entsprechend sollte ich jetzt für das Demokratische Türkeiforum ein Skin anlegen, das ich mal "demokrat" nennen werde.

Das Gadget "ReferenceTooltip"

Ich sah es zuerst in der englischen Wikipedia, dass ich nicht mehr auf eine Fußnote klicken musste, um sie am Ende der Seite zu sehen und dann wieder auf den Pfeil klicken, um an die Stelle im Text zu gelangen, sondern dass bei "mouse over" (darüber fahren mit der Maus) die Fußnote als Infobox (tooltip) erschien. Was die gadgets (der Schnickschnack) in einem Wiki ist und wie so etwas installiert werden kann wird auf der Seite Extension:Gadgets bei MediaWiki erklärt.

Diese Schritte werden benötigt, wenn mensch die Infoboxen bei Fußnoten auf seiner Seite einrichten möchte.

1. Wie die gadget-extension (gilt dann wohl für jede Art von "Schnickschnack" installiert wird, ist unter "download" auf dieser Seite von MediaWiki beschrieben.
2. Dann muss in der Datei LocalSettings.php die Zeile

require_once( "$IP/extensions/Gadgets/Gadgets.php" );

ziemlich am Ende eingefügt werden.

1. Es werden 3 Seiten benötigt:
   1. Die Seite MediaWiki:Gadgets-definition (falls schon andere "gadgets" installiert wurden, muss hier noch die Definition des neuen gadget eingefügt weren)
   2. Die Seite MediaWiki:Gadget-ReferenceTooltips.js
   3. Die Seite MediaWiki:Gadget-ReferenceTooltips.css

Ich habe die Seiten aus der englischen Wikipedia die *.js Datei und die *.css Datei als Quelltext kopiert und nichts verändert, weil dies "gadget" dort für alle BesucherInnen (sind dort auch potentielle BenutzerInnen) als Standard eingerichtet ist. Es hat auf Anhieb geklappt. Das kann bei dieser Fußnote getestet werden (nur falls die Seite im Cache ist, sollte je nach Browser der Cache umgangen werden, siehe die Seite MediaWiki:Gadget-ReferenceTooltips.js).

Sinnvolle Befehle im Terminal

Auf der Seite Using the Terminal sin viele Befehle erklärt. Ein paar Empfehlungen aus den USA waren:

Das Umbenennen erfolgt mit "mv" für move. Mit einer "-i" Option beim Kopieren wird gefragt, ob überschrieben werden soll. Löschen geht mittels "rm" für remove. Leere Verzeichnisse werden "rmdir" gelöscht und wenn die nicht leer sind, sollte "-f" für force dazu sowie die Unterordner können durch "-r" für recursive gelöscht werden. Die Optionen werden nacheinander geschrieben, z.B. "rm -rf ordner".

Ein normales Backup des Rechners ginge über "rsync" (wohl für remote synchronization). Dabei wird komprimiert und, wenn schon Teile einer Datei auf der anderen Seite (Rechner oder Festplatte) vorhanden sind, werden nur die Unterschiede transferiert. Ein Befehl könnte so aussehen:

rsync -avP orig kopie

Die Optionen könnten sein: -a behält Zeit und Zugangsrechte bei, -v Bericht zum Vorgang und -P (zeigt den Fortschritt. Mit Zugang zu einem anderen Rechner (via ssh) ginge auch

rsync -avP orig user@host:/path/to/file oder rsync -avP user@host:/path/to/file kopie

Aus dem Internet zum eigenen Rechner wäre dann

rsync -avP user@domain:/home/user/domain/ordner /ordner

Da wir uns bei /home/user/ befinden, kann "Ordner" durch ein Verzeichnis darunter und dann der gleiche Name wie im Internet genommen werden. Wenn auf der Festplatte nicht vorhanden, werden die Ordner wohl erstellt. Für das Ganze gibt es auch eine Benutzeroberfläche, was hier beschrieben wird.

Denkfehler:

1. Vom Rechner zum Provider (rsync -avP /extensions user@domain:/wiki/extensions sollte wohl rsync -avP extensions/ user@domain:/wiki/extensions/ heißen), sonst würde der Ordner "extensions" an die Stelle von "wiki" wandern
2. Ordner im Netz verschieben (rsync -avP wikibackup-2012/images domain/wiki/images hiermit wurde im Ordner "images" ein weiterer Ordner "images" angelegt, korrekt sollte sein: rsync -avP wikibackup-2012/images/ domain/wiki/images/