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?


 * That's not a namespace; you just happened to put a colon in the page title. —Emufarmers(T 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 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. 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:

The second solution does the same thing with CSS basically:

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 232, 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:

Here's what's in my LocalSettings: I've also tried, but I'm still receiving the same error.