StrategyWiki:Guide/Admin guide

StrategyWiki Administrators, also known as "sysops", are privileged users who, on top of adding content to the site, are able to perform administrative functions such as deleting pages and modifying protected pages. The following page is designed to be a reference for sysops who need a reminder on how to properly carry out such critical functions. For those wishing to become a sysop instead, please go here.

Page Deletions and Undeletions

Beforehand

Whether it be spam, a copyright violation, or just a page that doesn't have any particular use, pages are constantly being "deleted" from StrategyWiki. Deleting a page is a simple process. All you have to do is click on the "delete" tab, put in a reason, then click "delete." However, there are a few things you should be aware of before doing this:

• Are there any links to the page you are about to delete? Before you delete the page, click on the "What links here" link in the Toolbox. If there are pages that link to the page, point the links to a more appropriate page or remove them.
• Is there a talk page? Deleting a page will not delete its talk page if one exists. Therefore, you need to check to see if there is one; a relatively simple procedure. The "Discussion" link/tab will be blue if a talk page exists, and red if it doesn't.
• Is what you are deleting an image or some other type of file? If it is, these images/files cannot be recovered after deletion, so they will have to be re-uploaded if it is later deemed necessary.

The reason

You will need to include a summary of why you are deleting the page. Most of the time, MediaWiki will give you a default summary. If it does, then use it. If not, then you need to explain exactly why you are deleting the page. The more specific you are, the better the summary. For example, the summary "copyvio from http://www.example.com" is better than simply "copyvio".

Viewing/Restoring deleted pages

If it is later decided that a deleted page should be restored, go to that page and click on "View or Restore # deleted edit(s)." You will then be brought to a screen showing all the past deletions/undeletions of the page, a restore box, and then a list of the page's history. By clicking on the history links, you can see the wiki code of each revision. You can either restore the entire page by just simply clicking "Restore" or just certain revisions of it by checking the check boxes near each history line, then entering a reason in the above box and clicking "Restore".

Merging/Splitting Page Histories

Why?

You will need to merge page histories when someone cuts (or copies) and pastes the content from one page into another, generally-empty page (simulating a page move without actually using the "Move" tab), or when content from 2+ pages with existing content need to become one. Splitting page histories is only done if a history merge from 2+ pages with existing content was later deemed incorrect and needs to be reversed. The reason why this is an issue is because of the GFDL. It is against the terms of the GFDL to create a derivative work without giving some sort of history of past works (even if it is copy/paste).

Merging histories

Merging a page history is easy, but time consuming. Simply follow these steps:

1. Delete the destination page (the page where the history from the other page(s) is/are being merged into).
2. Use the "Move" tab to move the page containing the history needed to be merged to the now-deleted destination page.
3. If there are more than two pages that need to be merged, repeat steps 1 and 2 until you move all of the histories that need to be merged.
4. Undelete the revisions that you deleted to make way for the move
5. Revert the page back to the version where all the needed content was present (or move content from various versions until all the desired content is present).
6. Change all links from the redirect pages you made during the moves to the new location. You may want to delete the redirect pages as well.

Note: Before merging histories, ensure that the pages you are merging are actually the pages that need to be merged together, and once complete, the merge will not have to be split, as splitting page histories is even more time-consuming and difficult.

Splitting histories

Unlike merging page histories, splitting them is quite difficult, and very time-consuming. Follow these steps to properly split page histories:

1. Delete the source page (the page that you are splitting the histories from).
2. Undelete only the selected revisions you do not want to keep on the source page (aka, the revisions of the history that was previously merged into the page, but now need to be split up. If there were more than 2 pages merged, only undelete one of the pages).
3. Move the page using the "Move" tab to the new desired location.
4. If more than 2 pages were merged together, repeat steps 2 and 3 until all histories but the main one that you want to keep have been moved.
5. Undelete the remaining revisions.
6. Revert each split page to the correct version, if necessary.
7. Change the links to the now-split page to their respective pages, if necessary.

Removing select revisions from a page's history

This technique should rarely, if ever, be used. The only time where hiding certain revisions would be necessary is if there is some sort of copyright violation in that revision that needs to be removed, or if there is personal information included in that revision that a user later decides later not to share (such as an e-mail address). To use this feature, go to a page's history and click the "show/hide" link next to the entry you wish to delete. Then, check the boxes that you want to apply to this revision:

