Manual talk:User rights

Latest comment: 1 year ago by C.Syde65 in topic No Edit right for SysOp?

Please do not post support questions here.

Instead, use one of these channels:

Further options for contacting appropriate people can be found at Communication .

Special:Userrights limited to only Stewards[edit]

Special:Userrights is limited to only Stewards, which includes only two users. Shouldn't that link be open to everybody?

Heck no. --Sayuri 16:45, 6 October 2007 (UTC)Reply
To Anonymous poster: That page serves only one purpose, to (un)assign user groups to users. If it's open to everybody, anybody could assign themselves sysop access. --Egingell 04:28, 18 October 2007 (UTC)Reply

User rights names[edit]

Am I limited only to the names "sysop", "bot" and "bureaucrat" or can i make a new one? --Gerard armando 02:09, 20 October 2007 (UTC)Reply

You can make a new one; Help:User rights#Managing groups gives an example of this by creating a "ninja" group. —Pathoschild 18:58:41, 20 October 2007 (UTC)

I made my own group, but when viewing it on a user's preference page it is not shown as a link, while groups like sysop or user are. Why is this?

Nevrmind -> Manual talk:$wgGroupPermissions#Link to groups.3F

Discussion Pages[edit]

I'm setting up a wiki so that registered user cannot edit pages, but would like them to be able to use the discussion page. Is that possible? 14:41, 24 October 2007 (UTC)Reply

Not currently, though it would be easy to add that feature if a developer chose to do so. —Pathoschild 06:07:29, 25 October 2007 (UTC)

Actually, I think this is possible via the $wgNamespaceProtection setting. Just add the following settings to your LocalSettings.php file:

$wgGroupPermissions['approved']['editmain'] = true;
$wgNamespaceProtection[NS_MAIN] = array( 'editmain' );

This will only give those users who are part of the "approved" group the ability to edit the "main" namespace (but they can still edit the "talk" namespace). If you want to restrict other namespaces to editing by a single usergroup, you can add them as follows:

$wgNamespaceProtection[NS_USER] = array( 'editmain' );
$wgNamespaceProtection[NS_IMAGE] = array( 'editmain' );
// Etc...

I would like to do something similar, but I would like it so anyone can write in discussions but only registered users can edit and add articles. I tried to configure it but it says that you need both edit and createtalk turned to true for this to happen. Does anyone know the code to make this possible?- Thanks! Steve

-- 15:13, 20 November 2007 (UTC)Reply

If you add the following to the LocalSettings.php file:
$wgGroupPermissions['*']['edit-main'] = false;
$wgGroupPermissions['*']['edit-talk'] = true;
$wgGroupPermissions['user']['edit-main'] = true;
$wgGroupPermissions['user']['edit-talk'] = true;
$wgNamespaceProtection[NS_MAIN] = array( 'editmain' );
$wgNamespaceProtection[NS_USER] = array( 'editmain' );
$wgNamespaceProtection[NS_MEDIAWIKI] = array( 'editmain' );
$wgNamespaceProtection[NS_<WIKI-NAME>] = array( 'editmain' );
$wgNamespaceProtection[NS_HELP] = array( 'editmain' );
// plus any other namespaces you may have

you can restrict unregistered Users to editing discussion pages only and prevent them from editing articles.

Paul2387 13:41, 10 May 2010 (UTC)Reply

User Editing Rights for just one page[edit]

I'm setting up a wiki where registered users can only edit their own page. How do you do that?

You can't do that by default, though it would probably be possible to use or write an extension. —Pathoschild 04:33:21, 30 October 2007 (UTC)


I created a new user group in my wiki, let's call it "mods"·... but i want sysops to be able to manage them... i mean.. bureaucrats can edit bureaucrats, sysops and mods rights... sysops can edit sysops and mods rights, mods can only edit mods rights...

Example, protecting a page... I don't know if you get it.. how do i do it? --Gerard Armando 23:39, 8 November 2007 (UTC)Reply

Adding Users to a Group[edit]

There is a lot of talk about editing different user groups and such, but how does one add users to a specific group?

