Extension talk:Moderation

How to download without Git
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: https://github.com/edwardspec/mediawiki-moderation/archive/master.zip

Existing users moderated?
Where it says "Every edit (or image upload) by a new user is being sent to moderation.", does that also apply to existing users? I've tested it out on another site and regular, existing users are being forwarded to moderation and I'm having to manually go through the most active users and hange them to automoderated users, is that supposed to happen? --2A02:C7F:5E14:BD00:115B:E256:8C43:DCC9 18:58, 3 August 2017 (UTC)


 * Yes, the user should be manually made "automoderated" to bypass moderation. This is not done automatically.
 * You can, of course, set $wgAutoConfirmCount and write something like
 * to make users automoderated after 10 approved edits.
 * This is not a default behavior, because such configuration would allow a human vandal to easily bypass Moderation (they can fix 10 typos, which you would approve, and then they can start vandalizing. With manual promotion, you can approve the typo fixes without making the user automoderated). Edward Chernenko (talk) 21:59, 3 August 2017 (UTC)

So where the doc says "new user", that's not quite correct. They mean "any non-autoconfirmed user" or "any non-automoderated user" or "any non-skip-moderation user". Or something like that. Even if they're a very long-time user. Right? Johnywhy (talk) 23:45, 20 June 2018 (UTC)
 * Yes. It doesn't depend on when the user registered (or how many edits made). The user must have "skip-moderation" permission (e.g. be made "automoderated" by admin). Edward Chernenko (talk) 00:32, 21 June 2018 (UTC)
 * The docs say "new user", because when the admin follows "Best practices" (#2), he would grant "automoderated" flag to everyone except new users (users who contributed too little to tell if they are ok). Edward Chernenko (talk) 00:32, 21 June 2018 (UTC)

Exclude Namespaces
Is it possible to exclude several namespaces from the extension?
 * Implemented in 1.1.20. Edward Chernenko (talk) 18:16, 25 March 2018 (UTC)

This extension is very good
I am very pleased with how effective this is at stopping vandalism. After installing it on a small project focused wiki prone to outrageous trolling and vandalism, the problem was solved overnight. After a few days the vandals actually gave up and stopped even bothering, clearly bored that they could do no damage. All the main project contributors are auto-moderated so the moderation workload is very light. Would certainly recommend. JLJ001 (talk) 16:09, 26 May 2018 (UTC)

Is Moderation meant to replace patrolling?
The stock mediawiki patrolling feature is a bit of a pain to use, because there's no "approve all" button, and it has some other design issues that Moderation does not seem to have. Do users of the Moderation extension disable the stock patrolling feature, or use Moderation as a supplement to it? 73.118.51.32 00:27, 9 August 2018 (UTC)
 * Some wikis use both. Patrolling (or an extension like FlaggedRevs) is used for quality control (high-quality edits are marked as patrolled, but there may also be unpatrolled pages/revisions in the wiki and it's ok) and Moderation as an anti-vandalism tool (everything that is not vandalism gets approved, even if you don't have the time to thoroughly check the edit). Very few wikis use Moderation for quality control. Edward Chernenko (talk) 01:07, 9 August 2018 (UTC)

git releases like REL1_27
Would you mind using either the REL1_XX tags that most extensions use or provide a table for last known git commit or released version for a given MW release? It's not always possible to be current everywhere. Thanks --184.9.147.93 20:33, 20 January 2019 (UTC)
 * The master branch of this extension is backward compatible with 1.27. It will work with 1.27, 1.31 and 1.32 without any changes. For wikis that need even earlier version, there is REL1_23 (similar branch will be created for MediaWiki 1.27 when it becomes obsolete). Edward Chernenko (talk) 22:34, 20 January 2019 (UTC)
 * Update: REL1_27 branch was created for 1.27-1.30. The master branch supports 1.31+. Edward Chernenko (talk) 03:36, 16 November 2019 (UTC)

How do i use $wgModerationEmail?
$wgModerationEmail Is mentioned in the "Documentation" but I can't find any other mention on how to use it.
 * . Edward Chernenko (talk) 01:44, 22 January 2019 (UTC)

Bypass Moderation for Individual Pages?
Sometimes we use our wiki for creating a shared collaboration document for recording timings, short comments, etc. It works really well.

However, the extra Moderation step is a hinderance in this situation (excellent otherwise!).

Is it possible to exclude new pages via a category, flag or other method, to bypass Moderation?
 * Place them into a separate namespace (e.g. Document:Name of page) and use  in LocalSettings.php. Edward Chernenko (talk) 11:34, 24 January 2019 (UTC)

Exclude File Uploads from Moderation?
Is it possible to exclude file uploads from Moderation?
 * Yes, add NS_FILE to $wgModerationIgnoredInNamespaces array. Edward Chernenko (talk) 16:00, 24 January 2019 (UTC)

Hooks when a moderator approves an edit?
Are there hooks I can tap onto when a mod/sysop approves an edit?
 * You can use PageContentSaveComplete hook. Edward Chernenko (talk) 18:25, 18 October 2019 (UTC)

Question: what does a non-automoderated user see/know when editing?
We read How does it work? Every edit (or image upload) by a new user is being sent to a moderation queue. Until the moderator approves this edit, the page is unchanged. Pending edits are neither on the page history nor in RecentChanges. The user can see their edit and continue editing their own version of the page. OK, but mention what the user sees. Also mention what if he wants to change, or withdraw entirely, his edit while it is still in the queue: Jidanni (talk) 00:05, 16 November 2019 (UTC)
 * Does he see a message "your edit is queued waiting for approval." "You will be notified (how?) once it is approved."? Or,
 * Does he see nothing: making him think his edit worked. Only to find his friends can't see it yet?
 * Now, or
 * Later, from a different computer.
 * After saving the edit, non-automoderated user sees a message "Success: your edit has been sent to moderation. You can continue editing your version of this page". Here the words "your version of this page" are a link to the edit form. Furthermore, if the user is anonymous, this message would suggest "To skip moderation in the future, please sign up".
 * When revisiting the edit form, user sees the following note above the edit form: "You are editing your version of this article. It is currently awaiting moderation". Furthermore, the edit form is populated with the text of pending revision (what this user previously submitted). This allows user to continue editing his version of the page (no need to wait for its approval).
 * If the user is logged in, he can continue editing his version of the text on any computer. Anonymous users are identified by session cookie, and would be recognized in the same computer/browser, but would only be recognized on another computer if said cookies are synchronized between computers.
 * User doesn't receive a notification when the edit is approved. The user can, however, check "was it approved?" in the page history, or in his Watchlist, or (for small wikis) in RecentChanges.
 * Edward Chernenko (talk) 03:25, 16 November 2019 (UTC)

If I can't edit LocalSettings.php, how do I configure it?
I notice unfortunately a few of the settings need to be made in Local_Settings.php. But on some sites that is impossible. If those settings were available in the main interface then the user could change them from the defaults if he wanted to. Jidanni (talk) 03:41, 16 November 2019 (UTC)
 * Ask their administrators, they can add certain LocalSettings.php configs for your wiki. Inability to edit LocalSettings.php is not the extension's problem. Edward Chernenko (talk) 03:45, 16 November 2019 (UTC)
 * (They use a single Local_Settings.php for thousands of wikis. (I just thought is was a historical coincidence that some items could not also be controlled via your "panel". But yes, if they are kept out of being also controllable in the panel for security reasons, then OK, never mind. Else it would be great if users could also control them via the panel.) Jidanni (talk) 03:54, 16 November 2019 (UTC)
 * Again, this is not the extension's problem. Ask their support. They can solve your problem in 5 minutes. What you are suggesting is hours of development, and is not needed for 99,999999% of wikis, and therefore can only be implemented on commercial basis. Edward Chernenko (talk) 04:02, 16 November 2019 (UTC)

How to add a user to moderation group
This looks great extenstion. I have installed and using it now. Right now all moderation goes to only sysop user. How can I add another user or group so they can moderate the posts? I couldn't find it on the extension page. Thanks.
 * You can add the user to the "moderator" group. Edward Chernenko (talk) 14:30, 7 January 2020 (UTC)
 * Thanks. That worked. How long a user's post will be moderated? Is there a limit we can set so new user becomes a good user automatically?
 * Either add the user to "automoderated group" (recommended), or use $wgAutopromote (not recommended, see details). Edward Chernenko (talk) 17:20, 7 January 2020 (UTC)

Marking user spam is not working
Thanks for this extension. It's helping a lot. But I am going through this issue: 1. Mark a user as spammer. 2. confirmation comes that user is marked successfully spammer. 3. When I return to the moderation page, the posts of that user is still there and it's written that 'No longer a spammer'. What should have happened is when I marked a user spammer, all of the posts should have gone to spam automatically. But it's not happening and it's even saying the user is not spammer. I have made many spam users spammers, but I got the same results. What could be fix? Please help. Thanks,


 * 1) Only new edits go to "Spam" ("automatically rejected") folder. There is "Reject all" for already pending edits. 2) Seeing "No longer a spammer" link means that the user is already marked as spammer, and this link can be used for "unblocking" this user. 3) What exactly is happening on your wiki that you are marking tonns of users as spammers? This feature is not against automatic spambots, it only helps with human vandals. Edward Chernenko (talk) 12:22, 10 January 2020 (UTC)


 * thanks for reply. 1. So after marking user the new edits by that user will go to spam directly, right. thanks for clarifying. 2. Now I understood 'no longer a spammer' link. It's basically to make the spam user a good user back. I was just reading it, ignoring the link. 3. I am not getting lots of spam yet, about 10 spam posts a day. I haven't made wiki safe against spambots yet. Our wiki was for years read-only. with your extension I have made it open to users edit and create new posts. If I see lots of spammers only, then I should use the other extensions as you suggested. 4. I still feel that when a user is marked spam, the existing moderating-awaiting posts should also be rejected automatically. Why wait and ask moderator to mark them differently? We have the information, so why not do it automatically?
 * 4. When used properly (not unnecessarily clicking this link for automated spambots, which can easily register 100 new accounts every day), that would save like 3-4 clicks a year. Not worth implementing. Edward Chernenko (talk) 08:36, 11 January 2020 (UTC)

