Page MenuHomePhabricator

MediaWiki silently ignores attempts to set namespaces less than 0 or greater than 255
Closed, ResolvedPublic

Description

Author: qleah

Description:
However, it continues to process such an update, changing the namespace number
to 0 or 255, possibly destroying or duplicating content, or making pages
inaccessible. Do the Special: or Media: namespaces work at all? As far as I
can tell, the former is quietly redirected to MediaWiki:, and the latter to Image:.

Using an unsigned eight-bit value for namespace numbers is a terrible limitation
(it isn't even documented anywhere). In places, the code currently assumes
negative values are legal (e.g., NS_MEDIA = -2 and NS_SPECIAL = -1). Such a
small range will inevitably lead to namespace conflicts. Why was cur_namespace
chosen to be a tinyint?


Version: unspecified
Severity: normal

Details

Reference
bz719

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 7:00 PM
bzimport set Reference to bz719.
bzimport added a subscriber: Unknown Object (MLST).

Special and media are, well, special namespaces: no pages are stored with them.

rowan.collins wrote:

And presumably the reason for only allowing such a small range is that it was
never anticipated that anyone would want more seperate namespaces than that: the
original version had, what, about half a dozen? I honestly can't think why
anyone *would* want >256 different namespaces (or perhaps think of that as 128 +
an associated _talk for each one, but even then); unless they were trying to
create a "FractalWiki"-type system, where different namespaces were treated as
though they were their own wiki, in which case I think a limit on the number of
namespaces would be the least of their problems.

qleah wrote:

(In reply to comment #2)

And presumably the reason for only allowing such a small range is that it was
never anticipated that anyone would want more seperate namespaces than that: the
original version had, what, about half a dozen? I honestly can't think why
anyone *would* want >256 different namespaces (or perhaps think of that as 128 +
an associated _talk for each one, but even then); unless they were trying to
create a "FractalWiki"-type system, where different namespaces were treated as
though they were their own wiki, in which case I think a limit on the number of
namespaces would be the least of their problems.

Yes, probably. The limit is fairly simple to adjust, even after the wiki has
been created, but it's aggravating. It still ought to handle values outside the
set range in a way that doesn't require repairing the database by hand.

It's really easy to encounter the limit if one isn't aware of it; the code
suggests that numbers down to -15 should be valid, and most people don't think
of 256 as a nice round number. I almost started adding custom namespaces at
1000 (thinking I'd seen that done somewhere else). Padding namespaces to avoid
collisions later gives maybe 20-40 names until the limit, starting from 100.

FractalWiki sounds fun. Are there wikis which support nested namespaces?

jeluf wrote:

So, what is the bug here?
What do you mean by "Set namespace less than 0"? How do you set it, SQL?

qleah wrote:

Custom namespaces are defined using the $wgExtraNamespaces array.
DefaultSettings.php provides an illustration:

  1. $wgExtraNamespaces =
  2. array(100 => "Hilfe",
  3. 101 => "Hilfe_Diskussion",
  4. 102 => "Aide",
  5. 103 => "Discussion_Aide");

I added a comment in defaultsettings (HEAD):

  1. Custom namespaces should start at 100 and stop at 255 (hard limit set by database)

avarab wrote:

Marking this as FIXED.

I have no idea why this was marked fixed, as it's not.

Bumping namespace fields from tinyint to int in 1.5. Checked into CVS HEAD.