i.e. If I wanted to add a user to group 'ninja' ? Tablanch 22:29, 18 December 2007 (UTC)Reply

The first sentence states: "...which can then be assigned to (or removed from) users through the Special:Userrights interface." —Pathoschild 02:53:01, 19 December 2007 (UTC)
I see. Feel free to slap me. Tablanch 13:24, 19 December 2007 (UTC)Reply

Propose move to manual[edit]

The help pages should document features for normal users, and sysops, but should not detail configuration variables. Information for server administrators belongs in the technical manual. That wasn't made clear before, but recently I've added some details to clarify the aim of the Help pages. See Project:PD help#Target readership - Normal users.

I know you're busy editing/maintaining this page Pathoschild. How would you feel about moving most of this. Perhaps put it on a new page "Manual:User rights"? There's also meta:Setting user rights in MediaWiki which maybe should be merged into a manual page here.

Harry Wood 15:52, 19 December 2007 (UTC)Reply

I have no objections. Maybe we can merge the Meta page to a linked subpage like "Manual:User Rights/Deprecated", for MediaWiki prior to 1.5? I think adding it directly to the same page would add quite a bit of content without being relevant to most users. —Pathoschild 18:53:49, 21 January 2008 (UTC)
Actually speaking of deprecated old info Help:User rights management seems to talk a lot about old MediaWiki versions. That page also needs to move/merge out of the Help namespace for the same reasons.
Anyway, so if that's OK, I'm going to go ahead with a move soon. Help:User rights -> Manual:User Rights
-- Harry Wood 19:53, 21 January 2008 (UTC)Reply
Oh. I was going to go ahead with the move (and all the corrections it will require... but actually Manual:User rights page name is 'occupied'. I thought I'd checked that, but no, there's redirect there at the moment, which a sysop user will have to delete before I can carry out the move. -- Harry Wood 14:54, 18 February 2008 (UTC)Reply
Deleted. --HappyDog 16:32, 18 February 2008 (UTC)Reply
Thanks. OK here goes! -- Harry Wood 17:01, 18 February 2008 (UTC)Reply

Clickable User-Right in Special:Listusers[edit]


when i add the Ninja-Group (as an example from the Helppage), how can i manage the group is clickable on the page Special:Listusers like Project:Bureaucrats or Project:Administrators (Sysops)?
Thanks in advance
kind regards
TurboKanne, February, 9th, 2008.

See Manual talk:$wgGroupPermissions#Link to groups?. --Sayuri 22:43, 9 February 2008 (UTC)Reply
Thanks for this hint, but unfortunately this does not resolve my issue. The group "ninja" (for example) is still not clickable in Special:Listusers, only Bureauctrats and Administrators (behind the names) are clickable. Do you have any additional hint?
TurboKanne, February, 11th, 2008
After a couple of tests i found it only works within my wiki when i change the pages MediaWiki:Grouppage-Ninja and MediaWiki:Grouppage-ninja. Don't know why, but now it works.
TurboKanne, February, 15th, 2008

View source and history rights[edit]

It would be useful to have separate permissions for viewing page source and history pages. This would make it possible to prevent unregistered users from seeing anything but the current HTML version of the page, which would also have the benefit of preventing search engines and spam bots from accessing content (e.g. contact details) that have been hidden or deleted.

-- Keith Wilson 16:00, 19 March 2008 (UTC)Reply

This is not the place for feature requests. Try filing a bug (severity: enhancement) on Bugzilla. —Simetrical (talk • contribs) 22:54, 19 March 2008 (UTC)Reply

It would be enough to set a hook like

$wgHooks['PageHistoryBeforeList'][] = 'checkHistoryAllowed';

and check the user's rights in a personal function checkHistoryAllowed() - but even if the hook returns false or an error message, the history is still shown, because in PageHistory.php / HistoryPage.php the return value of wfRunHooks() is not checked. Why is that? --DocSnyder 19:24, 12 October 2010 (UTC)Reply

Only Confirmed mail can edit articles[edit]

Hi, i'm creating a new wiki right now. I want everybody be able to create and edit talk pages. But only users with an confirmed mail adress should be able to edit articles. (of course sysop and stuff should also be able to do that stuf....) I think if i set 'edit' to false for everybody else they can't edit talk pages, or at least i can't find a setting like 'edit_talk' or somethin. Somebody can point me to the right direction for this? -- 01:42, 21 April 2008 (UTC)Reply

New user rights: what version are they for?[edit]

The following was added to the bottom of the page on June 8, 2008 [1]:

#$wgGroupPermissions['suppress']['hideuser'] = true;
// To hide revisions/log items from users and Sysops
#$wgGroupPermissions['suppress']['suppressrevision'] = true;
// For private suppression log access
#$wgGroupPermissions['suppress']['suppressionlog'] = true;

Shouldn't these user rights be added to the list, and what version of mediawiki are these user rights available for? thanks Odessaukrain 03:24, 13 July 2008 (UTC)Reply

Permissions to be documented?[edit]

I see the following permissions on various sites. The meaning of some is obvious, but they are not documented here. Are they custom permissions?

  • boardvote
  • browsearchive
  • centralauth-admin
  • centralauth-merge
  • checkuser
  • hiderevision
  • makebot
  • makesysop
  • noratelimit
  • nuke
  • override-antispoof
  • oversight
  • renameuser
  • reupload-own
  • skipcaptcha
  • tboverride
  • torunblocked
  • uboverride

Renate 14:42, 14 July 2008 (UTC)Reply

The linked ones are extension-defined and the links go to their extension pages :). I'll get around to documenting all the ones that need it later today. --Skizzerz 14:58, 14 July 2008 (UTC)Reply

