Thanks - that would work, but I want this to apply to all content pages, not just certain ones, so I'd rather the protection didn't have to be done manually for each content page. I was hoping that there would be something I could add to LocalSettings.php which would mean that only admins can edit content pages, while anyone can edit talk pages - or perhaps there is an extension to achieve this. Derrick On Wed, May 7, 2008 at 1:34 PM, Kathleen Cooch <Kathleen.Cooch(a)dominos.com> wrote:

Thanks, but I'd rather that the site only allowed admins to edit content pages, rather than having to protect each content page manually. Also, I want anyone to be able to create a content page. Derrick On Wed, May 7, 2008 at 2:35 PM, Sullivan, James (NIH/CIT) [C] < sullivan(a)mail.nih.gov&gt; wrote:

Thanks! However, what exact form would the code take to enable to kind of access I'm wanting? I'm not very knowledgeable about all of this... I want only admins to be able to edit content pages, and anyone to be able to edit talk pages. Derrick On Wed, May 7, 2008 at 1:54 PM, Thomas Dalton &lt;thomas.dalton(a)gmail.com&gt; wrote:

2008/5/7 Derrick Farnell &lt;derrick.farnell(a)gmail.com&gt;om>: Yeah, pretty much. You may also need to add: $wgGroupPermissions['sysop']['sysop'] = true; I'm not sure if that's set by default, or not. (There is a difference between the sysop group and a sysop permission, so you need to explictly give the sysop group the sysop permission.)

How about a foreach loop through the array of namespaces, then change the exceptions afterward? -----Original Message----- Is there perhaps a way of setting this protection for all namespaces, except Talk (and MediaWiki Talk, etc.), with one line, for neatness?

On 07/05/2008, Thomas Dalton &lt;thomas.dalton(a)gmail.com&gt; wrote: As always, the idea comes to me just as I click send... I think non-talk namespaces generally have even IDs and talk namespaces odd ones. If that really is the case, then you can do a foreach loop and check if the id is even or odd (using "foo % 2 == 0" or whatever it is in php) and set the protection accordingly.

On 07/05/2008, Derrick Farnell &lt;derrick.farnell(a)gmail.com&gt; wrote: That will work fine. I don't believe there's any way to do that with the core code, but I think there are extensions to allow such things. Take a look at http://www.mediawiki.org/wiki/Extension_Matrix for a list of extensions, you can probably find one there (someone here may know of one that will do what you want and can save you the trouble - unfortunately, I can't).

Something like this loop should work, if you haven't defined any custom namespaces in your wiki: global $wgCanonicalNamespaceNames; foreach ($wgCanonicalNamespaceNames as $ns => $name) { // If namespace ID is non-negative and even, protect it. if ($ns >= 0 && $ns % 2 == 0) { $wgNamespaceProtection[$ns] = array( 'sysop' ); } } DanB -----Original Message----- Derrick Farnell writes: That went above my head! Perhaps if I just added a line for each non-talk namespace? That is: $wgNamespaceProtection[NS_MAIN] = array( 'sysop' ); $wgNamespaceProtection[NS_MEDIAWIKI] = array( 'sysop' ); $wgNamespaceProtection[NS_TEMPLATE] = array( 'sysop' ); $wgNamespaceProtection[NS_WIKI_TITLE] = array( 'sysop' );

On 07/05/2008, Daniel Barrett &lt;danb(a)vistaprint.com&gt; wrote: Don't you need namespace ids, rather than namespace names? I may just be mis-remembering what the various arrays are called...

On 07/05/2008, Boris Steipe &lt;boris.steipe(a)utoronto.ca&gt; wrote: 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.

2008/5/8 Derrick Farnell &lt;derrick.farnell(a)gmail.com&gt;om>: If you don't have lots of custom namespaces, and don't intend to add any, then yes. A loop would be about 3 lines, doing it explicitly is 4 - not much point doing something much more complicated to save one line.

In this small, toy example, you might be right; but on a large wiki, I believe the data-driven approach (iterating through the namespace list) is far better for maintenance. I run one wiki that has tremendous customization by namespace, and has quite a few custom namespaces too. If it used your explicit "line by line" approach (separate assignment statements for every setting), there would be hundreds of these nearly-identical lines. And every time someone added a new namespace, they'd have to remember to update the configuration by hand (copy and paste, copy and paste) with the potential for introducing careless errors. In my opinion, that kind of redundancy is a "textbook example" of a system heading toward unmaintainability. The data-driven approach just keeps working even when you add new namespaces. It represents a business rule in a compact form. You're right that the code would break if MediaWiki changed the meaning of namespace IDs. I'm less worried about that than introducing a bug by hand in several hundred lines of identical assignment statements. You are absolutely right that the admin would need to understand this kind of code to maintain the wiki. I don't see anything wrong with requiring this kind of domain knowledge from a wiki admin. And in real code (not my toy example, thrown together to answer a qusetion), it would be fully commented, and probably embedded in a class in an extension, also documented. DanB -----Original Message----- Boris Steipe writes: 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.