Extension talk:Moderation

From mediawiki.org
Latest comment: 23 days ago by WikiForMen in topic This extension is very good

How to download without Git[edit]

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)Reply[reply]

Here is a direct link: https://github.com/edwardspec/mediawiki-moderation/archive/master.zip

Existing users moderated?[edit]

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)Reply[reply]

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
$wgAutoConfirmCount = 10;
$wgGroupPermissions['autoconfirmed'] = 'skip-moderation';
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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]

Exclude Namespaces[edit]

Is it possible to exclude several namespaces from the extension? — Preceding unsigned comment added by 2003:73:ce61:d200:1551:696d:401f:1b90 (talkcontribs)

Implemented in 1.1.20. Edward Chernenko (talk) 18:16, 25 March 2018 (UTC)Reply[reply]

This extension is very good[edit]

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)Reply[reply]

I just tested it on a test wiki on MW 1.39-alpha, and I was positively impressed! No bugs, easy to install, well-documented, congrats Edward Chernenko! Given it was only a test, I cannot say like JLJ001| it helped in real counter-vandalism, but the scenario described seems promising – when communities want a priori moderation, which is a strong policy for a wiki, but it’s up to communities to decide. ~ Seb35 [^_^] 19:50, 22 June 2022 (UTC)Reply[reply]

This extension is actually good. But to stop the automated creation of spam accounts, I additionally use the Extension QuestyCaptcha.--WikiForMen (talk) 13:15, 4 February 2024 (UTC)Reply[reply]

Is Moderation meant to replace patrolling?[edit]

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? 00:27, 9 August 2018 (UTC)Reply[reply]

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)Reply[reply]

git releases like REL1_27[edit]

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 -- 20:33, 20 January 2019 (UTC)Reply[reply]

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)Reply[reply]
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)Reply[reply]

How do i use $wgModerationEmail?[edit]

$wgModerationEmail Is mentioned in the "Documentation" but I can't find any other mention on how to use it. — Preceding unsigned comment added by (talkcontribs)

$wgModerationEmail = 'will.be.sent.to.this.address@example.com';. Edward Chernenko (talk) 01:44, 22 January 2019 (UTC)Reply[reply]

Bypass Moderation for Individual Pages?[edit]

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? — Preceding unsigned comment added by (talkcontribs)

Place them into a separate namespace (e.g. Document:Name of page) and use $wgModerationIgnoredInNamespaces = [ number_of_this_namespace ] in LocalSettings.php. Edward Chernenko (talk) 11:34, 24 January 2019 (UTC)Reply[reply]

Exclude File Uploads from Moderation?[edit]

Is it possible to exclude file uploads from Moderation? — Preceding unsigned comment added by (talkcontribs)

Yes, add NS_FILE to $wgModerationIgnoredInNamespaces array. Edward Chernenko (talk) 16:00, 24 January 2019 (UTC)Reply[reply]

Hooks when a moderator approves an edit?[edit]

Are there hooks I can tap onto when a mod/sysop approves an edit? — Preceding unsigned comment added by 2001:f40:909:fd6b:103b:f124:6499:8fb3 (talkcontribs)

You can use PageContentSaveComplete hook. Edward Chernenko (talk) 18:25, 18 October 2019 (UTC)Reply[reply]

Question: what does a non-automoderated user see/know when editing?[edit]

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.

  • 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?

Also mention what if he wants to change, or withdraw entirely, his edit while it is still in the queue:

  • Now, or
  • Later, from a different computer.

Jidanni (talk) 00:05, 16 November 2019 (UTC)Reply[reply]

  1. 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".
  2. 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).
  3. 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.
  4. 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)Reply[reply]

If I can't edit LocalSettings.php, how do I configure it?[edit]

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)Reply[reply]

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)Reply[reply]
(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)Reply[reply]
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)Reply[reply]

How to add a user to moderation group[edit]

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)Reply[reply]
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)Reply[reply]

Marking user spam is not working[edit]

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, — Preceding unsigned comment added by 2409:4043:487:2be7:9cc7:fd25:ba28:fb14 (talkcontribs)

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)Reply[reply]
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)Reply[reply]

PostgreSQL support?[edit]

Do I read correctly that it does not support Postgres? Only MySQL? — Preceding unsigned comment added by (talkcontribs)

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)Reply[reply]
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. — Preceding unsigned comment added by (talkcontribs)
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)Reply[reply]
Wonderful. On the foreign keys - if the referencing column is not declared with NOT NULL, Postgres does allow null values as foreign keys. — Preceding unsigned comment added by (talkcontribs)

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)Reply[reply]

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

