Jump to navigation Jump to search

A Guide to configuring Namespaces in MediaWiki

This article is part of a series compiled as a guide to encourage and assist those building a MediaWiki-based website in a hosted environment.

Each article links to relevant documentation from the website and the website. Where the official documentation does not adequately cover the issues for a hosted site, or is too 'advanced', additional information, explanation and advice is provided.

A Namespace is a container for content.

The Main namespace in MediaWiki, NS_MAIN holds the pages you create, by default, and therefore does not need to be identified. Other namespaces, particularly custom namespaces which you can configure yourself, have a name like NS_FISH, for example. Each page about fish could be within this namespace and, if you configure an alias which allows both upper ands lower case, could be named Fish:Trout, or Fish:Salmon. Other namespaces on a natural science wiki could, for example, be NS_BIRDS, NS_MAMMALS, NS_DINOSAURS etc. The schema can be developed to your own design. If you permit the use of sub-pages then you could create a branching structure holding pages like Fish:Salmon/Atlantic, Fish:Salmon/Pacific etc.

This is a very powerful feature of MediaWiki. Planning a namespace structure can assist with configuring an Intranet, a Content Management System, or any wiki which has a specified set of topics.

Namespaces can be added progressively but plan well because implementing changes after creation may be difficult and risks loss of content.

Namespaces are configured in the LocalSettings.php file which you would usually have access to if MediaWiki is in a hosted environment.

Standard Namespaces

Namespace Overview
The Manual:Namespace provides a technical overview. MediaWiki has 18 built-in namespaces.
Namespace Constants
Each of the standard namespaces is defined by a name, in uppercase and has a numerical ID. These are listed in the Manual:Namespace constants.
Talk namespaces
Eight of the standard namespaces are Talk namespaces associated with a subject namespace. For example, the main namespace NS_MAIN has an associated talk namespace NS_MAIN_TALK. Each Talk namespace holds the discussion page associated with the content page.
Standard namespace properties and purpose
The Help:Namespaces describes each of the standard namespaces.

Custom Namespaces

The Manual:Using custom namespaces goes through the steps required to create a custom namespace. Each namespace has a number which is even for the Subject namespace and odd for the associated Talk namespace.

There are several variables which should be configured for each custom namespace. These are:-

Configures additional, custom namespaces.
This variable does not define whether or not the namespace can hold content. What it does is register that the content should be included when counting the number articles in the wiki; and other Special pages such as: random pages, short pages, long pages etc..
If Namespace Protection is enabled for a custom namespace then you can also define permissions using $wgGroupPermissions.
The NS_MAIN namespace does not allow sub-pages by default. This can be enabled with a line in LocalSettings.php
$wgNamespacesWithSubpages[NS_MAIN] = true;
The variable can be configured for each of your custom namespaces to allow creation and use of sub-pages.
Enables you to define a user-friendly name for the namespace which can be used instead of the primary name which must be capitalized. For example, Fish instead of FISH, or Protozoa as an alias for NS_PROT.
Using the Groups which have already been defined in LocalSDettings.php you can use this variable to configure permissions for users or user groups, for each namespace, including your custom namespaces.

An Example

All configuration settings for custom namespaces go in the LocalSettings.php file. If you have separated your custom configurations into a separate file then that is where you would put the namespace configurations.

In the example below all of the variables are collected together for one custom namespace. Some administrators would keep the variables together so that multiple custom namespaces are configured as a group for each variable. That is how some of the examples in manuals are organized. Another alternative is to group the values in an Array. All methods work; just choose whichever is clearer and works for you.

Namespaces are numbered. The Manual:Using custom namespaces recommends using numbers above 3000. The example here uses 3200 for the content namespace and 3201 for the associated Talk namespace.

The example uses the natural science namespace NS_FISH and assumes a group called scientists exists and has both read and edit permissions; but the group * for all users is restricted to read-only permissions.

Each line is preceded by a comment, starting with # which describes the purpose of the configuration which follows. Comments are useful and optional.

## Fish Namespace Configuration

# Define constants for Fish namespace
define("NS_FISH", 3200);
define("NS_FISH_TALK", 3201);

# Add extra namespaces
$wgExtraNamespaces[NS_FISH] = "Fish";
$wgExtraNamespaces[NS_FISH_TALK] = "Fish_talk";

# Identify as a content namespace
$wgContentNamespaces[] = NS_FISH;

# Required before configuring Group Permissions
$wgNamespaceProtection[NS_FISH] = array( 'editFISH' );

# Define scientist permissions
$wgGroupPermissions['scientist']['editFISH'] = true;

# Restrict other users
$wgGroupPermissions['*']['editFISH'] = false;

# Allow sub-pages
$wgNamespacesWithSubpages[NS_FISH] = true;

# Create namespace alias
$wgNamespaceAliases['Fish'] = NS_FISH;
$wgNamespaceAliases['Fish_TALK'] = NS_FISH_TALK;


The information or advice provided in this Guide is based on, or links to, official documentation for MediaWiki and was accurate when this article was created. However, some variation may occur between versions of MediaWiki; and the specifics of web hosting varies by service provider. Consequently, you should always create an effective backup before making any changes; ensure that you can restore your database and website; read the Release Notes before upgrading; and apply best practices to the management of your website. Any action that you take based on information provided here is at your own risk and the author accepts no liability for any loss or damage.