Help:Administrator guide

There are two types of formal administrator status: administrator and bureaucrat. For this document both are referred to as administrator.

This status should not be used to represent extra weight within community decisions, managing or ruling the wiki, nor is it a requirement for moderating or enforcing policy. Like all users, administrators should respect policy and consensus.

Blocks are applied via the form at the special page Special:Block. There are several steps to applying a block:

1. Specify the IP address or user to be blocked. Note that nonexistent usernames can also be blocked, so be certain you have the correct username. You can also block a range of IP addresses; see range blocks (below) for more information.
   • Usually, you'll be blocking people from the "Block this user" link in the sidebar or the "Block" link next to the username/IP address in the Special:RecentChanges listing.
2. Specify a duration for the block. You can select a predefined duration from the drop-down box labelled "Expiry", or you can enter a custom value, using the GNU standard format, in the "Other time" field. If the duration given is "indefinite", then the block will not expire, although the IP address or user account may still be unblocked by an administrator.
   • While the form accepts quite a large variety of date entry types (Fortnights, "Next Thursday"), you should generally confine yourself to the standard "years, months, weeks, days, hours, and minutes".
   • You can use decimals. Hence, "8.725 fortnights" is a valid (if strange and somewhat annoying) block duration.
   • Because IP addresses might be shared, it is highly recommended that they are not blocked for more than 6 months. It is strongly advised that they should not be blocked indefinitely.
3. Specify a reason for the block. This reason will be displayed to the blocked user if they attempt to edit a page.
   • Although it's technically optional, a reason is required so that other people know why the user is blocked. The more descriptive, the better (especially when using some of the blocking options below). If possible, consider linking to evidence.

Click "block this user" to apply the block. All blocks are recorded in the block log, and all currently active blocks are listed at the list of active blocks.

The blocking page has three important options associated with the block:

1. Block anonymous users only: When blocking an IP user, selecting this option will allow any registered users to continue editing from that address. This option does not affect a block of a registered user, but it does modify any autoblocks (see below) caused by that block.
   • Generally speaking, this isn't a very useful option. Many of the IP users that are blocked are from spammers or spam bots - if they create an account, they'll still be able to access from that location. This option is really only for use when considering a block of a proxy, tor exit node, or dynamic IP address (such as AOL), as it minimizes the likelihood of restricting actual contributors.
2. Prevent account creation: Anyone who tries to access from the blocked IP address will not be able to create an account.
   • This option should generally be turned on when dealing with an IP spammer, since they've been known to create usernames such as "Ki3H5x" to evade blocks. This also works when blocking a registered user - even though we can't see the IP address, the MediaWiki software takes care of it in the background.
3. Automatically block the last IP address used by this user, and any subsequent addresses they try to edit from: (Autoblock, for short) This option only applies to blocks of registered user accounts. When enabled, this option will cause the block to also apply to the most recent IP address and any other addresses that they try to log in from.
   • This is the mack daddy of blocking. This is the block for that l33t h4x0r d00d who thinks that he can get around a block by having his mother drive him to the library so that he can vandalize Izzy's page again. This option should usually be set when blocking a registered spammer/spambot, as it has a decent chance of blocking another address or two before they figure it out.
   • Autoblocks are taken care of in the background by the MediaWiki software, and last for 24 hours. These blocks only appear on the Special:Ipblocklist page (not in the regular block log) because they are added automatically.
   • Be careful when using the autoblock function, especially in the case of dynamic IPs (AOL being the prime example), as it can result in temporarily blocking large numbers of innocent users.

Range blocking is a way to block all IP addresses in a certain range. Hence the name. Range blocking is a bit different when we're dealing with IPv4 addresses (e.g. 1.1.1.1) vs IPv6 addresses (2001:0db8:85a3:0000:0000:8a2e:0370:7334).

Range blocking is needed for some IPv4 addresses because in countries or for ISPs short of IPv4 addresses, NAT is often used to assign people to a pool of dynamic IP addresses, instead of assigning each end user a different, static IP address. This results in users being able to evade a block by simply restarting their modem. This is the same reason why range blocking in IPv4 is dangerous, as there might be innocent editors who are blocked. As a rule of thumb, IPv4 range blocks should only be done when the vandal is known to be actively abusing the IP range. Knowledge of how to do a successful range block to restrict the block to the minimal number of addresses possible is essential.