Creating a group[edit]

I think it'd be important to note how to create a custom group. Simply creating an entry in the array may not be straightforward to all people. And I would've never thought of initializing it using the assignment operator:

$wgGroupPermissions['mygroup'] = $wgGroupPermissions['user'];

This was necessary to deny all users from the wiki and allow specific groups. I'm just not quite sure where to fit it in the current manual page.

--Dandin1 19:32, 7 June 2009 (UTC)Reply

You took the words right out of my mouth! I just posted the following on Wikimedia's Help_talk:User_rights page before I saw that the help page had been moved here:
I've been a wiki user for years, and a few years ago I set up and administered wikis for my department. Now I've been put in charge of running a new, public wiki. The Systems people have installed it --
  • MediaWiki 1.12.0
  • PHP 5.2.6-1+lenny3 (apache2handler)
  • MySQL 5.0.51a-24+lenny1
-- and made me a bureaucrat and a sysop, and now I'm trying to come up to speed. I'm working with the MediaWiki Handbook and LocalSettings.php, but there's a lot that I can't find.

Right now my question is: How do I create more groups? This wiki is meant to be world-readable, but people will have to request authorization to write to it, and there are to be separate sections with separate write authorization. I thought I'd be able to do that with groups and namespaces -- group A can write to namespace A, group B to namespace B, ... -- but all I can find is
You can add users to these groups: bot, sysop and bureaucrat.
You can remove users from these groups: bot, sysop and bureaucrat.
I can't find word one about creating new groups, even though I see numerous groups on this wiki here.

Is it doable? Is there a hole in the documentation? Do I need to ask our Systems folks to do something?
Dandin1, it looks from your answer as if this is a Systems job. But I'd like to hear it for sure.
Thnidu 23:29, 24 June 2009 (UTC)Reply

Editable talk/discussion pages[edit]

Is it possible to enable user edits only on discussion and talk pages, but not on actual articles? Or would this require a custom extension?

