Manual talk:$wgExtraNamespaces

I have attempted this process on wiki 1.6.8 on my site and adding the variable to the localsettings.php file has not seemed to add the new namespaces to the site. Is this information out of date to the current version(s) of mediawiki? or is somethnig going on here? I've seen other issues reported on help pages but noone has solutions for the problem. TheHYPO 02:00, 8 August 2006 (UTC)

Numberrange for namespace

In MediaWiki 1.5.8 namespaces are of type INT(11) in the database. This allows numbers up to 2147483647.

Namespace, where?

Which file should i edit for adding a Namespace? The LocalSettings.php file? or another? --Hó-òh Diskussion 12:47, 19 November 2006 (UTC)

See Help:Custom namespaces. --Linus M. 19:58, 10 May 2007 (UTC)

If this is the code for extra namespaces:

$wgExtraNamespaces = array(100 => "Portal", 101 => "Portal_talk");

Then how do you figure out the code for the default, given namespaces? PatPeter 22:06, 20 November 2007 (UTC)

The standard namespaces are defined in the file includes/Defines.php in the MediaWiki code. -- Tbleher 10:28, 22 January 2008 (UTC)

Why I can create a custom namespace without configure it?

I'm using MediaWiki 1.12, and I can create a page in a namespace which never be defined in LocalSettings.php, like 'wiki/Novel:Crime_And_Punishment'. Is this new feature or I miss something? — Preceding unsigned comment added by Halcyon8 (talk • contribs)

That's not a namespace; you just happened to put a colon in the page title. —Emufarmers^(T|C) 17:07, 22 August 2008 (UTC)

How do I hide my custom namespace's prefix from Category listings?

I administrate a wiki for a RPGMMO and one of the biggest assest on the wiki is our database of items available in the game. We created a Namespace "Item:" for all of these pages to assist in template auto-categorization and user searches, however, all of the listings on the Category:This_or_That pages now have an eyesore of Item:This, Item:That, Item:Then, Item:Now, etc.. Is there anyway I can hide my new namespace from Category listings? Thank you -- Technical 13 (talk) 16:31, 11 April 2012 (UTC)

I didn't understand the exact problem, but looks like you're doing transclusion wrong. When you include a page in another one you also include its categories, unless you puth them in <noinclude> tags etc. --Nemo 21:20, 11 April 2012 (UTC)

He means that if he has something called Foo:Lorem in Category:Ipsum, then he wants Foo:Lorem to appear as just Lorem in the category.--Jasper Deng (talk) 21:23, 11 April 2012 (UTC)

Oh. bugzilla:29975 then. Nemo 21:25, 11 April 2012 (UTC)

Yes, what Jasper said. See this page for a reference (only 4 items, however, there are cats with 500+ pages that will end up with same problem). -- Technical 13 (talk) 01:24, 12 April 2012 (UTC)

So, my wiki team and I came up with a couple workarounds for our issue that I want to share with everyone.

The first workaround is a JavaScript that makes the namespace disappear from the page:

/*
Namespace Stripping
Fix by DDOwiki.com/page/User:Ague
20 April 2012
*/

$('a[title^="Item:"]').each(function() {
    this.innerHTML = this.innerHTML.replace("Foo:", "");
    this.title = this.title.replace("Foo:", "");
}) // Leave final semi-colon out. When MW parses this it automatically adds a semi-colon.

/*
Optionally, uncomment the code below to strip the Foo: from the page title as well.  

MAKE SURE TO DELETE THE }) ABOVE IF YOU UNCOMMENT BELOW!  */

/*
});
// Strip Foo: from the page title
$('h1#title').each(function() {
    this.innerHTML = this.innerHTML.replace("Foo:", "");
});
$('title').each(function() {
    this.innerHTML = this.innerHTML.replace("Foo:", "");
})
*/

The second solution does the same thing with CSS basically:

// Strip "Foo:" namespace from category pages fix
div#mw-pages                               // declare the category listing section
a[title^='Foo:'] {
    font-family: 'Lucida Grande', Arial, monospace;  // your font(s) +", monspace"
    font-size: 12px;        // Set to whatever font-size those items currently use
    display: inline-block;
    overflow: hidden;
    text-indent: -1em;      // fudge this number until your Foo: prefix disappears
}
// strip "NS:" namespace from category pages fix end