Autoapprove IP Address[edit]

Is it possible to auto approve edits made by a specific IP address?-- 19:20, 28 August 2020 (UTC)Reply[reply]

No. Only a registered account can be excluded from moderation. Edward Chernenko (talk) 22:58, 28 August 2020 (UTC)Reply[reply]

How to delete unapproved revisions?[edit]

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)Reply[reply]

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: DELETE FROM moderation WHERE mod_rejected=1; Edward Chernenko (talk) 02:08, 3 December 2020 (UTC)Reply[reply]

Disappearing Message Box[edit]

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? — Preceding unsigned comment added by (talkcontribs)

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 ?action=purge to the URL of that other page - will the notice be shown then? Edward Chernenko (talk) 18:58, 5 December 2020 (UTC)Reply[reply]
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. ?action=purge does not make it come back. -- 01:49, 6 December 2020 (UTC).Reply[reply]
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)Reply[reply]

Change made by another extension can't get approved.[edit]

Moderation Special page says:

(diff) . . bN Template:Extension DPL 04:07 . . +253‎ . .[?] (Template:Extension DPL) [Approve Approve all . . Reject Reject all] . . [Mark as spammer]

  • 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: This page was automatically created. It serves as an anchor page for all invocations of Extension:DynamicPageList (DPL).

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;
$wgGroupPermissions['autoconfirmed']['skip-move-moderation'] = false;

-Johnywhy (talk) 05:38, 3 February 2021 (UTC)Reply[reply]

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)Reply[reply]
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)Reply[reply]
Update: There seems to be a change. Diff shows the before is blank, and the after contains:
<noinclude>This page was automatically created.  It serves as an anchor page for all '''[[Special:WhatLinksHere/Template:Extension_DPL|invocations]]''' of [http://mediawiki.org/wiki/Extension:DynamicPageList Extension:DynamicPageList (DPL)].</noinclude>
-Johnywhy (talk) 07:50, 3 February 2021 (UTC)Reply[reply]
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)Reply[reply]
Where are you seeing it has exactly the same text? Diff shows the before is blank, and the after contains:
This page was... Johnywhy (talk) 19:00, 6 February 2021 (UTC)Reply[reply]
https://imgur.com/KXduFXz Johnywhy (talk) 19:03, 6 February 2021 (UTC)Reply[reply]
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)Reply[reply]

Adding Link to Article on Approved Page[edit]

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?

-- 22:53, 28 April 2021 (UTC)Reply[reply]

Good idea, will be added. Edward Chernenko (talk) 00:08, 29 April 2021 (UTC)Reply[reply]

Bug: Moderated changes cannot be patrolled[edit]

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)Reply[reply]

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:
$wgGroupPermissions['*']['autopatrol'] = true;
$wgRevokePermissions['automoderated']['autopatrol'] = true;
Edward Chernenko (talk) 12:56, 22 May 2021 (UTC)Reply[reply]

Special:Moderation to not offer confirmation[edit]

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 $wgModerationUseAjax = true; (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)Reply[reply]
Superb $wgModerationUseAjax = true; is exactly what I needed thank you — Preceding unsigned comment added by Mycarebudget (talkcontribs)

Special:Moderation to offer Mark As Spammer and Reject All[edit]

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? — Preceding unsigned comment added by Mycarebudget (talkcontribs)

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Database Tables not created in MW 1.35 for master branch (1.5.36) of this extension[edit]

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). — Preceding unsigned comment added by Lost Student (talkcontribs)

Master branch version is 1.6.19, which supports MediaWiki 1.35-1.37. 1.5.36 is an old release. Edward Chernenko (talk) 21:34, 22 February 2022 (UTC)Reply[reply]
I must have mistakenly downloaded the wrong version then. Just for fun I just downloaded from https://github.com/edwardspec/mediawiki-moderation.git and put into a fresh MW install (1.37.1 this time). It worked fine--so I guess there's no bug. Thanks again for a fantastic extension!--Lost Student (talk) 22:41, 22 February 2022 (UTC)Reply[reply]
Getting this in v1.35.2 with fresh checkout of master branch as well. Will try checking out specific tagged versions Sneakers-the-rat (talk) 22:34, 8 May 2022 (UTC)Reply[reply]
Master branch of Moderation works with MediaWiki 1.35. Look at the output of update.php script when you run it: if there were any errors when creating the table, they will be there. Edward Chernenko (talk) 22:38, 8 May 2022 (UTC)Reply[reply]

Working with other extensions (SpamBlacklist & autoconfirm)[edit]

