Hey, There is a bug (or a feature, depends on how you see it) in mediawiki extension namespace registration [1]. If an extension registers a namespace, there is no way to override that. It can be problematic in cases when there is a conflict of IDs between two installed extensions or one extension and custom-defined namespaces. We want to change that but there are several approaches and each of them has benefits and issues:
One (suggested by me) is to make IDs of namespaces registered by extension configurable using LocalSettings.php. This allows us to easily "move" a namespace without needing to touch other configurations related to that namespace but it also adds a global variable and also can't handle conflict in names of namespaces.
Another approach (suggested by legoktm) is to skip registering a namespace from extensions when the namespace constant is already defined. This doesn't have problems that the first approach has but you need to duplicate the configuration when there is a conflict.
Please contribute at the discussion and add your comments/concerns. Also feel free to suggest a new approach.
[1]: https://phabricator.wikimedia.org/T160462
Best
Since I reported the issue, I'd like to provide some context and feedback
Am 21.03.2017 um 19:18 schrieb Amir Tafreshi:
Hey, There is a bug (or a feature, depends on how you see it) in mediawiki extension namespace registration [1]. If an extension registers a namespace, there is no way to override that. It can be problematic in cases when there is a conflict of IDs between two installed extensions or one extension and custom-defined namespaces. We want to change that but there are several approaches and each of them has benefits and issues:
For example, UploadWizard defines the Campaign namespaces to have ID 460 in its extension.json. If on your wiki NS 460 is already used for some reason, you cannot use UploadWizard. That's bad.
Even worse - if you tried, you would nto get an error. The namespace declaration would be overwritten, potentially causing existign content to become inaccessible or even corrupted, if content models for the namespace mismatch.
One (suggested by me) is to make IDs of namespaces registered by extension configurable using LocalSettings.php. This allows us to easily "move" a namespace without needing to touch other configurations related to that namespace but it also adds a global variable and also can't handle conflict in names of namespaces.
Amir provided a patch for this approach: https://gerrit.wikimedia.org/r/#/c/342879/
This introduces a new globalconfig variable, $wgExtensionNamespaces that allows namespaces to be overwritten. While this would work, it has the disadvantage of requiring existing LocalSettings.php files to be modified; and of course it's Yet Another Config Variable.
I wonder whether it would not be sufficient to allow namespaces to be defiend in the existing $wgNamespaces array before loading the extension; the extension would simply not register a namespace ID if that array already has an entry for the respective namespace name.
The namespace constant would need to be defined based on the contents of $wgNamespaces, to avoid inconsistencies.
Another approach (suggested by legoktm) is to skip registering a namespace from extensions when the namespace constant is already defined. This doesn't have problems that the first approach has but you need to duplicate the configuration when there is a conflict.
That's similar to the approach using $wgNamespace, but perhaps even simpler. I guess both could be allowed.
In any case, I'm fine with any of these approaches, as long as a) conflicts a<re detected and reported and b) I have a sane way to resolve them in LocalSettings.php.
wikitech-l@lists.wikimedia.org