I managed to do it by patching like this :
includes/Title.php : add the following line at the very beginning of public function userCan and private function getUserPermissionsErrorsInternal :
if (($action == 'edit') && ($this->isTalkPage())) $action = 'edittalk';
includes/EditPage.php :
replace the following line :
if ( !$wgUser->isAllowed('edit') ) {
by the following :
if ( (( !$this->mTitle->isTalkPage()) && ( !$wgUser->isAllowed('edit'))) ||  (( $this->mTitle->isTalkPage()) && ( !$wgUser->isAllowed('edittalk'))) ) {
now you have a new right to use in LocalSettings.php : edittalk. Here is an example :
$wgGroupPermissions['*' ]['edittalk'] = true;
$wgGroupPermissions['*' ]['createtalk'] = true;

  • This seemed to only create a 500 error. Is this dependent on a specific mediawiki version?
  • This solution, does not seem to work. Anon user is able to edit and create all pages, not only talkpages.

move-rootuserpages... what is a root user page?[edit]

Hey all, I am a little weak on the concept of what is a 'root page'. I did a search and did not find this well explained anywhere. As a result I am unsure whether I want all users to be able to 'move-rootuserpages' or not.

Maybe a glossary section should be added to the Manual?

Same comment here, I didn't got an answer to my question what a 'root user page' is and where (and why) a general user should 'move' it. Wasn't able to find an answer elsewhere. The definition of root which is applicable here is "the first or top-most directory in a hierarchy", isn't it? Root_(disambiguation) ( So why should a user be allowed move the top-most directory of his user page? I think giving an answer in this article to this with a glossary would be very helpful --LenaKö (talk) 14:27, 4 July 2017 (UTC)Reply


My wiki is closed to anonimous. I use external script which needs action=raw. But if I use $wgGroupPermissions['*']['read'] = false; I have no access to action=raw. How can I make such preferencies to create free rights for action=raw??? --Андрей Краснобаев 16:57, 17 December 2009 (UTC)Reply

The script must be autheticated. Max Semenik 16:59, 17 December 2009 (UTC)Reply
The idea is clear for me, but I'm not very skilled in php(( --Андрей Краснобаев 10:24, 19 December 2009 (UTC)Reply
Then use pre-existing code. Max Semenik 10:27, 19 December 2009 (UTC)Reply
Thank you for your answer! I send you the letter.--Андрей Краснобаев 11:02, 19 December 2009 (UTC)Reply


There seems to be a 'sendemail' right that doesn't seem documented. I would have added it to the table if I had figured out where it should have been inserted (it's obviously not editing, nor is it management). Coren 03:59, 17 July 2010 (UTC)Reply

Where are you seeing this right, and what version of MediaWiki are you using? Also, are you sure that it isn't added by an extension? --Skizzerz 19:28, 17 July 2010 (UTC)Reply
I apparently fail at searching through files. Anyway, I'd think that the 'sendemail' right would likely go under the Technical category since it kinda fits in with some of the other things. --Skizzerz 19:31, 17 July 2010 (UTC)Reply

User Group rights[edit]

I have disabled all the rights for non registered users and set the white list only to the special:userlogin page. But they can still see all the pages. It doesn't seem to work.

delete pages / reupload files only without category entry[edit]

I have a problem to delete pages or reupload file if the page or file are in a category. If I delete the category entry first it is posible to delete or reupload. I have this problem as user and admn. What is wrong with my user rights? --Dirk M 20:01, 15 August 2010 (UTC)Reply

Examples : emailconfirmed[edit]

What's the difference between the following example provided on this page and the result of Manual:$wgEmailConfirmToEdit = true;?

This example will disable editing of all pages, then re-enable for users with confirmed e-mail addresses only:

# Disable for everyone.
$wgGroupPermissions['*']['edit']              = false;
# Disable for users, too: by default 'user' is allowed to edit, even if '*' is not.
$wgGroupPermissions['user']['edit']           = false;
# Make it so users with confirmed e-mail addresses are in the group.
$wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED;
# Hide group from user list. 
$wgImplicitGroups[] = 'emailconfirmed';
# Finally, set it to true for the desired group.
$wgGroupPermissions['emailconfirmed']['edit'] = true;

-- Matsch 12:50, 23 February 2011 (UTC)Reply

Three-tier bureaucrat system[edit]

I want to create three tiers of bureaucrats:

  • Benefactor — can add or remove captain, lieutenant or sysop user rights
  • Captain — can add or remove lieutenant or sysop user rights
  • Lieutenant — can add or remove sysop user rights

How does one do this? I tried and failed. Leucosticte (talk) 08:10, 9 September 2012 (UTC)Reply

I'm not sure that the = operator can be used sequentially like that. Try declaring $wgAddGroups and $wgRemoveGroups for each group separately.--Jasper Deng (talk) 04:20, 10 September 2012 (UTC)Reply
Thanks; there were some other issues involved too, so I documented how to do it at Manual:Establishing a hierarchy of bureaucrats. Leucosticte (talk) 22:01, 11 September 2012 (UTC)Reply

move-target not documented!!!![edit]

There's no documentation about the right move-target. But if you don't set, move doesn't work.

Fernando Carpani (talk) 20:12, 27 May 2013 (UTC)Reply
Does this have to do with moving pages in general or just moving files? Technical 13 (talk) 22:02, 28 May 2013 (UTC)Reply

If logged in with Facebook - no need to confirm email address[edit]

If a user logs in with facebook on my site I don't want them to have to confirm their email before they edit a page. I have $wgGroupPermissions['emailconfirmed']['edit'] = true; set on my site for other regular accounts. How do I set it that users who login with facebook have their email confirmed automatically? Thanks --Tech (talk) 09:05, 9 June 2013 (UTC)Reply

You'll have to have that added as a feature to whatever extension is implementing Facebook logins on your wiki. Daniel Friesen (Dantman) (talk) 09:32, 9 June 2013 (UTC)Reply

Inherited permissions[edit]


How do I make it so that permissions are inherited? For example, I want the user group bureaucrats to have all the rights assigned to administrators, without having to type them in again and make the localsettings file longer and harder to get my way around.

I could just add people to both groups, but I want them to be in only one group at a time.--Lyrixn (talk) 16:56, 5 August 2013 (UTC)Reply

  • You have two reasonable options I can think of:
    1. Type them in again to each group. (This is the best option IMHO and a few extra bytes isn't going to hurt anything)
    2. Put the user in both groups
  • There are no other ways documented or that I am aware of to do this. Your final option might be to request that a method be added in a future version of the software on Bugzilla, and if it doesn't get closed as INVALID then eventually it could be added (but might be a long wait). Good luck! Technical 13 (talk) 17:07, 5 August 2013 (UTC)Reply

Create new user right for edits and pages created with external links?[edit]

I think this would be an amazing help in spam prevention.

What I wanted is a way to give visitors, and non auto confirmed users to edit the wiki but not being able to post edits with external links or create pages with links unless they are autoconfirmed.

It would work something like this if you get what I mean, editlinks and createpagelinks would be new variables for edits and pages with external links.

$wgGroupPermissions['*']['edit'] = true;
$wgGroupPermissions['*']['editlinks'] = false;
$wgGroupPermissions['*']['createpage'] = true;
$wgGroupPermissions['*']['createpagelinks'] = false;

$wgGroupPermissions['autoconfirmed']['edit'] = true;
$wgGroupPermissions['autoconfirmed']['editlinks'] = true;
$wgGroupPermissions['autoconfirmed']['createpage'] = true;
$wgGroupPermissions['autoconfirmed']['createpagelinks'] = true;

Permissions Frontend[edit]

I haven't yet gotten the wiki software installed, but I have to say that I am amazed that, based on this, there is apparently no admin frontend, at least not for permissions. Most forums have an admin permissions menu, so why not one of the most popular pieces of wiki software on the web? Hadashi (talk) 20:11, 19 January 2014 (UTC)Reply

Special:UserRights is used for managing existing user rights. But to edit local rights I'm afraid that yes, configuration file access is needed. Rather ironically, Extension:CentralAuth does have what you are looking for, but for global groups only.--Jasper Deng (talk) 20:23, 19 January 2014 (UTC)Reply


Hi, the vipsscaler-test right is missing. Can anyone add it with the explanation of what it is used for? It would be helpful so that I can update our German help page de:Hilfe:Gruppenrechte. Thanks! XenonX3 (talk) 14:51, 2 April 2014 (UTC)Reply

This is a right, which is added by an extension (by the Extension:VipsScaler). There are plenty of extensions, which bring their own rights and none of them have been added to this page, also as this would result in a never-ending, always out of date list. Instead of listing all custom, third-party rights, I think it's better to only list those rights, which come with the MediaWiki Core and only to show, how custom rights can in theory read as: in the source code) be given. -- 14:37, 23 November 2014 (UTC)Reply

Translation of user rights description[edit]

I'd like to mark this page for translation, but it makes little sense to translate all the user rights descriptions all over again. Can we find a way to just transclude the translations with int? But then how to avoid their disappearance when a right is removed from MediaWiki, should we just paste the text here when they're removed and avoid bothering? --Nemo 22:18, 8 August 2014 (UTC)Reply

Right precedence[edit]

The article specifies the following regarding the precedence of a right for a user with multiple groups: "If a member has multiple groups, they get the highest permission of any groups." By highest permission, does this mean that a 1/true for the right in any group trumps any 0/false for the right in any other groups? If so, this could definitely be worded better. --Tjbp (talk) 17:24, 22 August 2014 (UTC)Reply

Fixed. Jackmcbarn (talk) 21:37, 23 August 2014 (UTC)Reply

Project:OAuth administrators[edit]

The non-empty Project:OAuth administrators group is still a red link on Special:ListGroupRights. Ditto the empty Project:Account creators group. Help:User rights and Help:OAuth do not explain the mwoauthmanageconsumer right. For comparison see m:Meta:OAuth_administrators.

Guessing, these folks decide what happens with a Special:OAuthConsumerRegistration for a listing on Special:OAuthListConsumers, and then users can connect applications, and manage their stuff on Special:OAuthManageMyGrants. This theory has a fatal flaw, I had phabricator-production [1.0] on my list, but it's not a registered application.

Be..anyone (talk) 09:13, 26 October 2014 (UTC)Reply

Meanwhile Project:OAuth administrators exists (again) here, it's now a soft redirect to the corresponding Meta user group rights page. And the theory was fine, but stupid user missed that the 20 registered "connected apps" on the first page are not all registered connected apps. –Be..anyone (talk) 09:12, 3 January 2015 (UTC)Reply


Hi, I want that the bureaucrat's group will inclunde the all sysops' permissions. How can I do that> thanks for helpers Dekel E (talk) 16:00, 31 December 2014 (UTC)Reply

$wgGroupPermissions['bureaucrat'] = array_merge($wgGroupPermissions['sysop'], $wgGroupPermissions['bureaucrat']);
. In the future, though, please direct help inquiries to Project:Support desk. Thank you.--Jasper Deng (talk) 09:26, 1 January 2015 (UTC)Reply

Default Value for Rights[edit]

Is the default value for rights not defined/assigned to a group in either DefaultSettings.php or LocalSettings.php set to false? It seems to be implied, but I couldn't find confirmation of that on the Manual:User_rights page. — Preceding unsigned comment added by (talkcontribs)

Are you talking about Manual:User_rights#Default_rights, and did you miss that, or is something wrong with it? –Be..anyone (talk) 07:06, 15 March 2015 (UTC)Reply
Yes, I'm talking about Manual:User_rights. For example, if suppressredirect was not defined in DefaultSettings.php, would the value be false? This isn't actually explicitly stated on the page. — Preceding unsigned comment added by (talkcontribs)
Sorry, I don't know, but the folks on the support desk can help, unlike me they have actually installed MediaWiki.Be..anyone (talk) 17:59, 16 March 2015 (UTC)Reply
By default, if a right does not exist, then the acccording array kay is not set and this key won't have a value. So if in PHP you check for that array key, the result will be that it is not there or if you check its value, then it will not be false, but PHP will evaluate it to false.
Sidenote: Possible values for user rights only are true and false. In the case of a non-existing right/array key, its value will definitely not be true. Checking, if it is false however will not only cover cases, where the right has been set to false, but also cases, where the right does not exist at all - and getting the same result both times might not be what you want. So better check, if the right is granted/if the value is true: If you want to know, if a right is set, it will be save to explicitly see, if it is true. -- 17:59, 3 February 2016 (UTC)Reply

New right to allow read/write in custom namespace[edit]

I am developing my own wiki and I would like administrators to be able to view and edit in the Admin and Admin talk namespaces. I know it's possible somehow, but probably very difficult. Any help? Some unimportant person (talk) 12:32, 17 May 2015 (UTC)Reply

In Mediawiki edit rights (for a group) can be handled very well for each NS but you can not grant read rights on a specific NS. If you have a private Wiki then all users (logged in) can read every page on the Wiki, except some special pages. What you want is a Access Control List.
Some stuff to read:
If you really want to be able to specify read rights on NS or pages you are probably better of with Wiki software that has a Access Control List by default, like TikiWiki. --Felipe (talk) 05:33, 18 May 2015 (UTC)Reply

Possible Error In Ninja vs Writer Examples[edit]

I'm probably missing some finer points, but I guess it is the job of us newbies to suggest clearer documentation.

I wish there was more description for the purpose of the MidiaWiki:Group-<group-name> Pages. Where and when are their contents used? The examples given are slightly confusing because the Ninja example has a <group-name>='ninja' and Group page contents of:

  • Ninjas
  • ninja
  • Project:Ninjas

while the Write example lists <group-name>='Write', and has Group page content of:

  • Writers
  • Writer
  • Project:Write

There seems to be a contradiction here. If one example was plural then why not the other? Should the writer example actually be

  • MediaWiki:Group-Write (content: Writers)
  • MediaWiki:Group-Write-member (content: Write)
  • MediaWiki:Grouppage-Write (content: Project:Writers)

WmBliss (talk) 23:17, 30 August 2015 (UTC)Reply

Proxy edit request for an anon[edit]

Hi there. I would like to request an edit to this page, as semi-protection is applied and I don't have an account on here.

Within the wikitable in the "List of permissions" section is an entry for the unblockself permission. The current description says...

"Unblock oneself Without it an administrator that has the capability to block cannot unblock themselves if blocked by another administrator"

...which is missing some punctuation. It should be:

"Unblock oneself. Without it, an administrator that has the capability to block cannot unblock themselves if blocked by another administrator"

Minor edit. Easy to fix! 06:18, 6 June 2016 (UTC)Reply

I'm not sure how to get to the "Unblock oneself." part, but the following sentence I attempted to update that. Tropicalkitty (talk) 15:15, 6 June 2016 (UTC)Reply
Saw your edits - didn't realize there was a lot of advanced syntax within the table, heh. Much appreciated though! 19:23, 6 June 2016 (UTC)Reply

Giving a User rights without Group Permissions[edit]

It is possible to explicitly specify a username rights e.g. reading-rights for User "Patrick"?

Ambiguous numbers[edit]

The Description of the delete right reads:

Delete pages 1.5–1.11: allows the deletion or undeletion of pages. 1.12+: allows the deletion of pages. For undeletions, there is now the 'undelete' right, see below

This would be clearer if the numbers were identified as versions, and the text had better punctuation, e.g. thus:

Delete pages. In versions 1.5–1.11: allows the deletion or undeletion of pages. In versions 1.12+: allows the deletion of pages; for undeletions, there is now a separate undelete right, see below.

Yahya Abdal-Aziz (talk) 15:02, 30 January 2018 (UTC)Reply

Error in page: Mediawiki prefix[edit]

I'm fairly sure that every time it suggests creating a page with a Mediawiki: prefix, it really means <YourWiki>:. Example: MediaWiki:Group-<group-name> Calion (talk) 00:45, 17 February 2018 (UTC)Reply

I assume by <YourWiki>: you mean the Project: namespace (if not, please correct me). In that case, the text means exactly what it says: to create the pages in the MediaWiki: namespace. I'm guessing your confusion arises from the fact that this is the MediaWiki wiki, so you would expect the Project namespace here to use "MediaWiki" as an alias, but in actuality it has no alias, and instead just uses "Project" (as you can see from the output of {{ns:4}}: Project). 05:32, 17 February 2018 (UTC)
Yes, thanks. I see that that's right. Calion (talk) 19:09, 17 February 2018 (UTC)Reply

not allowing to view the Common.css[edit]

I want to disable viewing of Common.css for visitors and registered users so that only the sysops can see and edit the .css Page. Can someone help me?

It's not possible with the standard MediaWiki software (see Manual:Preventing access#Restrict viewing of certain specific pages). It may be possible with an extension, but as documented on that page, any extension offering that ability isn't necessarily reliable. In any event, if someone really wants to see Common.css, all they have to do is use the developer tools in the browser, so hiding it would only prevent seeing it for people who don't know how to use those tools. Robin Hood  (talk) 18:55, 20 February 2018 (UTC)Reply

Preventing visitors from certain pages[edit]


I am looking at making it so only users who are logged in can view a Draft: namespace. People who are not logged in won't be able to view the contents of this namespace.

Is this possible? If so, how would I be able to implement it?

Any help is appreciated.


--Squeak24 (talk) 15:51, 22 October 2018 (UTC)Reply

You'll need to use Extension:Lockdown --Ciencia Al Poder (talk) 09:33, 23 October 2018 (UTC)Reply

Give sysops all rights except bot rights[edit]

# Give sysops all rights except bot rights
foreach ( $wgGroupPermissions as $group => $groupPermission ) {
	if ( $group != 'bot' ) {
		foreach ( $groupPermission as $specificPermission => $value ) {
			if ( !isset( $wgGroupPermissions['sysop'][$specificPermission] ) ) {
				$wgGroupPermissions['sysop'][$specificPermission] = true;

Setian~mw (talk) 23:15, 22 February 2019 (UTC)Reply

MediaWiki pages to create with new group[edit]

The page says one should generate pages [[MediaWiki:Group-<group-name>]], [[MediaWiki:Group-<group-name>-member]], [[MediaWiki:Grouppage-<group-name>]] "with fitting content". What are those pages and what would be fitting content? I tried to find an example on this wiki, e.g. [MediaWiki:Group-Account creators]], and it is a red link. Tenbergen (talk) 20:44, 30 January 2022 (UTC)Reply

That's because the actual pages are MediaWiki:Group-accountcreator and MediaWiki:Group-accountcreator-member. They need to contain the displayed name for the group (in this case, "Account creators") and a group member (in this case "account creator"). KockaAdmiralac (talk) 20:47, 30 January 2022 (UTC)Reply

No Edit right for SysOp?[edit]

More than half the rights granted-by-default to sysop say "- requires the edit right", but the default rights listed for sysop don't include the edit right.

As my site's sysop, I definitely have the ability to edit all the things (as far as I can tell). I'm just wondering if sysop is missing from the User groups that have this right by default column & edit is missing from the Default rights column...

...Or does sysop actually lack the edit right? (Perhaps because all sysops are also users and users already have the edit right?) In which case, if I revoke the edit right for users, do I need to then explicitly grant it for sysops to remain fully functional?

Thanks for your time and I pre-emptively request forgiveness for my dumba$$ery. Medicinestorm (talk) 20:04, 7 April 2023 (UTC)Reply

Administrators (sysop) don't need to have the (edit) right if All Users (*) and Registered Users (user) already have it. Since all usergroups automatically have every permission that All Users and Registered Users have. However I do feel that it wouldn't be too far fetched if Administrators were granted the (edit) right by default in a later version of MediaWiki. Just in case there are any bugs preventing users from automatically receiving permissions from any implicit usergroups they are part of. But yes, if you were to revoke the (edit) right from All Users and Registered Users, then Administrators would no longer be able to use the (edit) right. ― C.Syde (talk | contribs) 01:03, 8 April 2023 (UTC)Reply
That makes sense. Thank you very much. Medicinestorm (talk) 20:38, 9 April 2023 (UTC)Reply
No problem! :) ― C.Syde (talk | contribs) 23:45, 9 April 2023 (UTC)Reply