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)

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

Local_Settings.php dependecies
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)