Bug in 1.19/Unintended Namespace Prefix Suppressed

I have been using MW for at least 6 years and have not had problems with namespaces until version 1.19, of from an unintended suppression of the namespace and re-classifying of defined namespaces into the main namespace.

Historically, defining a namespace for various usage (general classification, templates, etc.) was done via the classic:

define( 'NS_IMAGE', NS_FILE );
define( 'NS_IMAGE_TALK', NS_FILE_TALK );

or

define( 'NS_MOO_ATI', NS_MOO_ATI );
define( 'NS_MOO_ATI_TALK', NS_MOO_ATI_TALK );
define("NS_MOO_ATI",518);
$wgExtraNamespaces[MOO_ATI] = "Moo_ATI";
$wgPreloaderSource[ MOO_ATI ] = 'Template:Moo_ATI_Template';
define("MOO_ATI_TALK",519);
$wgExtraNamespaces[NS_MOO_ATI_TALK] = "Moo_ATI_Talk";

formatting. 1.19 apparently has changed the means of creating custom namespaces, one theory originally included a scalability conflict (only x num of custom namespaces) which has since been dis-proven.

Another theory is that the bug is a security vulnerability. Namespaces have a greater security conflict in dealing with server accessibility, the scripts for MySQL/PHP in MW have always been targets for hacker 'bid wars' seeking to execute serverjackings by changing the MySQL/PHP directories. One known area that you might want to test is the 'includes' directory, which host many new maintenance scripts such as 'HipHop' which may create incompatibility issues with namespace functions of mw1.19 and up.

My question: When creating new namespaces in mw1.19, why does the new namespace not record as an integer and register within its assigned namespace? - unsigned comment left by somebody

There is no security concerns in using extra namespaces. As has always been, there is some limit to the number of namespaces, but that limit is a very big number (I think its roughly 2 billion, whatever the size of a mysql int is, which I assume is 2³², in any case really super big number). I'm not sure what you're doing with the define's in the code above, instead you should be doing something like:

 define( 'NS_MOO_ATI', 518);
 define( 'NS_MOO_ATI_TALK', 519 );
 $wgExtraNamespaces[ NS_MOO_ATI ] = "Moo_ATI";
 $wgPreloaderSource[ NS_MOO_ATI ] = 'Template:Moo_ATI_Template';
 $wgExtraNamespaces[ NS_MOO_ATI_TALK ] = "Moo_ATI_Talk";

Key changes being not initially defining NS_MOO_ATI to be an undefined constant (That may or may not break anything, in the best case it did nothing), and remembering the NS prefix for the key of $wgExtraNamespace (The fact it starts with NS_ is unimportant, it just has to be the same as the define. Let me know if that fixes the issues you're having. (It possibly worked before because php might consider $wgExtraNamespace[ UNDEFINED_CONTENT ] = "foo"; to be $wgExtraNamespace[] = "foo", which adds something on to the end of an array, which may have just happened to all work out ok). Bawolff (talk) 14:38, 19 July 2012 (UTC)

---

Apparently, the aforementioned ns_moo reference did illustrate particular inconsistencies; after re-testing the suggested ns_moo_ati, the namespace conflict appears to be resolved.Habatchii (talk) 16:44, 19 July 2012 (UTC)

Use of undefined constant error

I've added a Portal namespace to my wiki, and since then I've been getting the same PHP error in my logs:

[11-Mar-2014 14:13:47 America/New_York] PHP Notice: Use of undefined constant NS_PORTAL - assumed 'NS_PORTAL' in D:\xxx\LocalSettings.php on line 185

Here's what's in my LocalSettings:
define( "NS_PORTAL", 100 );
define( "NS_PORTAL_TALK", 101 );
$wgExtraNamespaces[NS_PORTAL] = "Portal";
$wgExtraNamespaces[NS_PORTAL_TALK] = "Portal_talk";

I've also tried $wgExtraNamespaces['NS_PORTAL'] = "Portal";, but I'm still receiving the same error.

U must use $wgExtraNamespaces['NS_PORTAL'] = 'Portal'; Serdts (talk) 20:11, 7 December 2014 (UTC)