Before I stared using this extension, I prevented some unwanted edits and page creations by using the SpamBlacklist Extension. I was somewhat successful in keeping spam pages out of main namespace articles. I had an extensive blacklist, and a whitelist with many domains that were appropriate for the subject matter of my wiki. However, I was still getting a lot of spam (in a lot of cases they used redirects to avoid my blacklist) and the idea of the Moderation extension, and the ability to make spam never appear, really appealed to me. Unfortunately with this extension, spammers have tried to create thousands of pages over a couple of days, which makes my job of moderating very difficult. I noticed that most of these spam pages include links that the spam blacklist would prevent (if it were functional).

It's pretty easy to identify spam from only the page titles, so while it is a chore, I am able to go through each one and reject. However, if this extension ran after Spam Blacklist already had a chance to reject edits, it would save me a ton of work. Is that possible?

I also found that spammers have been creating a lot of user talk pages, which I cannot identify as spam from the title alone. This necessitates that I click on each one from the Moderation page before rejecting. So I wanted to make it so only autoconfirmed editors could create a talk page. But it appears that the autoconfirm rules do not run before an edit is added to the moderation list. Just like with Spam Blacklist, is it possible to check the autoconfirm rules before an edit is added to the moderation list?

Thanks!--Lost Student (talk) 05:51, 1 March 2022 (UTC)Reply[reply]

Moderation runs after checks of extensions like AbuseFilter, etc. No special action is required. Edward Chernenko (talk) 10:10, 1 March 2022 (UTC)Reply[reply]
Thanks, I haven't tried using AbuseFilter with Moderation yet. I'll play around with its rules. That would be nice to limit some of the deluge of spambots I'm getting. My current moderation queue is at 3,222 items(!) and I've already done a few hundred rejections.
I have a feeling that SpamBlacklist and Moderation don't play nice together but I'm not quite sure--something was causing issues when they were both active. I'll do some more testing to see if I can replicate. Lost Student (talk) 17:45, 1 March 2022 (UTC)Reply[reply]

How is the Token Parameter Calculated?[edit]

I'm trying to make a script that interfaces with edits that are awaiting moderation to allow some of the edits to be automatically approved or rejected based on certain parameters.

I have it mostly worked out, except for the token parameter in the urls to approve or reject the edits. Like this one: index.php?title=Special:Moderation&modaction=approve&modid=8476&token=c4e1897b58b55a38445d4ca572a1d39c6233635f%2B%5C

Is there a way I can generate or get valid tokens? And if not, is there a part of the extension I can disable that verifies the tokens? I image disabling wouldn't be ideal but it is being used on a private wiki where security is not an issue. (Page edits are made from feed streams and require moderation which is why I use this extension.) 16:52, 17 March 2022 (UTC)Reply[reply]

See Manual:Edit token. Edward Chernenko (talk) 17:02, 17 March 2022 (UTC)Reply[reply]

Can Moderation moderate the Discussion forum?[edit]

So before a question or response is submitted to the discussion tab/page, it will have to go to the Moderation first? 19:27, 28 March 2022 (UTC)Reply[reply]

Correct. You can exclude talkpages from being moderated by setting $wgModerationIgnoredInNamespaces, for example: $wgModerationIgnoredInNamespaces = [ NS_TALK, NS_USER_TALK ]; Edward Chernenko (talk) 19:58, 28 March 2022 (UTC)Reply[reply]

Feature suggestion to mitigate incorrect use: "revert" shortcut[edit]

Undesirable but well-intended edits (e.g. excessive trivia) are sometimes incorrectly rejected out of intuition and laziness rather than approved for a record in the page history and then reverted. I suggest adding a "revert" button next to "reject", which approves the edit and reverts it with an entered summary in one step. –Anerisys (talk) 19:51, 8 May 2022 (UTC)Reply[reply]

This is a good idea (and was requested before), will likely implement this at some point. Edward Chernenko (talk) 22:42, 8 May 2022 (UTC)Reply[reply]

Possible to send notification (ie. email) to moderated users upon approval?[edit]

We are happy users of this extension to maintain our wiki's quality control, but some users have requested a notification once their edits have been approved. Is this possible with the extension? 16:57, 9 May 2022 (UTC)Reply[reply]

Moderation itself doesn't send such notifications, because 99% of wikis don't need it (when Moderation is not used for review, edits are approved fairly quickly, and users are never wondering "when will my edits finally be approved?"). However, you can implement such notification yourself (e.g. in PageSaveComplete hook). Edward Chernenko (talk) 18:29, 9 May 2022 (UTC)Reply[reply]
Is PageSaveComplete executed on every save by the moderated user, or only after a moderator approves all edits to a page? 19:01, 10 May 2022 (UTC)Reply[reply]
It is not executed on every save (when the edit is intercepted by Moderation), only on approval. It also runs when admin/automoderated saves an edit that bypassed Moderation, so you would need to filter out those cases before you send your notification. Edward Chernenko (talk) 19:38, 10 May 2022 (UTC)Reply[reply]