PostgreSQL support?
Do I read correctly that it does not support Postgres? Only MySQL?
 * PostgreSQL is not yet supported. Very few wikis use it with MediaWiki, so it was never a priority. Edward Chernenko (talk) 12:37, 29 January 2020 (UTC)
 * How difficult would it be to add support for PostgreSQL ? This extension would be perfect for my needs, and I've long since kicked MySQL out.
 * Will look into this on Tuesday. It's not difficult to make a schema for PostgreSQL per se, but we use a trick with page_props table (assigning property to nonexistent page) that fails on PostgreSQL due to foreign key constraints (properties for nonexistent pages are not allowed). Will need to design this very carefully to not impact MySQL users. Edward Chernenko (talk) 11:40, 31 January 2020 (UTC)
 * Wonderful. On the foreign keys - if the referencing column is not declared with NOT NULL, Postgres does allow null values as foreign keys.

Implemented in Moderation 1.4.12. Test results: 1) automated testsuite passed for MediaWiki 1.32-1.34 with PostgreSQL, and for 1.31-1.34 with MySQL. 2) It should theoretically work with MediaWiki 1.31 too, but the testsuite itself (which is extremely complex) is not compatible with PostgreSQL+1.31 yet (skipped for now). 3) Tests with Extension:Echo and Extension:CheckUser were skipped, because these extensions themselves are not compatible with PostgreSQL. 4) Test of AbuseFilter was skipped for now, as AbuseFilter conflicts with our testsuite (but not Extension:Moderation itself). Edward Chernenko (talk) 02:02, 5 February 2020 (UTC)


 * Installed from git and so far everything appears to work. Thanks a lot !

