Extension:Moderation

Moderation extension protects small/medium wikis against vandalism.

This is one of the most effective anti-vandal protection methods. It has very little impact on legitimate users.

Introduction

 * How does it work?
 * 1) Every edit (or image upload) by a new user is being sent to moderation.
 * 2) Until the moderator approves this edit, the page is unchanged. Pending edit is neither in page history nor on RecentChanges.
 * 3) The user can see his/her edit and continue editing his/her own version of the page.


 * How do the admins moderate?
 * 1) New special page is provided (Special:Moderation). It's much like the RecentChanges, but has "Approve", "Reject", "Approve all" and "Reject all" buttons.
 * 2) Rejected edits go into the rejected archive.
 * 3) Approved edits are applied normally.
 * 4) Logs "who approved what" are maintained. Only the moderators can see them.
 * 5) If edit conflict is detected and it can't be resolved automatically, the moderator has the Merge button to apply the edit manually.


 * Why is it good?
 * 1) New users are not discouraged by annoying captchas, phone number verifications, etc. They edit normally, like they would do in MediaWiki without moderation.
 * 2) Blocks become practically obsolete. And blocks are not good (consider the chance of hitting a legitimate user with a range block, or inability to allow good edits from a not-very-adequate user who sometimes has the urge to vandalize a page or two).
 * 3) Vandalism out of "wanting to be noticed" is discouraged. Noone would sit for 5 hours looking for new and new proxies to make admin angry, if it's known that all those actions are not a problem.
 * 4) Vandalism methods like "vandalizing one page from two accounts to prevent one-click rollback" are no longer effective.
 * 5) Website can operate in anonymous networks like TOR or I2P.

Alternatives
Does MediaWiki have other counter-vandalism methods? In brief - not really.

MediaWiki was developed for Wikipedia. At any given time, Wikipedia has hundreds of volunteers willing to revert vandalism in real time. Almost every other wiki besides Wikipedia doesn't have that kind of advantage. The built-in counter-vandalism idea of MediaWiki is that vandalism takes more time than reverting it. Normally that's true, but this does poor job at discouraging vandalism, and the admins still have to check for vandalism in real time, even if the reverting itself doesn't take much of their time.

There are three known methods of fighting vandalism:


 * 1) Make all edits hard. For example, Lurkmore.to imposes a strong captcha on all edits from new users, and it takes a lot of edits to finally be able to edit without the captcha. Therefore the vandal has to spend a lot of time to do a handful of edits.
 * The obvious minus is that all legitimate users have to bypass the captcha as well, which could discourage minor edits like spelling fixes.
 * 1) Enforce user identification - for example, login via Facebook. If the social network verifies that all its users have a valid mobile phone number, then each vandalism attempt requires the vandal to go to the shop and buy a new SIM card. This method is extremely effective, though eliminates the anonymous editing and turns away the users who don't have an account in any supported social network.
 * A strong minus of this method is the impact on users' privacy. In non-democratic countries editing a page on politics can result in government trying to identify and persecute the user. For example, Lurkmore.to was contacted by Russian "anti-extremist special force" with demands to disclose information about the authors of pages about Ramzan Kadyrov and Molotov cocktail.
 * 1) Mitigate the results of vandalism. For example, a user can create 100 pages with offensive titles, but they can all be deleted by two clicks in Extension:Nuke. Moderation extension belongs to this category.

Is this extension stable?
This extension is beta. It was only tested with MySQL. This extension has been deployed in production on Russian Uncyclopedia (absurdopedia.net) since November 2014.

Please read the files KNOWN_LIMITATIONS, TODO and WONT_DO for all known issues. Feel free to contact the author if you have any questions.

The extension has an automated testsuite with significant coverage. See README.testsuite for details.

Configuration

 * Parameters for LocalSettings.php:
 * $wgModerationEnable : If set to false, then new edits are applied as usual (not sent to moderation). Default: true.
 * $wgModerationTimeToOverrideRejection : Time (in seconds) after which rejected edit could no longer be approved. Default: 2 weeks.
 * User rights:
 * skip-moderation : If the user has this right, his/her edits are applied as usual (not sent to moderation).
 * moderation : Allows access to Special:Moderation.
 * moderation-checkuser : Allows to see IPs of registered users on Special:Moderation.
 * Default settings are:
 * By default, two groups are created: moderator (has moderation right) and automoderated (has skip-moderation right).
 * By default, group checkuser has moderation-checkuser right.

Additional anti-vandalism tips
In order to prevent vandalism, the following additional measures should be applied:


 * 1) Absolute MUST for any small/medium wiki (with or without the moderation): moving pages must be restricted to a trusted group. Page moves are currently not intercepted by Extension:Moderation, and they are a popular type of vandalism.
 * 2) Registering new accounts with offensive names is still a way for a vandal to show itself in the RecentChanges. A simple solution is to remove newusers log from RecentChanges:

Recommended use / good practices
The following good-practices are advised:


 * 1) Only vandalism should be Rejected. Not-so-good edits with good intentions (e.g. adding excessive plot details into the Wikipedia article about film) are better made Accepted and then reverted as usual. This way the author is not offended and the text is saved in page history, viewable by anyone.
 * 2) Any user that deems legitimate (does N good edits) should be granted automoderated flag.
 * 3) Adding automoderated flag via $wgAutopromote is NOT recommended, as it motivates the vandals to do many very-minor edits (e.g. adding interwiki). Better grant the flag manually for one good edit and not grant it for 30 useless-edits-made-for-count.
 * 4) Abstain from using blocks. Limit the use of page protections to templates, etc.
 * 5) Allow the full rehabilitation of users with bad history of editing. Their useful edits to the articles should be allowed, no matter how many times they were blocked. At the same time, trolling on talkpages should be rejected, so are the purposely-low-quality edits.

Compatibility with other extensions

 * 1) Extension:Moderation must be enabled last in LocalSettings.php, because it aborts at least PageContentSave hook.
 * 2) Extension:Moderation fully supports Extension:CheckUser, meaning that if CheckUser extension is enabled, then any approved edit will have correct IP, user-agent and XFF saved in the checkuser tables.
 * 3) Sadly, Extension:Moderation is NOT compatible with Extension:VisualEditor.
 * When Moderation intercepts an edit, resulting status becomes "edit-hook-aborted". For normal editing form, this is OK (because saving causes a redirect anyway), but VisualEditor uses API and considers "edit-hook-aborted" to be an error. MediaWiki has no hooks that would allow to "rewrite" this "api-hook-aborted" with "success". Also preloading wouldn't work, as javascript-based editor would try to preload the latest revision (instead of pending change). Fixing this would require fixes to Parsoid, overriding ApiEdit class, etc.
 * 1) It's not a good idea to mix Extension:Moderation with upload extensions like Extension:MultiUpload. MediaWiki hook for uploads is not receiving all the necessary information (e.g. image description is not there), so Extension:Moderation has to parse the rest from the request parameters using SpecialUpload->loadRequest. If some upload form is different from Special:Upload, this won't work. Because of that, uploading via API is also disabled for users without skip-moderation right.