Extension talk:Moderation/Archive 1

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. [[User:Edward

Chernenko|Edward Chernenko]] (talk) 18:40, 20 November 2016 (UTC)

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 extension.json 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. New edits made by "automoderated users" will be applied immediately (not intercepted by Moderation). Edward Chernenko (talk) 00:53, 29 May 2017 (UTC)
 * Aha! my user was a bot, so  was also necessary. Cariaso (talk) 06:31, 1 June 2017 (UTC)
 * Thank you for finding this. I added this as default (for MediaWiki 1.28+). Edward Chernenko (talk) 01:45, 9 June 2017 (UTC)

A few questions/possible improvements
Hello! First of all, I really appreciate your extension -- it does awesome job!

I would like to ask a few questions, though:


 * Would it be possible add the "Pending for moderation" section directly to Special:RecentChanges as well? The background: I use Special:RecentChanges for years, and I use various filters that are provided by that page. Having a separate page, Special:Moderation, is not very convenient to me yet, and I'm afraid of missing a bunch of edits there (pending edits are self-destroyed after a certain amout of time, right?).


 * I use edits patrolling, so once I accept an anonymous edit I also have to mark it as patrolled. Doubling the moderation job here... Would it be possible to mark accepted edits as patrolled automatically?


 * Text conflicts. Once there is a text conflict, the conflict resolving page suggested the "mine" text only, but also provides the colorized diff above the text editor. This requires to copy "theirs" text by hand. Would it be possible to put both "mine" and "theirs" texts in the text editor with standard,   and   marks similarly to what Subversion, Git or Mercurial do on suggesting to resolve text conflicts?


 * Rejected edits are still kept and they can be approved later. Would it be possible to add a "Purge" or even "Purge all rejected edits" to forget such edits?

Sorry for too many questions, but your extension is really awesome. 92.253.250.171 17:41, 10 August 2017 (UTC)
 * It would be too difficult to merge Special:Moderation into RecentChanges.
 * Unlike RecentChanges, pending edits are NOT auto-destroyed. They are stored indefinitely. Even if you visit Special:Moderation once a year, you can approve an edit made 11 months ago.
 * If you want to use patrolling to manually patrol changes of automoderated users (but not the changes you Approved on Special:Moderation), you can do
 * Resolving edit conflicts is a feature of MediaWiki core (Moderation simply opens an edit form in conflict mode). Please submit a feature request to MediaWiki core to improve this.
 * Rejected edits can be only approved for $wgModerationTimeToOverrideRejection seconds (default: 2 weeks).
 * If you are one of those "let's save 640 kilobytes of disk space" administrators, just delete them from the database. . Such actions are too dangerous to be accessible from the web interface (if you have >1 moderator, you don't want another moderator to hide the misuse of Reject). Edward Chernenko (talk) 18:36, 10 August 2017 (UTC)


 * Got it.
 * &mdash;
 * Ah, I missed that point. Your suggestion makes perfect sense. Maybe something like "Accept+Mark as patrolled" then? (I didn't see your suggested configuration while I was typing the reply.)
 * I wasn't aware of that.
 * &mdash;
 * Well, not that a 640K guy. :) Actually I'm afraid of re-accepting vandal edits accidentally. But now I understand your point if having more than one moderator and possible misuse. However, we have a team of mods that trust each other. (Yep, a weak argument)
 * Thanks! 92.253.250.171 18:52, 10 August 2017 (UTC)

Doesn't play well with other extensions that create pages
I keep getting errors like this one:

If I had to guess, I'd say probably AutoCreateCategoryPages extension is being moderated?


 * Are you using the latest version of Extension:Moderation? Since 1.0.46, it no longer calls "commit" in ModerationEditHooks::onPageContentSave. Edward Chernenko (talk) 09:26, 5 January 2018 (UTC)

[Solved] 'skip-moderation' Blocks Sysop Edits
This prevents WikiSysop from editing pages. They don't even see the 'Edit' tab. $wgGroupPermissions['autoconfirmed'] = 'skip-moderation'; Why? How to fix?

Here's the full config i'm using: wfLoadExtension( 'Moderation' ); $wgModerationTimeToOverrideRejection = 31556952; $wgModerationNotificationEnable = true; $wgGroupPermissions['sysop']['moderation'] = true; # Allow sysops to use Special:Moderation $wgGroupPermissions['sysop']['skip-moderation'] = true; # Allow sysops to skip moderation $wgGroupPermissions['automoderated']['skip-move-moderation'] = false; # Moderate page-renames/moves. $wgGroupPermissions['sysop']['skip-move-moderation'] = true; # Don't moderate sysop renames/moves. $wgAutoConfirmCount = 10;
 * 1) $wgGroupPermissions['autoconfirmed'] = 'skip-moderation';	# BLOCKS SYSOP EDITS. HOW TO FIX?

Johnywhy (talk) 00:04, 21 June 2018 (UTC)
 * This line has a typo (it deleted all rights from "autoconfirmed" users, including "edit"). CORRECT: . Edward Chernenko (talk) 00:38, 21 June 2018 (UTC)
 * Thx, is this fix bundled into the git download now? -thx Johnywhy (talk) 07:50, 25 June 2018 (UTC)
 * What fix? You made a typo in your LocalSettings.php. There was no error in Moderation. Edward Chernenko (talk) 11:10, 25 June 2018 (UTC)
 * oops, thx, i understand. Johnywhy (talk) 14:36, 25 June 2018 (UTC)