Is the conclusion here that it may be better just adding a protection instruction line for each non-talk namespace:
$wgNamespaceProtection[NS_MAIN] = array( 'sysop' ); $wgNamespaceProtection[NS_MEDIAWIKI] = array( 'sysop' ); $wgNamespaceProtection[NS_TEMPLATE] = array( 'sysop' ); $wgNamespaceProtection[NS_WIKI_TITLE] = array( 'sysop' );
etc.
plus:
$wgGroupPermissions['sysop']['sysop'] = true;
?
Derrick
On Wed, May 7, 2008 at 11:35 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
On 07/05/2008, Boris Steipe boris.steipe@utoronto.ca wrote:
Guys, while this looks elegant on the surface, this is almost a textbook example of inadvertent obfuscation. No-one who does not remember the connection between talk namespaces and their ID will be able to figure out _why_ this loop is being run. Moreover, the code will break in case this connection is at some point lost.
If this were in my lab, I would require the permissions to be explicitly set. This will go a long way to make the code maintainable. Even if the only maintainer is you, yourself, half a year from now. Sure, you type more; but code is very much more often read than written. And making implicit knowledge explicit, that's what software engineering is all about.
$0.02
Boris (At the very least add a comment and explanation!)
Yeah, a comment or two would be good. It's important to note that this is just a config setting and not part of the core code. The core code shouldn't generally be modified by end users, and if they do, they need to know what they're doing. Once you've configured your site, significant changes aren't particularly likely. A comment just in case would be good, but there's no need to worry overly much. Doing it this way would mean that adding new namespaces wouldn't require you to remember to add new protection, it just requires you to continue to use the same convention.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l