Wikipedia:Technik/Skin/Einstellungen

Skin: Fortgeschrittene Benutzereinstellungen

---

Diese Projektseite beschreibt, auf welchen Wegen angemeldete Benutzer das Erscheinungsbild der Seiten im Wiki individuell umgestalten und zusätzliche Funktionen verfügbar machen können. Gestaltungswillen und Programmierlust sind kaum Grenzen gesetzt.

Anonyme (nicht angemeldete, „IP“) Benutzer können ähnliche Wirkungen über Greasemonkey erzielen.

Es gibt zwei Typen von Ressourcen, die verwendet werden können:

• CSS – optische Darstellung des Seiteninhalts (Farben, Schriften, Schriftgröße, Layout); Näheres unter WP:CSS.
• JavaScript (JS) – aktive Funktionen; Näheres unter WP:JS.

Sie können als persönliche Benutzer-Unterseiten angelegt werden und erhalten dann das jeweilige Content Model. Der CodeEditor schaltet sich automatisch ein.

Reihenfolge

Die Ressourcen werden in einer bestimmten Ordnung wirksam. Insbesondere bei CSS überschreibt dabei jeweils die darauffolgende Definition die vorangehende („Kaskade“). Auch mit JavaScript kann es sinnvoll sein, vorangegangene Werte zu überschreiben, oder man benötigt zuvor definierte Funktionen. Die grundsätzliche Abfolge ist:

1. Weltweit (WMF)
2. Lokales Projekt (deutschsprachige Wikipedia) – Ressourcen im MediaWiki-Namensraum (nur durch bestimmte Administratoren zu ändern)
3. Benutzerdefiniert (global)
4. Benutzerdefiniert (lokal)
5. gruppenspezifisches CSS und analog JS (nur durch bestimmte Administratoren zu ändern)

Außerdem können zu beliebigen Zeitpunkten weitere angeforderte Ressourcen eintreffen. Hier hängt es vom Browser, der Netzwerkgeschwindigkeit, bereits vorhandenen oder frisch vom Server zu ladenden Versionen ab, wann Ressourcen wirksam werden. Für JS gibt es Möglichkeiten, die Ausführung erst fortzusetzen, nachdem externe Quellen geladen wurden.

Lokale benutzerdefinierte Standardressourcen

Die Ressourcen werden im momentanen Wiki als Benutzerunterseiten mit standardisierten Namen erwartet und ohne weiteres Zutun geladen, sofern sie vorhanden sind (die Verlinkungen auf die Ressourcen wirken nur bei angemeldeten Benutzern).

Desktop

Ressourcen für Desktop-Darstellung

Reihenfolge	CSS	JS	Anm.
1. gemeinsam für alle Skins	mein/common.css	mein/common.js
2. Skin-spezifisch eine von zurzeit	mein/vector.css	mein/vector.js	2010
	mein/vector-2022.css	mein/vector-2022.js
	mein/monobook.css	mein/monobook.js
	mein/modern.css	mein/modern.js
	mein/cologneblue.css	mein/cologneblue.js
	mein/timeless.css	mein/timeless.js

Die Seiten werden als Einheit in einem dynamisch generierten Modul user zusammengefasst. Das Modul ist auch definiert, wenn Benutzer nicht angemeldet sind, hat dann jedoch keinen Inhalt.

• Die Definitionsseiten für einzelne Skins sind älter als die Möglichkeit gemeinsamer Konfigurationsseiten common.
• Wenn keine Eigenschaften deklariert sind, die spezifisch für eine Skin sind, sollte man sie allmählich in die common-Definition (oder gleich global) übernehmen, damit sie auch beim Umschalten der Skin verfügbar sind.
• Umgekehrt lassen sich durch Verteilung der Ressourcen auf common und verschiedene Skins unterschiedliche Szenarien für verschiedene Arbeitsumgebungen schaffen: In der normalen Skin hat man nur die Standard-Ressourcen, die man immer braucht; durch einfaches Umschalten der Skin käme man in einen anderen Modus, in dem aufwändige und komplexe Werkzeuge zugeschaltet werden, und einige andere ggf. nicht mehr eingebunden wären. Auf diese Weise lassen sich auch neue Werkzeuge erproben.

Mobil

Ressourcen für Mobil-Darstellung

CSS	JS
mein/minerva.css	mein/minerva.js

Die Desktop-Einstellungen des lokalen Projekts sollen ignoriert werden. Das Modul user müsste analog als verfügbar gemeldet werden, was im November 2014 noch nicht der Fall war. Die globalen Standardressourcen waren im November 2014 noch nicht mobil verfügbar.

Andere benutzerdefinierte Ressourcen

Es kann noch beliebig viele weitere Benutzer-Unterseiten mit Code geben. Diese zählen jedoch nicht zu den Standardressourcen und müssen individuell geladen werden; siehe auch „Benutzerskripte“.

Globale benutzerdefinierte Standardressourcen

Seit 2014 gibt es die Möglichkeit, automatisch für alle Wikis der WMF individuelle Benutzerressourcen einzubinden.

Die Seiten liegen im Meta-Projekt:

Gemeinsames CSS/JavaScript für alle Wikis (weitere Informationen):

