Extension talk:Moderation

Works with Echo?
Hi, Thank you for creating this very useful extension! Does Moderation work with Echo to notify users on accepted or rejected edits through its notification system? If it doesn't notify, will it be very difficult to do that with the process described in this page? 106.51.25.183 07:12, 9 February 2017 (UTC)
 * Not yet. It's pretty easy to implement. The question is, is this a good idea?
 * If an edit got rejected, it was probably vandalism or spam, so do we need to invite the vandal back to the wiki about which he might have forgotten already?
 * Good users, on the other hand, will be quickly made automoderated by administrator, so they won't see the moderation for long. Besides, they can continue editing their version immediately (before it is accepted), so it's not like they have to impatiently wait for that.
 * Generally, a user would want to be notified "my edit was approved/rejected" only if he/she doesn't know whether it will be approved or rejected. For example, on a humor site where "funny jokes are approved, non-funny are rejected". When following Good Practices #1, approval is assured if the edit wasn't made with bad intent. Edward Chernenko (talk) 07:53, 9 February 2017 (UTC)

Plans with Flow
Hello, are there plans to support Flow extension anytime soon? Would it be difficult to do so? Thanks. --Krusher (talk) 07:29, 7 October 2016 (UTC)
 * Hello, I don't use Flow, so I wasn't planning to implement this myself (unless hired to do so). You can help by looking for another developer (who is interested in Flow) who would contribute such code. Edward Chernenko (talk) 08:07, 7 October 2016 (UTC)
 * Btw, I had a quick look - it seems it would be easier to implement this feature within Extension:Flow itself. Edward Chernenko (talk) 18:40, 20 November 2016 (UTC)

DownLoad
I am not quite sure what to download from here or from Git. Am I supposed to install Vagrant? Please tell us more exactly what to do. --Ruud Habets (talk) 11:48, 30 July 2015 (UTC)
 * Here is a direct link:.

Email notifications and RSS
It should be configurable to send info to certain email(s) when a new unmoderated change appears.

The number of such emails per day should be limited.

The list of proposed changes should also be available as RSS (or Atom) feed. The URL of the feed should probably include a passphrase.
 * RSS feed is a good idea and is added to the TODO list. As for emails, I don't really want to go into that here. If someone else implements this, such change can be merged. -- Regards, Edward Chernenko 10:42, 16 May 2015 (UTC)
 * Btw, User:Vedmaka has implemented the emails part (many thanks!). See comments for,   and   in Moderation.php for details. Edward Chernenko (talk) 18:44, 4 March 2016 (UTC)

Wonderful! Can we set this to notify all moderators? Or a list of emails or users? thanks Tansaku (talk)
 * No. Sending these emails is not queued (it is done immediately), so if you had a list of 10-20 emails, there would be a considerable delay each time non-automoderated user saves a new edit. Edward Chernenko (talk) 14:08, 4 May 2017 (UTC)

Q&A
Is it possible to view the revised version of an update that's pending moderation? We can see the diff but it doesn't look like we can see the new page. As I understand it, it's probably best to approve anything that's not spam and then to revise the result. Is that the proper approach? Thanks.
 * Hello, although previewing (as when you click Preview button) pending edits can be implemented, I doubt this feature will be used. It's not a good idea to approve/reject edits based on whether they are formatted good or not, as if you reject badly-formatted edit with good text, author will be offended and won't know why it wasn't approved. General idea is to approve edit that is not vandalism/spam and then either fix its appearance if the added text is worth it, or revert if it's not that good to bother. Both ways, the text stays in history. When reverting, you also can specify the reason (viewable to whoever made the edit), when rejecting, you can not. -- Regards, Edward Chernenko 10:42, 16 May 2015 (UTC)

First, congratulation for this great work you did! We are trying to implement a workflow for some papers publication in wiki. Your extension fulfill most of our requests, and for us would be very useful to have next to diff button there, a preview for pending edits. Regards, --LiaVeja (talk) 10:23, 18 June 2015 (UTC)
 * I will implement this (there will be an option in LocalSettings turning Preview link on). -- Regards, Edward Chernenko 23:58, 19 June 2015 (UTC)
 * Hello, I have implemented this feature. Please try it out and let me know if it solves your problem. -- Regards, Edward Chernenko 00:47, 25 June 2015 (UTC)