Moderation notification emails triggering block on Yahoo[edit]

It seems Yahoo Mail really doesn't like the moderation notification emails. It starts blocking after so many and never seems to lift the block. Emails bounce and I get "421 4.7.0 [TSS04] Messages from <ip address> temporarily deferred due to unexpected volume or user complaints -" and still blocking after a week. This is particularly a problem if a user makes many edits in a short space of time. I have had 3 different IP addresses blocked so far because of this. There needs to be an option to limit how many are sent at a time. 11:32, 28 August 2022 (UTC)Reply[reply]

There is not much we can do about it (even if 1 user doesn't edit many times, there may be multiple users who would do 1 edit within the short period of time). Direct these emails to your own mailserver (rather than to Yahoo) or don't use this feature at all. Edward Chernenko (talk) 11:38, 28 August 2022 (UTC)Reply[reply]
One possible idea is to send an hourly digest "what new edits have appeared in the moderation queue in the last hour?" (instead of mailing after every edit). I don't plan to implement this feature myself, but feel free to submit a pull request. Edward Chernenko (talk) 11:41, 28 August 2022 (UTC)Reply[reply]

[Fix] Image Upload Issue after Upgrade[edit]

I had upgraded one of my wikis to a newer MediaWiki version and ran into an issues where users would get this exception when uploading files:

Special:Upload MWE Exception from line 64 of /var/www/mediawiki/extensions/Moderation/lib/ModerationUploadStorage.php: ModerationUploadStorage::getOwner: unable to create user.


  1. 0 /var/www/mediawiki/extensions/Moderation/lib/consequence/QueueUploadConsequence.php(67): ModerationUploadStorage::getOwner()
  2. 1 /var/www/mediawiki/extensions/Moderation/lib/consequence/manager/ConsequenceManager.php(27): MediaWiki\Moderation\QueueUploadConsequence->run()
  3. 2 /var/www/mediawiki/extensions/Moderation/hooks/ModerationUploadHooks.php(79): MediaWiki\Moderation\ConsequenceManager->add()
  4. 3 /var/www/mediawiki/includes/HookContainer/HookContainer.php(155): ModerationUploadHooks->onUploadVerifyUpload()
  5. 4 /var/www/mediawiki/includes/HookContainer/HookRunner.php(4198): MediaWiki\HookContainer\HookContainer->run()
  6. 5 /var/www/mediawiki/includes/upload/UploadBase.php(935): MediaWiki\HookContainer\HookRunner->onUploadVerifyUpload()
  7. 6 /var/www/mediawiki/includes/specials/SpecialUpload.php(579): UploadBase->performUpload()
  8. 7 /var/www/mediawiki/includes/specials/SpecialUpload.php(214): SpecialUpload->processUpload()
  9. 8 /var/www/mediawiki/includes/specialpage/SpecialPage.php(600): SpecialUpload->execute()
  10. 9 /var/www/mediawiki/includes/specialpage/SpecialPageFactory.php(635): SpecialPage->run()
  11. 10 /var/www/mediawiki/includes/MediaWiki.php(307): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
  12. 11 /var/www/mediawiki/includes/MediaWiki.php(947): MediaWiki->performRequest()
  13. 12 /var/www/mediawiki/includes/MediaWiki.php(547): MediaWiki->main()
  14. 13 /var/www/mediawiki/index.php(53): MediaWiki->run()
  15. 14 /var/www/mediawiki/index.php(46): wfIndexMain()
  16. 15 {main}


  1. Run php maintenance/cleanupUsersWithNoId.php -prefix '*' (may say already complete)
  2. Run php maintenance/migrateActors.php

Figured I'd save someone some time since it took me a while to narrow down that the "ModerationUploadStash" actor did not exist in the actor table, and this fixes it. Derf Jagged (talk) 16:58, 4 June 2023 (UTC)Reply[reply]

Yes, this is a correct way to fix it. This problem is not related to Moderation itself (other extensions can be affected by this too), it's a one-time issue with actor migration (it should have been done automatically during MediaWiki upgrade). Edward Chernenko (talk) 20:07, 4 June 2023 (UTC)Reply[reply]

[Feature Request] Option to ignore null edits[edit]

Very frequently, people open the editor and click "submit" to exit, resulting in "null edits" which can only be rejected. It'd be nice if these null edits were just outright blocked or for there be a variable to set to ignore these edits since the only option moderators have is to reject it. Derf Jagged (talk) 13:20, 20 July 2023 (UTC)Reply[reply]

Won't be implemented. Please see the file WONT_DO for why this idea was rejected in the past. Edward Chernenko (talk) 15:53, 20 July 2023 (UTC)Reply[reply]
Wouldn't the ideal solution be to reject null edits that also do not have an edit summary? Derf Jagged (talk) 19:15, 20 July 2023 (UTC)Reply[reply]
I don't want to implement this. There are various problems: edit might not have been a null edit at the moment when it was made, MediaWiki doesn't inform us that this is a null edit (we'd have to check the current text of the article with a separate SQL query), and it will complicate the tests. If you can implement this and cover this with tests, feel free to send a pull request. Edward Chernenko (talk) 22:52, 20 July 2023 (UTC)Reply[reply]

filter by categories[edit]

I'm trying to create a filter for pages pending moderation (because I'd like to organize the pages according to their category, for moderators to approve or not), but I'm facing a problem. If the page is not saved until the moderator approves it, how would I know what category the pending page belongs to? 00:18, 29 July 2023 (UTC)Reply[reply]

You can use Extension:AbuseFilter (which runs before Moderation intercepts the edit) to tag the edits (e.g. add category-cats to edits that have "Category:Cats" in their text), and then use mod_tags field. Edward Chernenko (talk) 04:43, 29 July 2023 (UTC)Reply[reply]
In that case, I would have to do this for each category, right? 20:00, 29 July 2023 (UTC)Reply[reply]
Yes. If there are too many categories (and you don't want to have 50 filters), alternative is to use ModerationPending hook, where you can analyze mod_text and set mod_tags (via a separate UPDATE query) as needed. Edward Chernenko (talk) 20:27, 29 July 2023 (UTC)Reply[reply]
Thanks so much Edward ^^ I managed to implement this feature this way 04:32, 31 July 2023 (UTC)Reply[reply]

Machine Learning[edit]

I love this extension and have used it in all my wikis. I'd like to recommend a minor modification to store (in a database table) each edit's previous text, it's modified text, the action taken (such as if the edit was approved or rejected), and other information like the page name, namespace, and account or IP address. This would allow users to export manually created data sets to train machine learning algorithms that they could later use in a bot that approves, rejects, or take no action on future edits.

For my use, I use the Page Forms extension so all legitimate edits have very specific characteristics. As I'm spending time manually approving or rejecting edits, I couldn't help but think that if I was able to record this data I'd be able to train a bot that could automatically reject a large percentage of malicious edits. 22:34, 29 July 2023 (UTC)Reply[reply]

All this information is already recorded in logs and other database tables. Please obtain it from there. Edward Chernenko (talk) 00:29, 30 July 2023 (UTC)Reply[reply]

Add user group to moderation notifications?[edit]

I know there are options to send to a single email for moderation notifications with $wgModerationNotificationEnable = true; and $wgModerationEmail = 'send.to.this.address@example.com'; - can this be set so that a usergroup of moderators all get the notification?

For example ConfirmAccount has a confirmaccount-notify permission that can be enabled to achieve this.

Thanks! MikesaundersNLS (talk) 15:18, 11 December 2023 (UTC)Reply[reply]

There is no such feature, and there is no plan to implement this. Edward Chernenko (talk) 15:53, 11 December 2023 (UTC)Reply[reply]
Thanks for the quick reply - is that because it's not something that seems helpful or because there are other ways to do it? I'm just thinking about a small wiki where the moderators will not necessarily check frequently. MikesaundersNLS (talk) 10:10, 12 December 2023 (UTC)Reply[reply]
It's a good idea to avoid sending too many emails directly from the webserver: this can trigger rate limits of receiving mail servers, etc. What you can do instead is receive only 1 letter, but use a forwarding function (services like Gmail have it) to re-transmit that received letter to other addresses. Edward Chernenko (talk) 10:27, 12 December 2023 (UTC)Reply[reply]
Ok yes that was going to be my work around. Thanks again! MikesaundersNLS (talk) 10:29, 12 December 2023 (UTC)Reply[reply]

Documentation style[edit]

Starting #, #;, ;, : and * should not be included in translation tags. WikiForMen (talk) 14:39, 30 January 2024 (UTC)Reply[reply]

For the record, if I keep receiving this many pointless notification emails about "translation markup was slightly modified" edits, I will unwatch this page, and you can answer the legitimate questions about the extension yourself. Edward Chernenko (talk) 16:17, 31 January 2024 (UTC)Reply[reply]