MediaWiki Forums - Editing Restrictions 101 (Part III)

Previous: Editing Restrictions 101 (Part II)

Part III of this tutorial covers setting up your own namespace protections and group permissions to customize the editing access to your wiki.

MediaWiki, by design, is set up to allow pretty liberal access for reading and editing. Namespace protections were established to provide administrators with some ability to limit editing access to the wiki without installing any extensions.

Namespace protections do not grant additional rights to users; you use your Group Permissions to do that. Namespace protections are used to restrict a right that has been granted; most administrators use namespace protections to restrict editing of certain namespaces to specified groups. This tutorial will cover a few examples of some of the more commonly requested settings on the forums.

Provide edit access to anonymous users to discussion pages only

This can be accomplished by setting up a namespace protection that is granted to registered users.

If you remember from Part I, anonymous users by default can edit or create pages on the wiki without registering. By restricting edit access to article namespaces you can grant access to anonymous users to discussion pages only.

Step I: Set up a namespace protection for article pages

Add the following to LocalSettings.php:

Code:

$wgNamespaceProtection[NS_MAIN] =
$wgNamespaceProtection[NS_USER] =
$wgNamespaceProtection[NS_PROJECT] =
$wgNamespaceProtection[NS_FILE] =
$wgNamespaceProtection[NS_IMAGE] =
$wgNamespaceProtection[NS_TEMPLATE] =
$wgNamespaceProtection[NS_HELP] =
$wgNamespaceProtection[NS_CATEGORY] = array('editarticles');

What you are doing here is establishing a namespace protection for all of the article namespaces, otherwise called subject namespaces. Note that we are not applying this protection to the discussion pages.

Step II: Add the namespace protection to the Registered Users group

Add the following to LocalSettings.php:

Code:

$wgGroupPermissions['user']['editarticles'] = true;

What you have done here is assign the "editarticles' protection to the 'user' group. Since namespace protections are a further restriction, a group must have both 'edit' rights and any other restrictions assigned to a namespace to be able to edit that namespace.

You're done! Now anonymous users will only be able to edit the discussion pages on your wiki.

Provide read access to registered users only, and edit access to sysops
There is a way to blanket protect your wiki from reading by anonymous users (only anonymous users can be restricted without installing extensions to customize restrictions). You can do this by doing the following:

Step I: Remove edit and read access from anonymous users

Add the following to LocalSettings.php:

Code:

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;

You don't have to worry about the "createpage" and "createtalk" permissions since you must have "edit" permissions to be able to "create" pages.

Step II: Remove edit permissions from registered users

Add the following to LocalSettings.php:

Code:

$wgGroupPermissions['user']['edit'] = false;

This removes edit permissions from registered users.

Step III: Grant edit access to sysops

Add the following to LocalSettings.php:

Code:

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

Step IV: Set up your "whitelisted" pages

Whitelisted pages are a special group of pages that are designated as readable to anonymous users when you have otherwise restricted read access to your wiki by setting $wgGroupPermissions['*']['read'] = false;. You need to do this for the login page so that users can access it to log in. You can also designate other pages, such as the main page, as readable by anonymous users as well.

Whitelisted pages are designated using the configuration setting $wgWhitelistRead.

Add the following to LocalSettings.php:

Code:

$wgWhitelistRead = array("Special:Userlogin", "-", "MediaWiki:Monobook.css", "MediaWiki:Common.css", "Main Page");

This will allow anonymous users to access Special:Userlogin and the Main Page. It also allows any customized css settings stored in MediaWiki:Monobook.css or MediaWiki:Common.css to be applied for anonymous users as well. If you don't want anonymous users to read the Main Page of your wiki, you can restrict access to it by omitting "Main Page" from $wgWhitelistRead.

You're Done! Now only logged in users can read your wiki pages, and only sysops can edit.

Granting Registered users with Read Only access the ability to edit pages in the User namespace and discussion pages

This is designed to go with the previous topic

When you restrict read access to registered users as described above, you may want to grant them the ability to edit pages in the User namespace (allowing them to edit their user page) and the discussion pages. You can do this by setting up a namespace protection for all pages except the user namespace and the discussion pages, and then giving that protection to sysops only.

Step I: Set up a namespace protection for all Article namespaces except the User namespace

Add the following to LocalSettings.php:

Code:

$wgNamespaceProtection[NS_MAIN] =
$wgNamespaceProtection[NS_PROJECT] =
$wgNamespaceProtection[NS_FILE] =
$wgNamespaceProtection[NS_IMAGE] =
$wgNamespaceProtection[NS_TEMPLATE] =
$wgNamespaceProtection[NS_HELP] =
$wgNamespaceProtection[NS_CATEGORY] = array('editarticles');

Step II: Assign the namespace protection to the sysop group:

Add the following to LocalSettings.php:

Code:

$wgGroupPermissions['user']['edit'] = true; //Note this is different from the setting in the previous topic
$wgGroupPermissions['sysop']['editarticles'] = true;

You're done! if you followed the directions in the previous topic combined with this one, your wiki will now be set up to allow registered users only to read your wiki. Registered users will also be able to edit the discussion pages, and pages in the User namespace.

4 Comments

thnidu - April 12th, 2010 22:41

The only way I can print these articles is to open them in MSIE, select the text, and choose Print Selection. And, at that, it's no wider than the column on the screen, so I've got 2 pages of content spread out across 5 or 6 sheets of printout.

I normally use Firefox, but Print just gave me the framing material (header, footer, left and right columns) and the title info (down thru "Published on...", comment count, and HR): No content! When I selected the article and chose Print selection, I got the middle column all right, title and text... as much as would fit on one page and no more. The print footer said "1 of 1".

In MSIE, Print gives me the header and all three columns (slight overlap on the left, but not serious), but only the first page.

Anyone else report such a problem?

hoggwild - April 12th, 2010 23:19

Unfortunately, I cannot help you. I have spent hours trying to fix the layout on this site to no avail. Unfortunately I don't make any money whatsoever on this site and I don't have unlimited time and resources to spend trying to fix a broken piece of software.

The vBulletin 4.0 package is a worthless piece of crap. You can't configure it, you can't format it and the search engine has been completely screwed up by the vBulletin team.

They lost all of the old team members and the new ones cannot do anything right.

If anyone is looking to purchase a good commercial software package to run a public forum, don't walk, RUN away from vBulletin. They have ruined what used to be a good product.

Rather than waste any more time screwing with the layout on this worthless piece of crap, I am concentrating my efforts on finding a replacement.

thnidu - April 15th, 2010 00:06

Oh, dear. Thank you for the answer, and I'm sorry for the trouble you've been having. I know this sort of situation all too well... And thank you for this whole site!

EricPost - August 2nd, 2010 06:31

Thanks so much for this. This is exactly what I wanted. But there is one other thing I would like to know how to do if possible.

Is there a way to use your code above and then require if a user wants to register to edit that he/she confirm the email?

Right now all I see is confirm to edit, which of course defeats the purpose as it over-rules letting any edit a discuss page.

What I want to do is to keep the code used on this page but if a user wants to register he/she must confirm that email. That way it'll prevent anyone from using a random email to register.

Thanks

Editing Restrictions 101 (Part III)

Sections

Categories