Autoapprove IP Address
Is it possible to auto approve edits made by a specific IP address?--76.173.103.102 19:20, 28 August 2020 (UTC)
 * No. Only a registered account can be excluded from moderation. Edward Chernenko (talk) 22:58, 28 August 2020 (UTC)

How to delete unapproved revisions?
Is a potentially danger: some spam bots can do 100500 edits, and despite they will not be approved, they will clog DB. How to prevent it/clear unapproved revisions? Арскригициониец (talk) 01:31, 3 December 2020 (UTC)
 * 1) You should use Extension:AbuseFilter, etc. to reduce the number of spam bots. It's not the purpose of this extension to deal with 100500 bot edits. The purpose of this extension is to deal with human vandals. 2) You can unrecoverably empty the "moderation" table with the following SQL query:  Edward Chernenko (talk) 02:08, 3 December 2020 (UTC)

Disappearing Message Box
On a previous installation on MW 1.34, the message box alerting me to pending edits always stayed visible until all pending edits were processed.

I changed web hosts when I upgraded to MW 1.35. Now, I get the message box alerting me to new pending edits, but it disappears when I navigate around the wiki.

I'm finding that keeping that message box always visible was very helpful, but I can't figure out how to make it act that way. Was there a new setting that was added or some other change?


 * 1) Shouldn't be the case. The only situation in which this message box becomes "hidden" for you is when you visit Special:Moderation. Nothing during the normal page-to-page navigation should cause this. 2) Since you mentioned changing hosts, it may be cache-related misconfiguration or something. When you go to another page and the notice disappears, try adding  to the URL of that other page - will the notice be shown then? Edward Chernenko (talk) 18:58, 5 December 2020 (UTC)


 * Maybe my memory is bad. It appears the message box stays visible whenever you navigate around the wiki, however it does disappear when you visit Special:Moderation, and doesn't come back even when you move away from that page or if more stuff comes into the queue. I thought in the past it keeps showing when you go away from Special:Moderation.  does not make it come back. --72.130.209.247 01:49, 6 December 2020 (UTC).
 * It always worked this way (the box became hidden for those moderators who already visited Special:Moderation after the most recent "pending edit"). There hasn't been any change in this behavior. Edward Chernenko (talk) 03:59, 6 December 2020 (UTC)