• "Hide revision text": Prevents non-sysops from seeing the text of that particular revision
• "Hide edit comment": Prevents non-sysops from seeing the edit comment of that particular revision
• "Hide editor's username/IP": Prevents non-sysops from seeing the username/IP of the editor of that particular revision
• "Apply these restrictions to sysops as well as others": Bureaucrats can check this option to prevent even ordinary sysops from seein the revision text/edit comment/editor's username/IP

After you have selected all the options you want, add in a comment and hit "Apply to selected revision". If you wish to see the older version of this guide (using actual page deletion/restoration), see this revision

Importing Pages

Importing a page is a means of transferring pages across various MediaWiki wikis while keeping the edit history intact (and thus satisfying the GFDL). In most cases, this isn't necessary as you may just link to the page's history on the other wiki, but in cases where it is marked for deletion, you'd want to import the page here. Before you import a page, you have to export it on the other wiki. Go to Special:Export on that wiki and export the page or pages that you want to import here. Then, save the .xml file, go to Special:Import, browse to your saved .xml file, and click "Upload". After a while, the pages, with the edit history intact (if you exported them that way), will be on StrategyWiki. Chances are, the pages you've imported will need a large cleanup to meet our formatting standards, as well as to get rid of all of the red links.

Protecting and Unprotecting Pages

Protecting

To protect a page, click on the "protect" tab. Then, select "Sysops only" from the Edit menu. It will automatically making Move Sysops only as well. Then, enter a valid expiry time (such as "1 year" or "infinite") and a reason for protection and click "Confirm". If you don't want to fully protect the page, the varying options you may choose are outlined below:

• "(default)" means that all registered users may edit/move the page.
• "Block unregistered users" means that all unregistered users and all registered users using an account less than four days old may not edit/move the page. If protecting due to vandalism by anonymous users, it is recommended you use this option instead of the "Sysops only" option.
• "Sysops only" means that only sysops may edit/move the page. This is the most common mode of protection.

If you check the "Unlock move permissions" check box, you may assign varying levels of protection for Edit and Move. For example, an Edit level of "(default)" and a Move level of "Sysops only" means that any registered user may edit the page, but only Sysops may move it to a new location using the "move" tab (this is called "move protection").

If the Edit level is set to "Sysops only", a checkbox called "Protect pages included in this page (cascading protection)" will be enabled. Checking that means that all templates and such included in the page will be protected at the same level of the page. This is how the title blacklist works.