CSS	JS
meta:mein/global.css	meta:mein/global.js
Anmelden im Meta-Projekt

Die Seiten werden in einem dynamisch generierten Modul ext.globalCssJs.user zusammengefasst. Wenn user geladen wurde, sind die globalen Standardressourcen auch bereits geladen. Das Modul ist auch definiert, wenn Benutzer nicht angemeldet sind, hat dann jedoch keinen Inhalt.

Wenn zwar nicht für alle Wikis, aber für viele oder zumindest mehrere Projekte eine gemeinschaftliche Definition aktiviert werden soll, kann per JavaScript abgefragt werden, in welchem Projekt das globale Skript eingebunden ist, oder es können andere Eigenschaften bestimmt werden. Beispiele:

Konfigurationsparameter	Bedeutung	Nutzung
wgDBname	Datenbankname	Analyse auf die Projektart; etwa ob wikisource enthaltend.
wgContentLanguage	Sprachcode des Projekts	Nur in deutschsprachigen Wikis eine entsprechende Rechtschreib- und Grammatikprüfung einbinden.
skin	Aktuelle Benutzeroberfläche (Schlüsselwörter wie oben)	Analyse auf die momentane Skin; oder auch ein Mobilgerät.
Siehe auch: Code-Beipiele (englisch)

Aus Sicherheitsgründen wirken die beiden globalen Standardressourcen nicht auf sich selbst. Wenn man hier einen schweren Fehler machen würde, könnte man sich selbst blockieren. Über die URL zur Anmeldung und dann die URL der Seiten lässt sich hingegen der Quellcode immer erreichen.

Zur Wirksamkeit lokaler Variablen siehe Kapselung.

Aktivierung

In der Benutzereinstellung (Registerkarte „Aussehen“) können angemeldete Benutzer unmittelbar auf alle Seiten mit Standardressourcen zugreifen. Die globalen Seiten im Meta-Projekt stehen unter „Gemeinsames CSS/JavaScript für alle Wikis (weitere Informationen):“.

Zurzeit nicht angemeldete Benutzer können ihre sonst genutzten Benutzerseiten über Greasemonkey einbinden.

Browser-Cache

An die URL der Standardressourcen wird seit 2011 ein Zeitstempel angefügt, der die letzte Veränderung angibt. Damit wird immer die gültige Definition eingebunden; Leeren des Browser-Cache (siehe Hilfe:Cache) ist deshalb nicht mehr erforderlich.

Das gilt aber nicht für Einbindung anderer Seiten. Hier hat jede Version die identische URL und im Browser-Cache können deshalb veraltete Versionen vorkommen. Dann wären die auf Skin/JS angegebenen Möglichkeiten einzusetzen.

JavaScript

Beim Zusammenwirken mehrerer unterschiedlicher Skripte sind zwei Fragestellungen von Interesse:

1. Warten, bis ein anderes Skript geladen wurde;
2. Übermittlung von individuellen Konfigurationswünschen und aufrufbaren Funktionen an andere Skripte.

Der zweite Punkt ist inzwischen zu einer echten Herausforderung geworden.

In den frühen Jahren hatten die Programmierer Hunderte von Variablen und Funktionsdefinitionen verstreut. Waren die Namen auch noch kurz und nicht sehr einfallsreich, dann überschrieben sie sich gegenseitig, die falschen Funktionen wurden ausgeführt. Selbst wenn es nicht zu Namenskonflikten kommt, ist es bei einer Auflistung von 500 Variablen und Funktionen in einer Wiki-Seite nicht mehr möglich, die Herkunft und Wirkung der meist wenig aussagekräftigen Bezeichner nachzuvollziehen.

Seit mehreren Jahren wird in MediaWiki dem entgegengewirkt, indem nur noch Komponenten des Objekts mediaWiki in strukturierter Weise genutzt werden. Für Anwendungen steht der Container mw.libs zur Verfügung.

Kapselung

Langfristig ist vorgesehen, die Standardressourcen automatisch zu kapseln. Um dann zwischen unterschiedlichen Einheiten Daten auszutauschen, müssen definierte Schnittstellen benutzt werden. Lokale Variablen (mittels var deklariert oder gar völlig undeklariert) in den Benutzerskripten haben keine Wirkung nach außen und stören dort nicht mehr. In der globalen JS-Definition wurde hierfür bereits ein Anfang gemacht.

• Skripte, die für andere Skripte eine Servicefunktion bereitstellen, sollten beispielsweise ein Anwendungsobjekt in mw.libs verwenden, dort alle Funktionsaufrufe anbieten und über dieses Anwendungsobjekt auch konfiguriert werden.
• Auch für sich selbst kann man ein individuelles Anwendungsobjekt aus seinem Nicknamen basteln und dieses als Komponente von entweder mw.libs oder window anlegen.

Keine gute Idee wäre es, die pollution of the global namespace dadurch fortzusetzen, dass wieder alle Skripte Einzelvariablen unter window definieren.

Weitere Informationen

MediaWiki: Extension:GlobalCssJs – Technische Informationen (englisch)

MediaWiki: Help:Extension:GlobalCssJs – Code-Beipiele (englisch)