Change made by another extension can't get approved.
Moderation Special page says:


 * On click "Approve", i get: Your edit was ignored because no change was made to the text.
 * On click "Approve all", i get: Approved 0 edits. Failed to approve 1 edit: edit conflicts, etc.

The changed page says:

Here's my LocalSettings.php

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; $wgGroupPermissions['sysop']['skip-move-moderation'] = true; $wgAutoConfirmCount = 10;	# AFTER 10 APPROVED EDITS, THE USER WILL NO LONGER BE MODERATED. $wgGroupPermissions['autoconfirmed']['skip-move-moderation'] = false; -Johnywhy (talk) 05:38, 3 February 2021 (UTC)


 * Please check if the page "Template:Extension DPL" 1) already exists in your wiki, 2) has exactly the same text as this change is trying to add (as seen via "diff" link). If that's the case, you can simply Reject this edit (the reason why it can't be approved is because it changes nothing on the page). Edward Chernenko (talk) 01:28, 3 February 2021 (UTC)
 * i'll try that. It seems if nothing got changed, the approval shouldn't get rejected. I don't understand that logic. And... if someone saves a page without changing anything... that will get moderated? -thx
 * -Johnywhy (talk) 05:40, 3 February 2021 (UTC)
 * Update: There seems to be a change. Diff shows the before is blank, and the after contains:
 * This page was automatically created. It serves as an anchor page for all invocations of Extension:DynamicPageList (DPL).
 * -Johnywhy (talk) 07:50, 3 February 2021 (UTC)
 * The page Template:Extension DPL already exists in your wiki, and has exactly the same text as this change is trying to add. Edward Chernenko (talk) 09:11, 3 February 2021 (UTC)
 * Where are you seeing it has exactly the same text? Diff shows the before is blank, and the after contains:
 * Johnywhy (talk) 19:00, 6 February 2021 (UTC)
 * https://imgur.com/KXduFXz Johnywhy (talk) 19:03, 6 February 2021 (UTC)
 * Please re-read my message again. Moderation behaves 100% as expected in this situation, and I won't be explaining "why" for the third time. Edward Chernenko (talk) 20:01, 6 February 2021 (UTC)
 * Please re-read my message again. Moderation behaves 100% as expected in this situation, and I won't be explaining "why" for the third time. Edward Chernenko (talk) 20:01, 6 February 2021 (UTC)