SPAM
I see "Reject" and "Reject All" links, but no link "SPAM" for a particular edit. Thus I rejected some spam changes, but http://withoutvowels.org/w/index.php?title=Special:Moderation&folder=spam folder is empty. I want spam in spam folder. If a folder is always empty, this makes no sense.
 * There is a misunderstanding here.
 * "Mark as spammer" button is not the same as "Spam" button in your mailbox. When you press "Spam" in, say, Yahoo Mail, the message is analyzed and in the future Yahoo Mail will (theoretically) filter messages like that more effectively. To detect future spam like that, tens of thousands of spam messages must be analyzed. Yahoo can do it, one single wiki can't. Therefore such feature can't be implemented.
 * "Mark as spammer" is a completely different feature. It is also called a "moderation block". It is intended to block vandals, not spam. Because if you block them as usual, they'd just register a new account and continue vandalizing; but if you use "Mark as spammer", then they won't even know they were banned; their edits will just go into the Spam folder.
 * There are tonns of extensions for combating trivial spam. Noone wants to sit and moderate them one-by-one. Moderation is primarily a counter-vandalism extension, i.e. against human vandals (as they waste time and admins don't). For spam bots, time is of no concern; AbuseFilter is a good measure against them. -- Regards, Edward Chernenko 11:23, 26 May 2015 (UTC)

Feature suggestion: Different levels of moderators
I suggest to allow to moderate edits of certain pages only by users of some right group. For example, I want changes to the "Donate" page of my nonprofit be approved only by administrators, not just moderators, because it is related with money.
 * It would be more practical to simply protect "Donate" page from edits by non-administrators. Edward Chernenko (talk) 13:48, 2 December 2015 (UTC)

Doesn't seem to work very well with Flow
This extension doesn't seem to work very well combination with Flow. When creating a new talkpage weird errors happen.

This is more of an "FYI" than bug report, by the way ;-) Its perhaps something to mention on in the README... Carpetsmoker (talk) 14:03, 2 February 2016 (UTC)
 * 1) For now, I allowed edits in Flow forums to bypass moderation. 2) (why these errors occured) Extension:Flow uses its own "Content model" (simply speaking, forum pages are not stored as plaintext, unlike other wiki pages). For edits in Flow forums to be queued for moderation, we will need to add support for this content model. Edward Chernenko (talk) 21:59, 3 February 2016 (UTC)

Suggested Additions
First off, extension works great. Perfect for what we need.

A few suggestions:
 * When viewing the differences between the current version and the proposed edit, there should be an "Approve" button on that page. Clicking this approve button should bring you back to the Special:Moderation page. (+1 Tansaku (talk))
 * When clicking "Approve" on the Special:Moderation page, you shouldn't be redirected to a separate confirmation page. It should just reload the page with a confirmation message at the top. (+1 Tansaku (talk))
 * Possibly have a message on a page with a pending edit that lets the viewer know that there is an updated version, it just hasn't been approved yet. I believe the ApprovedRevs extension does something similar to this. (+1 Tansaku (talk))

And this may be totally undoable, but it would be super cool to have moderation groups set up by category. ie the 'moderation-cata' user group can only approve pages that belong in the category 'A'. --66.45.189.35 16:18, 12 February 2016 (UTC)
 * "Approve button on pending diff page" - good idea, will do this shortly.
 * "Clicking Approve shouldn't leave Special:Moderation" - planned (already in TODO) but low prio, will be done if there is time. Probably we shouldn't even reload the page here - Approve link can use Ajax. At the mean time, it's convenient to open Approve links in separate tabs (middle mouse button click on them).
 * "Letting the viewer know that there is a pending version" - will NOT be done. An important advantage of moderation is that it demotivates the vandals, because the viewers can't see vandalism in any way. Allowing users to see "non-approved" version, if they want (as with ApprovedRevs on stabilized pages) would negate this advantage.
 * "Moderators that can only moderate edits in certain pages" - seems unnecessary (see "Different levels of moderators" topic above, the same thing). It's not as if you can trust some person not to approve vandalism in pages about Cats, but can totally expect the same person to approve vandalism in pages about Dogs. You either trust a person to be a moderator or not. Edward Chernenko (talk) 17:01, 12 February 2016 (UTC)


 * The ability to let a user moderate pages only with specific categories. Ryan 23:24, 28 November 2016 (UTC)
 * Too difficult to implement + useless in 99.9% of wikis. Edward Chernenko (talk) 23:33, 28 November 2016 (UTC)

Problem with bot edits
When I try to run  (with suitable stdin), it says:

Saving... failed Edit aborted by hook. It gave no explanation.

It seems that the hook in question is from `Extension:Moderation`.

After this I manually confirm the bot edit through `Extension:Moderation` interface.

Please make possible `Extension:Moderation` not to interfere with bot edits.


 * Hello, you can easily fix this:
 * Method 1: you can use edit.php like this:  - where NameOfUser is an account who has automoderated flag.
 * Method 2: add the following to LocalSettings.php:
 * The default behavior is correct, because you were technically editing as anonymous user, not as a bot. Edward Chernenko (talk) 08:09, 14 December 2016 (UTC)