To enter an expiration date, make sure it is in a valid format (either "infinite" or "indefinite" or something with "A Years, B Months, X Days, Y Hours" (any combination will work provided they are in the correct order). Please use common sense when deciding on an expiration date. Critical or "high-risk" pages should normally be protected indefinitely, while perhaps only a week or so is justified on a page where an edit war is taking place to allow enough time for both sides to cool down.

Unprotecting

To unprotect a page, click on the "unprotect" tab. Then, select "(default)" from the Edit menu and enter a reason for unprotection, then click "Confirm".

Protection checklist

Only certain pages really need to be protected, so use the following checklist to determine if the page you are thinking of protecting really needs it or not.

• Is it a highly used template such as the {{Header Nav}}?
• Is it a highly visible page that doesn't need to be changed all that often such as the Main Page?
• Is it an archive of past discussion that should not be edited?
• Does the page exist here for some sort of legal reason, such as the GNU Free Documentation License?

If a page doesn't fit into any of the above categories, then use your best judgment before protecting it, or ask the community. If you are still unsure, it is best not to protect the page.

Protecting entire guides

This technique should only be used in emergency situations when many registered users are vandalizing multiple pages of a guide. To fully protect the entire guide without having to protect each page individually, copy (and modify) the code below and put it into StrategyWiki:Title blacklist. Please note that this will fully protect the guide (so that only sysops can edit it), so do not do this without a very good reason (it also is quite server-intensive).

<DPL>
titlematch=Guidename/%|Guidename
namespace=Namespace
include=0%[0]
format=,\n* [[%PAGE%]],,
</DPL>

Replacements to make in above code:

• Replace both instances of "Guidename" with the name of the guide (NO namespace)
• Replace "Namespace" with the namespace the guide is in (use "namespace=" if it is in the Main namespace)

Note: Semi-protecting entire guides is currently impossible, so just semi-protect pages if they start getting heavy vandalism.

Editing Protected Pages

Editing a protected page is exactly like editing any other page in terms of procedure, but there are a few things to keep in mind before you hit "save page":

• Did you use "Show Preview" and found no mistakes in your edit?
• Is the edit really necessary? If it is like a superfluous edit to a widely used template, it adds meaningless jobs to the job queue.
• Did you discuss the edit you were going to make first? Getting input before editing a protected page is valuable to see what other edits might need to be made to the page, as well as if editing it is even a good idea to begin with.

Banning and Unbanning Users

Don't be ban-happy

As the title of this section implies, don't go nuts with this feature. Before banning a user, make sure that what they did deserves a ban. Generally, the following actions are the only ones that deserve a ban:

• Vandalising, spamming, etc.
  • First offense: warning (use either {{Vandalism warning}} or {{Vandalism only}}), or if really bad, infinite ban.
  • Second offense: second warning (if second offense wasn't all too bad and the first warning was {{Vandalism warning}}), or infinite ban.
  • Third offense: infinite ban.
• Sockpuppeteering (using a sockpuppet): infinite ban, block account creation. Check the New User log to find any other accounts by that person and ban those as well.
• Breaking official policies
  • First offense: notice on the user's talk page.
  • Second offense: another notice on the user's talk page, make it sound a bit more urgent/harsh (or if bad enough, skip this and go straight to "third offense")
  • Third offense: temporary ban (generally an hour or two), notice on user's talk page
  • Fourth offense: longer temporary ban (about a week to a month), notice on user's talk page
  • Fifth offense: infinite ban

If you are thinking of banning someone for a reason other than those listed above, please use good judgment and determine if a ban is truly the best course of action. Also, please note that the actions per offense are merely guidelines. If you believe that a user has done something bad enough to be banned without warning, then do so.

Banning

To ban a user, either click on the "block" link next to their names (on Special:Recentchanges, a page's history, or their contributions page), or go to Special:Blockip and enter that user's name in the "IP Address or username" field. Then, select a time from the "Expiry" drop-down (if you want to enter a time not listed on the drop-down, select other, then fill in the "Other time" field). Finally, enter a valid reason for blocking the user and check/uncheck the boxes for additional restrictions (see below). When all done, click on the "Block this user" link. Meanings of the check boxes:

• "Block anonymous users only": This only applies to when you are blocking an IP Address instead of a user's name. When blocking an IP Address with this box checked, any registered and logged-on users editing from that IP Address will still be able to edit. If it is unchecked and you are blocking an IP Address, any registered and logged-on users from that IP Address will be unable to edit as well. If you are blocking a username, this check box does absolutely nothing.
• "Prevent account creation": If this box is checked, the user will be unable to create an account from that IP Address (if you blocked an IP Address), or while logged on as the blocked username. However, if you block a username, be wary that they will still be able to create accounts once they log out.
• "Automatically block the last IP address used by this user, and any subsequent addresses they try to edit from": fairly self explanatory. It blocks the user's IP Address for 24 hours (you do not get to see the address), and automatically blocks any other IP Addresses the user tries to edit from for a period of 24 hours as well (again, you do not get to see the addresses). This check box is pointless when blocking an IP Address.

Once you've banned the user, make sure to blank their user page and replace it with the {{banned}} template (if the ban is infinite or lengthy). You will probably also want to leave a message on their talk page explaining why they've been banned, unless they were spamming, in which case they're probably a bot, and leaving them a message is unnecessary.

Unbanning

To unban a user, go to Special:Ipblocklist and locate the user that you want to unban. Then, click the "unblock" link, enter a valid reason to unban that user, and click "Unblock this address". Also, if the entry did not say "autoblock disabled" in it, make sure to unblock any of the autoblocked numbers as well.

Rolling Back Edits

Beforehand

A "rollback" is the process of reverting every edit by a user until it reaches a version not by that user (for example, if user "A" edited a page, then user "B" edited it, then user "A" edited it another 5 times, the "rollback" would revert the last 5 edits by user "A"). Accessing this feature is relatively simple. The last edit of each page's history has a [rollback] link next to it, as well as a user's contributions page and while viewing the latest diff from recent changes. However, if only one user has edited a page or someone else has edited after that user, you cannot roll back that user's edits. Do not click the rollback link just to find out what it does. Unlike almost every other action on StrategyWiki, rollback does not have a confirmation page. The action is carried out the moment you hit the rollback link. So, before you hit the link, make sure that you truly want to revert all of those edits.

Afterwards

Since the rollback feature gives an automated summary, you cannot specify why you reverted all of those edits. Therefore, it is generally common courtesy to leave a message on the user's talk page as to why you reverted all of those edits.

"Bot" rollback

If a user has a mass flood of edits that you want to revert, you may want to do a "bot" rollback. To accomplish this, go to the user's contributions page, then look at the URL. If the part after strategywiki.org says "/wiki/", then add ?bot=1 to the end of the URL. However, if the part after strategywiki.org says "/w/index.php?", add &bot=1 to the end of the URL instead. After adding that part to the URL, browse to the new address. Then, click the rollback links next to the pages you want to roll back. Once it is completed, it will hide the original edits and the reversion of them from Special:Recentchanges unless they click on "Show bots". This does not hide the edits from contribution pages or the page's history, however, so it should not be used to hide edits, merely to prevent a mass amount of them from flooding Special:Recentchanges.

Patrolling Edits

Patrolling edits is a key part in making sure that every edit made to StrategyWiki is effectively and efficiently looked over by an administrator. Unpatrolled edits have a ! by them in Special:Recentchanges, so if you have some free time, browse through their diffs (either via the "diff" link or "last" link). When you get to the page, you should see a link saying [Mark as patrolled]. Once you look over the edit and determine that it isn't vandalism or doesn't need any cleanup/copyediting, then click that link to notify other administrators that the edit was valid and they don't need to check it. Ideally, every edit should be patrolled. However, since some administrators don't look at edits already marked as patrolled, don't click on the [Mark as patrolled] link without actually looking over the diff first.

Enforcing Policies

Every administrator should know the policies here at StrategyWiki and be able to uphold them. When enforcing these policies, use the message templates to notify users that they are breaking them, and be kind about it. Chances are they didn't know that it was a policy. For the sequence of warning users, please see the banning section.

Changing a User's Rights

Changing a user's rights is limited to Bureaucrats. To change a user's rights, go to Special:Userrights, enter the name of the user, and select the rights you wish to give that user or remove from that user (select multiple by holding Ctrl and clicking). The rights applicable are outlined below:

• "Sysop": Sysop access. This gives the user access to everything mentioned above.
• "Bot": Bot access. This hides the user's edits from Special:Recentchanges unless "Show bots" is selected.
• "Bureaucrat": Checking this box will give the user Bureaucrat rights. Use this in tandem with setting "Sysop"

This should be obvious, but do not change a user's rights mindlessly.

Locking the Database

Locking the database essentially makes StrategyWiki read-only. To use this feature, go to Special:Lockdb and enter a reason, then confirm the lockdown. Needless to say, don't do this unless it is absolutely necessary. This action is by default disabled, but it may be enabled for Bureaucrats by setting $wgGroupPermissions['bureaucrat']['siteadmin'] = true; in LocalSettings.php (in the filesystem -- not a wiki page). Similarly, the database may be unlocked via Special:Unlockdb.

Welcoming users

If you see an edit (in recent changes) made by a user with a non-existent talk page, please create the talk page and create it with the content {{subst:welcome}} to welcome the user. Your signature will automatically be appended.

If the user making the edit is an anonymous user (not logged in), use instead the following markup, which encourages them to register and contribute more: {{subst:register}}. Again, your signature will automatically be appended.

Removing anon permissions

This should only be used in drastic moments (such as a DDoS, heavy anonymous bot edits from proxies/multiple IPs, or a flood of bot account creations). Edit MediaWiki:Anonrights by putting a bulleted list containing the right to remove. The rights that can be removed this way are below (with explanations)

• read: setting this prevents anonymous users from being able to view pages
• edit: setting this prevents anonymous users from editing all pages
• createpage: setting this prevents anonymous users from creating new pages
• createtalk: setting this prevents anonymous users from creating new talk pages
• createaccount: setting this prevents anonymous users from creating new accounts

Again, do not use this without a really good reason. Follow the directions here if you need more assistance in using this.