Adding Link to Article on Approved Page
I'm finding myself needing to make further modifications to articles after approving edits. Currently, after approving an edit, the extension shows a page that says "Approved 1 edit. Return to Special:Moderation." with the Special:Moderation being a link. After approving the edit I go to Recent changes and then the article to make further edits. It would be very useful if the approval page also included a link to the corresponding article.

Is that a feature that could be added?

--68.229.117.46 22:53, 28 April 2021 (UTC)
 * Good idea, will be added. Edward Chernenko (talk) 00:08, 29 April 2021 (UTC)

Bug: Moderated changes cannot be patrolled
This is a bug I have noticed across two wikis, the one I have on Miraheze and the brand new one I installed myself. Once you accept a revision on special:moderation, it cannot be patrolled. Heck, why isn't that automatically patrolled anyway? MarioSuperstar77 (talk) 11:54, 22 May 2021 (UTC)
 * 1) Moderation doesn't change anything related to patrolling. 2) If you want moderator-approved edits to automatically be marked as patrolled (but still require manual patrolling for edits by "automoderated" users), you can use the following configuration:  Edward Chernenko (talk) 12:56, 22 May 2021 (UTC)

Special:Moderation to not offer confirmation
The Special:Moderation page works well but is really time consuming. You have to click on an action, see a new page confirming the action, then click back to the Special:Moderation page. With all the mouse movements as well this is wasteful if you are moderating a lot of entries.

Could there be an option or an alternate Special:Moderation page where you click on an action and the page is refreshed ready for clicking another action? No wasteful page displays, click etc Peter
 * Two options already exist: 1) enable  (experimental), 2) It's convenient to click on links like Approve with a mouse wheel to open them in new background tab. You can click on 20 links quickly and then just close those tabs. Edward Chernenko (talk) 11:01, 11 October 2021 (UTC)
 * Superb $wgModerationUseAjax = true; is exactly what I needed thank you

Special:Moderation to offer Mark As Spammer and Reject All
This might be a use case just for me but 99.99% of all the moderation is to be set as Mark As Spammer and Reject All. Could the Special:Moderation page provide a function that sets all the entries to Mark As Spammer and Reject All?
 * If you are clicking "Mark as spammer" link more than 4-5 times a year, you are using it wrong. It's not meant to be used against automated spambots. See https://github.com/edwardspec/mediawiki-moderation/issues/16 for details. Edward Chernenko (talk) 17:10, 30 January 2022 (UTC)


 * I get your point - but I use AbuseFilter and it's a whole additional maintenance task and I still want to check if there are any false negatives/positives. Far easier to check the Moderation page once a week, scan through and then be able to reject the lot :-)     Mycarebudget (talk) 08:24, 10 February 2022 (UTC)
 * In reply to my reply - I was 100% WRONG. Set up the simplest of AbuseFilters and it's capturing just about every autospammer out there based on Link Spamming. You were right, I was wrong :-) Mycarebudget (talk) 12:57, 11 February 2022 (UTC)

Database Tables not created in MW 1.35 for master branch (1.5.36) of this extension
First of all, this is now my favorite extension. It has made a huge difference in stopping the tidal wave of spam and saved me a lot of time. Thank you!

Here's a bug I found in the current master branch (1.5.36): I tried to install the extension into my install of Mediawiki 1.35.5. When I ran the update.php script, I received an error that the Moderator database table(s) were not present (unfortunately I didn't save the exact text of the error notice). It appears that they weren't created by the update script.

Next, I tried to install the Rel1_31 branch in a Mediawiki 1.33 install, and the update script worked, properly creating the required database tables. The extension worked perfectly in that installation. I was then able to upgrade to MW 1.35.5 and since the tables were already present, running the update script did not produce any errors, and the extension is working properly now.

In short, there is a bug in the setup/database creation functions in the current master branch (1.5.36).