Extension talk:Moderation

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: 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)

Request for on wiki notification
Please could moderators get immediate notifications on wiki? That is some sort of message appearing at the top of whichever page they're looking at saying "new edits requiring moderation". --Rob Kam (talk) 08:38, 25 November 2017 (UTC)
 * Good idea, will implement this. Edward Chernenko (talk) 09:02, 25 November 2017 (UTC)
 * Implemented in 1.1.14. Edward Chernenko (talk) 13:56, 24 January 2018 (UTC)

Edward Chernenko, with extension Echo this notification stops showing --Saew12 (talk) 23:16, 15 November 2018 (UTC)
 * Indeed. I'll investigate how to fix it. (the cause is that Extension:Echo removes "You have new messages" box, and Moderation uses this box) Edward Chernenko (talk) 23:32, 15 November 2018 (UTC)
 * Fixed in 1.3.24. Edward Chernenko (talk) 14:25, 28 November 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)

Feature request: view-only access
For the purpose of transparency, could a moderation view-only user right be added? I request this to allow users to view the moderation logs, and to view (but not approve/reject) intercepted edits at Special:Moderation. It is a right that we would like to give to all registered users on our wiki, because there does not seem to be any danger in allowing everyone to have view only access.

In addition, could this view only right allow someone who is editing a page with pending edits to see those pending edits, to prevent edit conflicts? In a perfect world, we would have enough moderators to quickly approve all edits, but we don't, and on our wiki people are very likely to heavily edit the same content, and we do not want to give automoderated status to everyone. People who are editing a page with pending edits deserve to see any pending edits from non-automoderated users, to know if their own effort would be wasted. Extension:Moderation could be like the other review extensions in allowing editors to see pending edits, but while still keeping the Extension:Moderation benefits of those edits not being in the recent changes, and not being saved to the page's history until approved. 73.118.51.32 01:03, 12 August 2018 (UTC)

I noticed that in the documentation the question "Can other editors improve non-approved edits?" is answered with "No". It this an intentional design decision, or a fixable shortcoming? It would be sufficient to hide potential vandalism edits from everyone except someone who is editing the page in question (and has the moderation view only right), is that agreeable? 73.118.51.32 01:21, 12 August 2018 (UTC)
 * This is an intentional design decision. Moderation is not a review extension and such use is neither recommended nor endorsed. You should use FlaggedRevs or something if you want pending edits to be public and non-malicious users to remain non-automoderated for long periods of time. Edward Chernenko (talk) 08:08, 12 August 2018 (UTC)
 * Btw, if "people are very likely to heavily edit the same content" on your wiki, then it's very inconvenient to delay making them automoderated: the moderator would often have to resolve edit conflicts when approving their edits, which would otherwise be done by the users themselves. Edward Chernenko (talk) 08:12, 12 August 2018 (UTC)
 * Thank you for the reply. I understand now that auto moderated should not be delayed. 73.118.51.32 13:19, 12 August 2018 (UTC)

Feature request: not to click twice
After every new serie of spam, I need to click both "mark as spammer" and "reject all" for every spam message. Please invent something to reduce the number of clicks I need two times. --VictorPorton (talk) 18:10, 28 September 2018 (UTC)
 * You shouldn't click "mark as spammer" at all. This is a feature against human vandals, not automatic spambots. See https://github.com/edwardspec/mediawiki-moderation/issues/16 for details. Edward Chernenko (talk) 18:23, 28 September 2018 (UTC)

git releases
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)

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)

404 or 403 error
Hi Ed, I get a 404 or a 403 error if a user tries to edit a page that has gone to moderation. I'm running 1.30 wiki on my testing server and I've upgraded to 1.3.26 on my testing server from 1.1.18. I also tried 1.3.0. I did run update.php. seems to work just the same, but my user gets a 404 or a 403 when they attempt to edit a page that has gone to moderation.
 * 1) Anything in the webserver logs? 2) can you edit a nonexistent page on your wiki by navigating to ? Edward Chernenko (talk) 15:21, 31 January 2019 (UTC)
 * I get a HTTP 200 when I try to create a new page.TespSam (talk) 15:54, 1 February 2019 (UTC)
 * 1) Please let me know the following URLs (without the domain name, e.g. '/wiki/Something?action=edit'): (a) URL that shows 404/403, (b) URL of the normal edit form (when you try to create a new page), (c) URL of any existing page. 2) does your wiki use Extension:PageForms? 3) Please also check error_log of the webserver: 403 and 404 errors are sent by webserver (not MediaWiki), so its logs will have the exact reason. Edward Chernenko (talk) 00:38, 2 February 2019 (UTC)
 * The 404 looks like
 * 2019-02-28 21:50:24 ipAddress GET /api.php ... 443 - ipAddress Mozilla/5.0+(Windows+NT+6.1;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/72.0.3626.119+Safari/537.36 https://website.com/index.php?title=Test2&veaction=edit 404 15 0 0
 * Edit a moderated page: /index.php?title=Test2&veaction=edit
 * Edit an unmoderated page: /index.php?title=Test2&veaction=edit
 * Edit a new page by following a redlink: /index.php?title=Test2&action=edit&redlink=1
 * TespSam (talk) 22:09, 28 February 2019 (UTC)
 * I've upgraded the wiki to 1.31.1, and visual editor to the 11/2018 version. Still getting the errors.  I got a second test user to inspect while editing an article that was in moderation and it said:
 * Moderation: not preloading: no pending change found
 * It let the second user make edits to the (unmodified) page and then both changes were in moderation.TespSam (talk) 17:14, 1 March 2019 (UTC)
 * Ok, this thing with the second user is a correct behavior: Moderation hides not-yet-approved change of user A from user B. User B can only see a pending edit made by user B (if B made such an edit). Message "no pending change found" appears if current user (in this case, B) doesn't have a pending change. Edward Chernenko (talk) 17:41, 1 March 2019 (UTC)

I tested this (Chrome, Firefox): non-automoderated user A creates a page in VisualEditor, then opens "your version of the page" link. The edit form that opens does indeed have HTTP code 404 (same as when you start editing a non-existent page - because, well, the page doesn't exist until Approved), but everything else works: user A can see the text of pending edit (and can continue editing it), because it's substituted into the form when VisualEditor initializes. Edward Chernenko (talk) 02:18, 2 March 2019 (UTC)

Also I didn't get HTTP 404 from api.php (all requests to api.php were HTTP 200). Could you please check what this failed API request was by opening F12 ("Network" tab) in your browser before the test? (find the request that has HTTP 404 and "api.php" in its URL, its Response and Headers may contain more information on what went wrong). Edward Chernenko (talk) 02:28, 2 March 2019 (UTC)