Functionality compared to FlaggedRevs and Approved Revs?
Isn't this basically the same thing as FlaggedRevs and Approved Revs? The core functionality of all these extensions is that new edits aren't seen by the public until it's been manually approved by an authorized user. FlaggedRevs is a bit more complicated, but Approved Revs seems to do the same thing and has been around longer? Is there a difference I'm not seeing? Under what circumstances would one deploy this extension instead of the others? Monitorio (talk) 21:33, 13 February 2017 (UTC)
 * The key difference is that FlaggedRevs/ApprovedRevs hides the bad revisions only from readers. The vandal edits will still exist in history and RecentChanges, and all editors will stumble upon them when they try to edit the page which was vandalised. Therefore administrators have to revert vandalism in real time.
 * On the other hand, Moderation completely eliminates vandal edits. Because pending edits are stored separately, non-approved revisions are simply not created in page history, etc. This ensures that not only readers, but also other editors won't see the vandal edits in any of the pages.
 * In short, (1) FlaggedRevs is for quality control but doesn't help against persistent vandalism. (2) Moderation is specifically against vandalism and renders it completely ineffective. Edward Chernenko (talk) 22:03, 13 February 2017 (UTC)
 * Thanks for clearing things up. So Moderation intercepts edits and prevents them from even technically editing the page in the first place? So in the event of a massive automated spam campaign, I'd mass reject edits instead of reverting? Monitorio (talk) 22:17, 13 February 2017 (UTC)
 * Exactly. You don't need to check RecentChanges often to make sure that new bad edits haven't appeared. You can check pending edits when it is convenient to you, and until you Approve the edit, it won't appear in the wiki. Grant "automoderated" flag to good users to auto-approve their edits. Edward Chernenko (talk) 22:41, 13 February 2017 (UTC)

Php deprecated warning
I installed the extension then this error started to appear in the error_log file: PHP Deprecated: Non-static method ModerationApproveHook::getTaskKey should not be called statically in /path/to/my/installation/extensions/Moderation/hooks/ModerationApproveHook.php on line 149

Is there a solution for this?

Thanks
 * Fixed (please download the latest version of the extension). Thank you for noticing this. Edward Chernenko (talk) 18:30, 26 April 2017 (UTC)
 * Thanks a lot. I confirm that the error message is gone now. Much appreciated.

How to translate the message editing confirmation message?
Is there a way to translate the message that appears when someone edits a page? so that it appears in the language that the Mediawiki installation is in? thanks.
 * Yes. You can modify this message by editing MediaWiki:Moderation-edit-queued in your wiki (plus, if user was anonymous, MediaWiki:Moderation-suggest-signup). Edward Chernenko (talk) 12:53, 27 April 2017 (UTC)
 * If (1) you have many wikis or (2) if you want to translate all messages (not just this one), you can translate the file extensions/Moderation/i18n/en.json (part of the lines after ":") and save it as, for example, "fr.json" for French. We could then add this file into the new version of extension. Edward Chernenko (talk) 12:53, 27 April 2017 (UTC)

How to remove moderation from individual users
I'm reading in the documentation that users can be assigned a 'skip-moderation' flag when they've done a sufficient number of good edits. I was confused whether this was something that could be done through the moderation interface (e.g. clicking 'approve-all') or required editing a config file. I've achieved the desired effect by adding users to the "automoderated user" group on the User rights management page: Special:UserRights - would be cool if this was an option on the moderation page so that one didn't have to navigate to the user rights management page. Tansaku (talk)
 * 1. Is this really needed? UserRights is already only two clicks from Special:Moderation (userpage -> "User rights management").
 * 2. I thought about adding a link which would open Special:Userrights (with prepopulated fields: username + already selected 'automoderated' checkbox), but sadly Special:Userrights ignores parameters like ?wpGroup-automoderated=.
 * 3. I'm not very comfortable duplicating code of UserRights in Extension:Moderation itself (for one-click "make automoderated" link), because future versions of UserRights may include additional security checks/options, and Moderation could bypass them because it wouldn't know about them. Edward Chernenko (talk) 13:33, 4 May 2017 (UTC)

How to restrict moving pages
The main page says:
 * 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.

How should this be done. Specific example text would be very helpful. Cariaso (talk) 01:16, 27 May 2017 (UTC)
 * To allow only administrators to move pages:  See Manual:User rights for details. Edward Chernenko (talk) 05:05, 27 May 2017 (UTC)
 * Thank you Cariaso (talk) 00:44, 29 May 2017 (UTC)

whitelisting users
I have the Moderation extension successfully installed, but I do not understand how to allow certain users to have their edits not require approval. The test user is already a member of what UserRights shows as 'automoderated user' and what I see in mysql as ug_group = 'automoderated'. My LocalSettings.php says  What else might I need? - Cariaso (talk) 00:44, 29 May 2017 (UTC)
 * Nothing else. Edits of "automoderated users" are applied immediately (not intercepted by Moderation). Edward Chernenko (talk) 00:53, 29 May 2017 (UTC)