An IP range takes the form of 69.208.0.0/24 (for reference, that's the range between 69.208.0.0 and 69.208.0.255) - it shows the IP address at the low end of the block (more or less) and the number after the "/" shows the number of significant bits (it makes more sense in binary, take a look at MW:range blocks). In other words, the "69.208.0.0/24" range actually blocks all IP addresses of the form 69.208.0.XXX. Since an IP address consists of 32 bits, a block of "69.208.0.0/32" is the same as blocking "69.208.0.0."

Make sure to check the IP range multiple times before range blocking, due to the massive possibility of error. One useful site is the netmask calculator, which will automatically compute the necessary values to block all addresses between the two you provide.

Please note that individual IP addresses cannot be unblocked from a range block. Any attempts to unblock that IP will not take effect unless the entire range is unblocked.

The reason for carrying out a range block on IPv6 addresses is different from that of IPv4. IPv6 is designed to never run out, and it has an address space so wide that it is intended to have one public IPv6 address for each device in the network. Welp, here's the problem. If a vandal moves from one device to another, plugs into another ethernet jack in the wall, or programs their router so that they can switch IPs easily, their IP will change even though they haven't left their home. This is why some admins prefer doing a range block for all IPv6 vandals, even if there hasn't been repeated abuse of multiple IPs. As a rule of thumb, one end user (e.g. one household) is typically assigned a /64 subnet.

Therefore, to determine a basic range block target, just add /64 after the IP address, e.g. 2001:0db8:85a3:0000:0000:8a2e:0370:7334/64. Note that it's also incredibly easy to do a wider/narrower range block. Just remember that one hexadecimal digit is 4 bits, and that an IPv6 address has 128 bits in total.

For more information on how to do range blocks for IPv6, see mw:Help:Range blocks/IPv6. https://ip.sb/cidr might also be useful.

It is possible to prohibit the block target from making changes only to specified pages and/or all pages in namespaces. If a page is moved, the restriction will be switched to the new title. This feature is rarely used on the wiki, but it can be used in cases like edit warring or implementing a sanction. Note that non-existent pages cannot be blocked, and setting multiple overlapping blocks with different expiration dates is not supported.

Blocked users may still read pages, but they cannot create, edit, or move pages, nor can they upload files. In general, all additional user rights (deletion, protecting, assign user rights) will be disabled for the duration of the block, but this does not apply to block/unblocking abilities. Any user that has blocking and unblocking abilities will be able to use them during their block (which allows them to unblock themselves).

An IP address or registered user account can be unblocked via the list of active blocks. Find the IP address or registered user account you wish to unblock in the list (you can enter the address or name in the "search" field to help you find the entry), and click the "Unblock" link displayed to the right of the block's expiry time.

This will lead you to a confirmation page. Enter the reason for unblocking (optional) in the "reason" field, and click "unblock this address" to remove the block. All unblockings are recorded in the block log.

Check out Category:Pending deletion to see if there are any pages pending deletion. Do check with other users if you are unsure of anything. For images, remember to check global usage to avoid breaking it on other language wikis.

Sometimes it is necessary for a single revision to be deleted, rather than the whole page. This is useful when a user adds personal or sensitive information, such as access keys and passwords. If you see this, revert it immediately, and hide the revision. The Delete/undelete revisions page can be accessed through the history page.

Hiding a revision removes the text, edit summary and/or the user's name or IP address from public viewing. Only other administrators can see the hidden revision.

The following options are available:

1. Hide revision text. Almost always used.
2. Hide edit comment. Only to be used if the edit summary contains sensitive information.
3. Hide editor's username/IP. Unlikely to be used.

Protecting a page restricts it from being edited. This is primarily used for pages that have a high chance of being vandalized (Main Page) or as a temporary measure on a page that is the subject of an edit war or mass vandalism by multiple users. There are three different kinds of protection:

• Semi-protection: Only registered users are allowed to edit the page. Any anon (IP) contributors will still be able to see the source code, but are unable to make any changes.
  • This version makes a lot of sense on a page that is getting a lot of anon vandals, but it's not very useful in preventing an edit war.
• Full-protection: Only administrators are allowed to edit the page.
  • This version should mainly be used on high-profile pages, pages that should never be changed by a non-administrator or as a very temporary measure to stopping an edit war. Please note that, when dealing with an edit war, no matter which revision you choose to protect, it will be the wrong one. Try to keep any pages protected for as short of a time as possible.
• Director-only protection: Only directors (admins for all language wikis) are allowed to edit the page. This is usually for high-profile pages that are often changed, for example Minecraft Wiki and Template:Version/FP.
• Cascading protection: The page and all images, pages, and templates included into the page are also protected.
  • Cascading protection should NEVER be used with semi-protection. Since Cascading protection automatically full-protects all included pages, any registered user can add an image or template to that semi-protected page to cause it to be full-protected (something that only administrators should be able to do).
  • Most likely, this option will never need to be used here.

By checking the "unlock move permissions" box on the "Confirm protection" screen, the page move rights can be restricted independently of page editing. This is most often used on Project pages that anyone should be able to edit, but that should generally not be moved.

If a page does not exist, it can be protected against creation in the same way that an existing page can be protected from moving and editing. This is generally only done for pages which are frequent vandalism targets with no reason to exist, such as index.php.

To protect an already uploaded image from being replaced with a newer version (such as images used on the Main Page), you can simply use the Protect button like with any other article.

Once in a while you may come across some image filename that shouldn't be uploaded at all to the wiki, (f.i. File:Example.jpg). To achieve this, simply edit the page of that image, (for example to add a reason why that page was protected). After this page has been created, the Protect button for that article will be available, and users trying to upload the image after that will receive a warning message that the page has been protected and will be unable to proceed.

When used to temporarily stop an edit war, protection may be viewed as an endorsement of that particular version. This is not the case. Be careful to remind other users of this and start a discussion on the talk page of the article to resolve the conflict.

Any user can revert a page by going through the page history. Administrators gain access to an additional rollback link to expedite the process. To revert the edits of one user to the last version by the previous editor, click rollback on the page history, the user contribution list, or on the diff page. The reversion will be marked as a minor edit and given an automatic edit summary based on the contents of MediaWiki:Revertpage.

Special:AbuseFilter has a list of all abuse filters on the wiki. These abuse filters can check if an edit or action match a condition and perform functions like preventing the action, tagging it or displaying a warning to the user. MediaWiki:Spam-blacklist and MediaWiki:Spam-whitelist performs similar functionality but only for spam. These tools are very powerful in preventing spam from being submitted at all. Due to their complexity this article will not go into great detail about how to use them – detailed documentation is available at mw:Extension:AbuseFilter#Creating and managing filters. Here are some tips specific to this wiki:

• When editing an abuse filter, an edit summary is not available, so it is generally recommended to document what you've changed in the description.
• In Spam blacklist, it is possible to use regular expression, which is yet another complex topic that we can't get into.
• If you can't read AbuseFilter syntax/regex, it is adviced that you do not touch it. Let a skilled admin do it and watch what they've changed – it's quite fragile.

System messages are all the pages under the MediaWiki namespace. This is what you want to change to modify the text shown in the UI. Now, try appending ?uselang=qqx to this page's URL and come back here.

Welcome back! You are probably seeing a bunch of ⧼things like this⧽. This is totally normal. qqx is a special language MediaWiki uses for the translation key. For example, look that the search box – it probably says searchsuggest-search. Well, if you go to MediaWiki:Searchsuggest-search, you will see the source string. To change the text displayed in the search bar, you just need to edit the page (but please don't actually do that). Please note that this is rarely needed. Here are some special MW pages that you can't find with ?uselang=qqx:

• MediaWiki:Sidebar
• MediaWiki:Sitenotice (and you need to increment MediaWiki:Sitenotice id to make it reappear to users who dismissed it)

CSS and JS pages are system messages. Please don't touch it if you don't know what you're doing! GIMs and other admins are your friend if you need help. With that said, although it isn't a requirement to be an admin, some knowledge of CSS and JS will help, and it is a skill you can use outside of the wiki. You can learn them by following online tutorials and asking for help on Discord.

Most active administrators also actively edit the wiki. This occasionally causes conflict of interest. For example, if people start personally attacking you after an edit to an article, blocking them yourself makes it appear as if you're using your administrator tools to control wiki content.

Thus:

• If you're editorially involved in a conflict, request another administrator's intervention.
• If you're personally involved with a member of a conflict, request another administrator's intervention.
• Only mention your administrator status when justifying or explaining an administrative action.

Administrators do not have any say in the editorial process beyond that of any other editor. The community can sometimes place extra weight on the opinions of administrators, due to them generally being experienced and well respected editors. This extra weight is completely unintentional and stems completely from the culture of the wiki -- people may look up to administrators and may be more reluctant to dispute them. Even though this view is not the administrator team's fault, nevertheless, every administrator should be careful to avoid abusing this additional editorial power.

Some possible ways to avoid abusing administrator authority follow, roughly sorted from simple to complex.

• Negate the importance of the administrator role if it gets brought up in an editorial discussion.
• Be a little more explanatory than usual. Justify edits more completely. Post in talk more often if something might become controversial. This is good advice for everyone, but it's doubly important for administrators -- a lack of an edit summary for any non-minor edit can give the impression of unilateral action.
• Remind people that usual cultural considerations apply to administrators, too. For example, occasionally add "if you disagree, please revert" to your edit summary or talk post. Even though people are always free to revert like this, explicitly stating so helps them get over the fear of reverting an administrator.
• If you get administratively involved with an article, avoid being editorially involved with that article for some time.

• Watching (and watchlisting) the admin noticeboard is useful for awareness of currently requested tasks. The same goes with #wiki-requests. Remember though, that an issue being listed there does not necessarily mean that administrator action is required.
• If an issue is brought to attention in this fashion that requires community input, the administrator should post it as is appropriate.