Handbuch:Verwendung von benutzerdefinierten Namensräumen
Zusätzlich zu den eingebauten Namespaces ist es möglich, benutzerdefinierte Namensräume zu einer MediaWiki-Installation hinzuzufügen, um Inhalte weiter zu trennen und eine logischere Organisation zu ermöglichen.
Benutzerdefinierte Namensräume sind mit der Konfigurationsrichtlinie $wgExtraNamespaces
einfach zu verwalten.
Es ist auch möglich, Aliasnamen für benutzerdefinierte (und auch vordefinierte) Namensräume zu definieren, indem man die Konfigurationsdirektive $wgNamespaceAliases
verwendet.
Eingige Erweiterungen machen es Dir leicht benutzerspezifischen Namensräume zu erstellen
Beispiele enthalten NamespaceManager und BlueSpiceNamespaceManager .
Einen benutzerdefinierten Namensraum erstellen
Sie registrieren zusätzliche Namespaces, indem Sie sie der globalen Variable $wgExtraNamespaces
in Ihrer Datei "LocalSettings.php" hinzufügen.
Alle Namensräume benötigen einen eindeutigen numerischen Index in diesem Array.
Als ein Beispiel einer einfachen ERstellung eines benutzerspezifischen Namensraums, füge folgende Zeilen in die "LocalSettings.php" Datei die "Foo" als Namensraum 3000 definiert und den zugehörigen Namensraum "Foo_talk":
Note that having a talk namespace associated with your custom namespace is currently a hard requirement.
// Definiert Konstanten für einen zusätzlichen Namensraum.
define("NS_FOO", 3000); // Diese Zahl MUSS gerade sein.
define("NS_FOO_TALK", 3001); // Dies MUSS die darauffolgende Ganzzahl sein.
// Füge Namensräume hinzu.
$wgExtraNamespaces[NS_FOO] = "Foo";
$wgExtraNamespaces[NS_FOO_TALK] = "Foo_talk"; // Beachte die Unterstriche in den Namen der Namensräume.
- Wähle eine unbenutzte Nummer
- Als Grundsatz gilt, dass die Zahlen der Namensräume 100-199 für seitenspezifische namensräume reserviert sind, obwohl einige Erweiterungen diesem Grundsatz nicht entsprechen. Ersteller von Erweiterungen nutzen höhere Zahlen bis 32767. Wenn Du einen Index wählst solltest Du jede Zahl vermeiden, die in extension default namespaces genannt wird, da Du die Erweiterung eventuell später installieren möchtest. Die Zahlen von 3000 bis 4999 sind den System-Administratoren vorbehalten, um benutzerspezifischen Namensräume zu erstellen. (Ebendfalls solltest Du jeden Namensraum mit name vermeiden der bereits in Extension default namespaces (Festgelegte Namensräume von Erweiterungen) ist.)
- Gerade vor Ungerade
- Beachte der oben genannte Zahlenbereich 3000 für den Namensraum ist ein Beispiel.
- ein gerader Namensraum Index ist für Themen Namensraum bestimmt.
- ein ungerader Index folgt unmittelbar darauf und bestimmt den Diskussion ("talk") Namensraum
- Erstelle den Diskussions-Namensraum ebenfalls.
- Normalerweise erstellt Du einen Diskussions "Talk" namensraum zusammen mit einem benutzerspezifischen Namensraum. Mit diesem Beispiel, wenn Du eine Seite verschiebst in den Namensraum "Foo", wird angezeigt auch die verbundene Diskussions-Seite mit zu verschieben (wenn es eine gibt) und wenn Du dich dafür entscheidest, wird MediaWiki diese Diskussions-Seite in "Foo talk" setzen.
- Keine Leerzeichen
- Verwende Unterstriche anstatt von Leerzeichen für Benennungen von Namensräumen. 'My Namespace' ist hier unzulässig; verwende stattdessen 'My_Namespace'.
- Keine Bindestriche
Der großgeschriebene Teil erlaubt keine Bindestriche, aber sie können sicher zu den Prefix-Titeln ergänzt werden. Beispiel:
$wgExtraNamespaces[NS_FOOFOO] = "Foo-Foo";
- Gib den gewählten Nummern einen Namen
- Das Beispiel definiert Konstanten für die Namensraum IDs, sodass Du später auf die Namensräume Deiner Konfiguration verweisen kannst, wie z.B. in
$wgNamespaceProtection
,$wgNamespacesWithSubpages
oder$wgExtraGenderNamespaces
Weiter kannst Du zusätzliche Einstellungen für Deinen neuen Namensraum konfigurieren.
$wgNamespaceProtection[NS_FOO] = [ 'editfoo' ]; // Berechtigung "editfoo" um den Namensraum foo zu bearbeiten
$wgNamespacesWithSubpages[NS_FOO] = true; // Unterseiten für den Namensbereich foo erlauben
$wgGroupPermissions['sysop']['editfoo'] = true; // Berechtigung "editfoo" für die Benutzer der Gruppe "sysop" erteilen
- Tue es frühzeitg
- Veränderungen an
$wgExtraNamespaces
müssen durchgeführt sein während der MediaWiki Initialisierung, z.B. für den Fall, dass eine Erweiterung usw. mit dieser neu erstellen benutzerspezifischem Namensraum funktionieren soll. Stelle sicher, dass du diese zuvor definiert und benannt hast, bevor du die entsprechende Erweiterung aufrufst. Beispielsweise kann dies nicht in einem post-initialisierten Hook wie$wgExtensionFunctions
verändert werden.
- Achten Sie auf Kollisionen mit URL-Protokollen
- Der Verlinkungscode von MediaWiki kennt eine Reihe von URL-Protokollen, die in der Variable
$wgUrlProtocols
definiert sind. Wenn Deine Namensraumbenennung identisch zu einem aus dem Protokoll ist, wirst Du Störungen im [[wikilinks]] auf den Seiten Deinen benutzerspezifischen Seiteen erzeugen. Dies tritt überlicherweise auf wenn jemand versucht den Namensraum "News" zu erstellen, weilnews:
ein URL Protokoll für NNTP Newsgroups ist. - Um dies zu vermeiden setzt man das entsprechende URL Protokoll ausser Kraft, in dem man folgenden Code in die "LocalSettings.php"-Datei einfügt (man ersetzt
news
durch den kleingeschriebenen Name des Protokoll das man entfernen möchte):
$wgUrlProtocols = array_diff( $wgUrlProtocols, array( 'news:' ) );
In Erweiterungen
Erweiterungen fügen oft ihre eigenen Namensräume hinzu, wie z.B. der "Topic"-Namensraum der Flow -Erweiterung.
Eine Erweiterung kann bedingungslos zu $wgExtraNamespaces
hinzufügen, wie oben beschrieben, oder wenn ihre Namensraumregistrierung bedingt ist (zum Beispiel definiert EventLogging nur seinen "Schema"-Namensraum im Wiki, wo es Schemas speichert), dann kann sie eine Handler-Funktion für den CanonicalNamespaces -Hook hinzufügen, die entscheidet, was zu tun ist.
Die zeitliche Abstimmung der Registrierung von Erweiterungen ist subtil.
Funktionen, die Erweiterungen mit $wgExtensionFunctions
registrieren, werden zu spät ausgeführt, um zusätzliche Namensräume zu registrieren (task T47031).
Daher sollten Erweiterungen den <code<>CanonicalNamespaces-Hook auf Dateiebene (in MyExtension.php
) binden und dort überprüfen, ob das Wiki den zusätzlichen Namensraum aktivieren sollte oder nicht.
Erweiterungen können Namespace-Berechtigungen und Inhalts-Handler bedingungslos auf Dateiebene konfigurieren, da sie nicht erfordern, dass der Namespace tatsächlich erstellt wird.
MediaWiki Version: | ≥ 1.25 Gerrit change 166705 |
Das Registrierungssystem extension.json
verfügt über einen Schlüssel namespaces
, mit dem eine Erweiterung ihre Namensräume auflisten kann, die immer existieren sollten.
Aus der Gadgets -Erweiterung:
"namespaces": [
{
"id": 2300,
"constant": "NS_GADGET",
"name": "Gadget",
"protection": "gadgets-edit"
},
{
"id": 2301,
"constant": "NS_GADGET_TALK",
"name": "Gadget_talk"
},
]
Sie unterstützt auch den CanonicalNamespaces
-Hook.
Erweiterungen sollten die Erweiterungsregistrierung gegenüber CanonicalNamespaces bevorzugen.
Beachten Sie, dass das Hinzufügen einer Erweiterung zu LocalSettings.php nicht unbedingt dazu führt, dass relevante Namensraumkonstanten als globale Variablen für andere Erweiterungen verfügbar sind.
Inhaltsnamensräume
Wenn die Seite für die Website-Statistiken (siehe Special:Statistics) erstellt wird, verwendet MediaWiki Werte, die in der Datenbank gespeichert sind, um bestimmte Gesamtzahlen zu berechnen. Eine bestimmte Gesamtzahl ist die Anzahl der Artikel oder die Anzahl der Inhaltsseiten.
Damit eine Seite als Artikel oder richtiger Inhalt betrachtet wird, muss sie:
- sich im Hauptnamensraum oder einem definierten Inhaltsnamensraum befinden.
- keine Weiterleitung-Seite sein
- Mindestens einen internal link enthalten
Wenn Sie benutzerdefinierte Namensräume erstellen, um zusätzliche Inhalte aufzunehmen, ist es eine gute Idee, dies in der Konfiguration anzugeben. This is done via the $wgContentNamespaces configuration directive.
To extend the example above, one might add the following to the "LocalSettings.php" file:
$wgContentNamespaces[] = 3000;
- oder
$wgContentNamespaces[] = NS_FOO;
MediaWiki will now consider pages in the "Foo" namespace to be articles, if they meet the remaining criteria, and will include them when updating the site statistics counters.
Running maintenance scripts
- When adjusting the value of configuration parameter
$wgContentNamespaces
, it is a good idea to run either the "path/to/maintenance/updateArticleCount.php or "path/to/maintenance/initSiteStats.php" script to update the internal statistics cache (see Handbuch:Wartungsskripte ).
Warum möchtest du einen benutzerdefinierten Namensraum
There are several reasons you might want this:
- A custom namespace can be used to hold content that should not be shown on the search results page, for example pages that are used only for transclusion.
- Certain namespaces require additional privilege(s) for editing.
- You want certain namespaces not to be subjected to certain limitations or default settings ($wgNoFollowNsExceptions for example)
- A uniform prefix for specific content(s), which is searchable for that namespace only
- If you're a MW developer, sometimes you need to have a custom namespace for your extension(s)
Handeln mit bestehenden Seiten
When storing page records, MediaWiki uses a namespace's numerical index, along with the remaining title text. Thus, when a page is created in a namespace that doesn't exist, e.g. "Bar:Some page", it is treated as being in the main namespace.
This can cause problems if adding a custom namespace definition for "Bar" at a later date, as MediaWiki will look for a page indexed via the proper namespace, but won't be able to find it, thus making the content inaccessible.
To correct this problem, there are three main approaches.
Konfliktseiten verschieben
If the number of pages affected is small (e.g. "Bar" held five pages created before the namespace was defined in the site configuration), then the following approach might be suitable:
- Comment out the namespace definition in the configuration file
- Access each affected page, and move it out of the pseudo-namespace, e.g. move "Bar:Some page" to "Bar2:Some page"
- Un-comment the namespace definition
- Move the affected pages back into the new namespace
Use a maintenance script
Within the maintenance directory, there is a maintenance script which performs the above operation more effectively for a large number of pages; NamespaceDupes.php
It is simple to use, but as with all MediaWiki maintenance scripts, consult the available usage information first (use --help
as an option).
Use a database query
To move all pages "Bar:Some page" into namespace 3000, make the following database query:
UPDATE page SET
page_title = REPLACE(page_title, 'Bar:', ''),
page_namespace = 3000
WHERE page_title LIKE 'Bar:%' AND page_namespace=0
To handle discussion pages:
UPDATE page SET
page_title = REPLACE(page_title, 'Bar_talk:', ''),
page_namespace = 3001
WHERE page_title LIKE 'Bar_talk:%' AND page_namespace=1
After such fiddling, run the refreshLinks.php script and the updateSearchIndex.php script to update internal links and search results in your wiki. Note that external search engines like Google will take some time to update their index.
Entfernen benutzerdefinierter Namensräume
The problem addressed above also occurs when a custom namespace definition is removed; MediaWiki is no longer aware of the numerical index for the namespace, and attempts to search the main namespace for the desired pages, leading to inaccessible content. This is a rare occurrence, since most sites will not need namespaces removed, but it is a problem. (See mailing list discussion).
Beispiel, wie man Flow und den Thema-Namensraum entfernt:
- Deinstalliere Flow
- Füge temporär $wgExtraNamespaces[2600] = 'Topic'; in der Konfiguration hinzu
- Benutze deleteBatch.php um alle Seiten im Thema-Namensraum zu löschen
- Entferne die $wgExtraNamespaces-Einstellung
Umbenennen benutzerdefinierter Namensräume
Suppose that you need to rename custom namespace "Foo" to "New" without performing a mass move of pages.
The easiest way to achieve this is to preserve the namespace ID (here "3000
") as well as the namespace constant (here "NS_FOO
"), modify the (visible) namespace title and add the old one as an alias.
ändere
Namensraumkonflikte vermeiden
In order for you to avoid namespace conflicts e.g. your namespace has the same number as a namespace defined by an extension, the extension namespace list shows you which numbers to avoid to prevent conflicts.
Defining $wgNamespacesToBeSearchedDefault , $wgNamespacesWithSubpages , $wgContentNamespaces or $wgNamespaceAliases for an ID not associated to any existing namespace in $wgExtraNamespaces doesn't break the wiki; MediaWiki gracefully ignores such configurations.
Namensräume gestalten
For example, to set the background color of pages in a particular namespace (and its associated talk namespace) you can add the following code to your common.css:
.ns-3000 #content, .ns-3001 #content { background-color: #f3f3ff; }
.ns-3000 div.thumb, .ns-3001 div.thumb { border-color: #f3f3ff; }
where 3000
is the namespace's index and #f3f3ff
is the color you want as its background color.
You might also want to change the name of the tab from its default (the namespace's name). This is located in your system messages at MediaWiki:nstab-namespace.
Siehe auch
- Handbuch:Konfigurationseinstellungen#Namensräume
$wgNamespacesToBeSearchedDefault
- Extension:NamespaceManager - for management of namespaces
- Namespace manager - as originally proposed for MW1.6-wikidata and its successors.
Aktuell vom OmegaWiki-Projekt genutzt.
- Extension:SkinPerNamespace - to use a different skin in a namespace
- Extension:SpecialNamespaces - a modified version of the Erweiterung:Interwiki which changes it to provide a namespace manager as a special page.
- Extension:Lockdown - to control access to namespaces
- Extension namespace registration
- Maintenance scripts