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@dominos.com wrote:

Hi You might try protecting your content page and not assigning cascading protection so users could edit talk pages Kate

...

...

...

"Derrick Farnell" derrick.farnell@gmail.com 5/7/2008 8:28 AM >>>

Hi

I want only admins to be able to edit content, but anyone to be able to post to talk pages - is there a way to control edit rights for talk pages differently from content pages?

Thanks in advance for any help

Derrick _______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

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@mail.nih.gov> wrote:

This is sort of kludgy but you could give your admins Sysop privilege, then have them protect each article via the protect tab after they initially create the article, which prevents all but Sysops from editing it. The talk page for that article should still be editable by regular (non-Sysop) users.

-Jim

-----Original Message----- From: Kathleen Cooch [mailto:Kathleen.Cooch@dominos.com] Sent: Wednesday, May 07, 2008 8:35 AM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] Is there a way to control edit rights for talkpages differently from content pages?

...

Hi

...

I want only admins to be able to edit content, but anyone to be able to

post to talk

...

pages - is there a way to control edit rights for talk pages

differently from content

...

pages?

...

Thanks in advance for any help

...

Derrick

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

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 thomas.dalton@gmail.com wrote:

2008/5/7 Derrick Farnell derrick.farnell@gmail.com:

...

Hi

I want only admins to be able to edit content, but anyone to be able to

post

...

to talk pages - is there a way to control edit rights for talk pages differently from content pages?

Thanks in advance for any help

Yes. See http://www.mediawiki.org/wiki/Manual:%24wgNamespaceProtection

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

2008/5/7 Derrick Farnell derrick.farnell@gmail.com:

Would I simply add to LocalSettings.php the line:

$wgNamespaceProtection[NS_MAIN] = array( 'sysop' );

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 thomas.dalton@gmail.com wrote:

2008/5/7 Daniel Barrett danb@vistaprint.com:

...

How about a foreach loop through the array of namespaces, then change the exceptions afterward?

No point - the exceptions list would be just as long as doing it the other way around. There's a talk namespace for every non-talk one.

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 derrick.farnell@gmail.com wrote:

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' );

etc.

plus:

$wgGroupPermissions['sysop']['sysop'] = true;

?

That will work fine.

Also, is there way to allow only users to be able to edit their own user page, admins or not (while letting anyone edit their talk page)?

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 danb@vistaprint.com wrote:

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' ); } }

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 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.

2008/5/8 Derrick Farnell derrick.farnell@gmail.com:

Is the conclusion here that it may be better just adding a protection instruction line for each non-talk namespace:

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.