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. — Preceding unsigned comment added by VictorPorton (talk • contribs)

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 $wgModerationNotificationEnable, $wgModerationNotificationNewOnly and $wgModerationEmail 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. — Preceding unsigned comment added by VictorPorton (talk • contribs)

There is a misunderstanding here.

1. "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.
2. "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.
3. 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. — Preceding unsigned comment added by VictorPorton (talk • contribs)

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)

1. "Approve button on pending diff page" - good idea, will do this shortly.
2. "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).
3. "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.
4. "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 php5 ../web/w/maintenance/edit.php Title (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. — Preceding unsigned comment added by VictorPorton (talk • contribs)

Hello, you can easily fix this:

1. Method 1: you can use edit.php like this: maintenance/edit.php Title --user NameOfUser - where NameOfUser is an account who has automoderated flag.
2. Method 2: add the following to LocalSettings.php: if (PHP_SAPI == "cli") { $wgModerationEnable = false; }

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 — Preceding unsigned comment added by Atef81 (talk • contribs)

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. — Preceding unsigned comment added by Atef81 (talk • contribs)

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. — Preceding unsigned comment added by Atef81 (talk • contribs)

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:

$wgGroupPermissions['user']['move'] = false;
$wgGroupPermissions['sysop']['move'] = true;

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

$wgGroupPermissions['automoderated']['skip-moderation'] = true;

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

$wgGrantPermissions['basic']['skip-moderation'] = true;

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)

1. It would be too difficult to merge Special:Moderation into RecentChanges.
2. 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.
3. 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

   $wgGroupPermissions['*']['autopatrol'] = true;
   $wgRevokePermissions['automoderated']['autopatrol'] = true;
   

4. 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.
5. Rejected edits can be only approved for $wgModerationTimeToOverrideRejection seconds (default: 2 weeks).
6. If you are one of those "let's save 640 kilobytes of disk space" administrators, just delete them from the database. DELETE FROM moderation WHERE mod_rejected=1;. 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)

1. Got it.
2. —
3. 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.)
4. I wasn't aware of that.
5. —
6. 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:

2017-12-30 03:04:27 8ee5cb28068e wikidb: [a43bbb2c989f4750df410ced] /index.php?title=The_Independent_Institute&action=formedit   Wikimedia\Rdbms\DBUnexpectedError from line 2767 of /var/www/includes/libs/rdbms/database/Database.php: Wikimedia\Rdbms\Database::commit: Got COMMIT while atomic sections WikiPage::doModify are still open.
#0 /var/www/extensions/Moderation/hooks/ModerationEditHooks.php(160): Wikimedia\Rdbms\Database->commit()
#1 /var/www/includes/Hooks.php(186): ModerationEditHooks::onPageContentSave(WikiPage, User, WikitextContent, string, integer, NULL, NULL, integer, Status)
#2 /var/www/includes/page/WikiPage.php(1570): Hooks::run(string, array)
#3 /var/www/extensions/AutoCreateCategoryPages/AutoCreateCategoryPages.body.php(73): WikiPage->doEditContent(WikitextContent, string, integer, boolean, User)
#4 /var/www/includes/Hooks.php(186): AutoCreateCategoryPages::onPageContentSaveComplete(WikiPage, User, WikitextContent, string, integer, NULL, NULL, integer, Revision, Status, boolean, integer)
#5 /var/www/includes/page/WikiPage.php(1798): Hooks::run(string, array)
#6 [internal function]: WikiPage->{closure}(Wikimedia\Rdbms\DatabaseMysqli, string)
#7 /var/www/includes/libs/rdbms/database/Database.php(2693): call_user_func_array(Closure, array)
#8 /var/www/includes/deferred/AtomicSectionUpdate.php(35): Wikimedia\Rdbms\Database->doAtomicSection(string, Closure)
#9 /var/www/includes/deferred/DeferredUpdates.php(257): AtomicSectionUpdate->doUpdate()
#10 /var/www/includes/deferred/DeferredUpdates.php(210): DeferredUpdates::runUpdate(AtomicSectionUpdate, Wikimedia\Rdbms\LBFactorySimple, string, integer)
#11 /var/www/includes/deferred/DeferredUpdates.php(127): DeferredUpdates::execute(array, string, integer)
#12 /var/www/includes/MediaWiki.php(603): DeferredUpdates::doUpdates(string, integer)
#13 /var/www/includes/MediaWiki.php(572): MediaWiki::preOutputCommit(RequestContext, Closure)
#14 /var/www/includes/MediaWiki.php(878): MediaWiki->doPreOutputCommit(Closure)
#15 /var/www/includes/MediaWiki.php(523): MediaWiki->main()
#16 /var/www/index.php(43): MediaWiki->run()
#17 {main}

If I had to guess, I'd say probably AutoCreateCategoryPages extension is being moderated? — Preceding unsigned comment added by CalNation (talk • contribs)

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;
# $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: $wgGroupPermissions['autoconfirmed']['skip-moderation'] = true;. 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)

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)

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)

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. — Preceding unsigned comment added by TespSam (talk • contribs)

1) Anything in the webserver logs? 2) can you edit a nonexistent page on your wiki by navigating to /index.php/SomethingRandom?action=edit? 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)

Okay! The 200 seems to have resolved itself. I guess I'll just train my users that the 404 is expected behavior.TespSam (talk) 14:27, 4 March 2019 (UTC)

If it opens VisualEditor correctly and doesn't display an error, how is this 404 even visible to them? Edward Chernenko (talk) 15:31, 4 March 2019 (UTC)

The VE loading progress bar turns into a 404 or 403 dialog box. I haven't figured out what the difference is between the 404 or 403. Also, turns out that not all the users get the dialog all the time. I created a test user that doesn't the error, they just go straight into editing the pending article, but my coworker gets the error when he tries to test. However sometimes, both users get the error.

TespSam (talk) 17:01, 4 March 2019 (UTC)

Ok, this is clearly a bug, but it might be anywhere (even in Parsoid) and I can't reproduce it locally. We need to know what was the exact HTTP request that failed with 404 or 403 (please open F12 in browser and retry the test, then look at the list of HTTP requests for failed ones) - URL, response, etc. What's the version of Parsoid? Maybe your wiki uses RESTBase proxy (which is not yet supported by Moderation)? Edward Chernenko (talk) 17:10, 4 March 2019 (UTC)

My parsoid is ver 0.8.0, no restbase. VE version 0.1.0 (6854ea0) 16:33, 5 November 2018 404 Error:

https://website.com/api.php?action=visualeditor&format=json&paction=parsefragment&page=Wiki_Main_Page&wikitext=the%20entire%20contents%20of%20the%20article

TespSam (talk) 17:47, 4 March 2019 (UTC)

Updated parsoid to 0.9.0 but it didn't help. TespSam (talk) 19:13, 4 March 2019 (UTC) Same with parsoid 0.10.0 TespSam (talk) 19:31, 4 March 2019 (UTC)

I'm pretty sure that the page that is 404'ing is coming from a URL character limit. I don't get the 404 on smaller pages, but my main page has some 5000 or more characters in url encoded format. If I chop off the wikitext part of the url, I don't get the error. TespSam (talk) 20:05, 4 March 2019 (UTC)

Confirmed that the cause was indeed the URL character limit. Fixed in Moderation 1.3.27 (this is now a POST request). Edward Chernenko (talk) 20:19, 4 March 2019 (UTC)

The fix is good. Thanks! TespSam (talk) 20:45, 4 March 2019 (UTC)

Error 500 moderating uploads

Hello, I'm trying to moderate an upload, but when I want to preview the file I got a blank page with an error 500. As seen here: https://i.imgur.com/v082uiC.png

I can't get it to show any errors. Is there a way to tell what's failing? I've tried the usual. (look in the logs, error_reporting(E_ALL); and ini_set('display_errors', true);, etc) — Preceding unsigned comment added by Krusher (talk • contribs)

Exact cause of 500 should be in the webserver's error log. Edward Chernenko (talk) 21:54, 19 May 2019 (UTC)

Tried to, but nothing is really shown, except the access line: 77.228.xxx.xxx - - [20/May/2019:09:36:51 +0200] "GET /index.php?title=Especial:Moderation&modaction=showimg&modid=17 HTTP/2.0" 500 89 "https://www.apocrypha.ovh/index.php?title=Especial:Moderation&modaction=show&modid=17" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36" "-" "www.apocrypha.ovh" sn="www.apocrypha.ovh" rt=0.053 ua="unix:/var/run/php/php7.0-fpm.sock" us="500" ut="0.053" ul="18" cs=- (nothing in error.log or php log either) --Krusher (talk) 07:38, 20 May 2019 (UTC)

Without the error message (it should be in error.log, unless the logging is somehow disabled - please check parameters error_log (should have correct path) and log_errors (should be On) in php.ini and, if PHP-FPM is used, in PHP-FPM's www.conf), there is no way to know what went wrong. 500 can be caused by 500 different reasons. Edward Chernenko (talk) 08:56, 20 May 2019 (UTC)

No matter what I do PHP won't display or log the error. The most I've figured out is that the line that is causing the error is: $repo->streamFile( $result['thumb-path'], $headers ); in ModerationActionShowImage.php ... parameters are as follows:

Array
(
    [thumb-path] => mwstore://local-backend/local-temp/0/02/20190520020756!phpoqcj5H.jpg
    [thumb-filename] => EscudodechilelicenciaCC.jpg
)
Array
(
    [0] => Content-Disposition: inline;filename*=UTF-8''EscudodechilelicenciaCC.jpg
)

File is readable and can be accessed by nginx if known. I've tried to catch it, but it seems you can't really catch errors in PHP, only exceptions. --Krusher (talk) 10:13, 20 May 2019 (UTC)

Finally, got the error:

[6c8cfceec6011d6b87da5845] /index.php?title=Especial:Moderation&modaction=showimg&modid=17 Error from line 57 of /home/krusher/www.apocrypha.ovh/extensions/Moderation/action/ModerationActionShowImage.php: Call to undefined method LocalRepo::streamFile()

Backtrace:

#0 /home/krusher/www.apocrypha.ovh/extensions/Moderation/SpecialModeration.php(140): ModerationActionShowImage->outputResult(array, OutputPage)
#1 /home/krusher/www.apocrypha.ovh/includes/specialpage/SpecialPage.php(570): SpecialModeration->execute(NULL)
#2 /home/krusher/www.apocrypha.ovh/includes/specialpage/SpecialPageFactory.php(575): SpecialPage->run(NULL)
#3 /home/krusher/www.apocrypha.ovh/includes/MediaWiki.php(288): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#4 /home/krusher/www.apocrypha.ovh/includes/MediaWiki.php(865): MediaWiki->performRequest()
#5 /home/krusher/www.apocrypha.ovh/includes/MediaWiki.php(515): MediaWiki->main()
#6 /home/krusher/www.apocrypha.ovh/index.php(42): MediaWiki->run()
#7 {main}

Is there something missing? --Krusher (talk) 10:23, 20 May 2019 (UTC)

That error message is quite helpful. I'm investigating what caused it. Edward Chernenko (talk) 10:27, 20 May 2019 (UTC)

This function was removed in this change in MediaWiki core, which won't appear in MediaWiki releases until 1.34 (current version is 1.32.1). You are using master branch of MediaWiki core. Extensions are written for (and tested with) stable versions of MediaWiki. Edward Chernenko (talk) 10:40, 20 May 2019 (UTC)

Dang, that serves me right for playing with master branches. Do you think of any temporary workaround until the extension catches up? --Krusher (talk) 10:44, 20 May 2019 (UTC)

This could do in the meanwhile:

//              $repo->streamFile( $result['thumb-path'], $headers );
                header('Content-type:image/png');
                readfile( 'images/temp/' . str_replace ( 'mwstore://local-backend/local-temp/', '', $result['thumb-path'] ) );

I should switch to the release branch, though... --Krusher (talk) 10:51, 20 May 2019 (UTC)

Fixed in Moderation 1.3.30. (of course, tomorrow's changes in MediaWiki core might break something again...) Edward Chernenko (talk) 10:59, 20 May 2019 (UTC)

Remove an approved revision or clearing the moderation list?

For some reason, when I try to "approve" some revisions, I am told "Edit not found. Probably already approved." However, the revision still appears in the moderation list! Sometimes I receive this message too: "Your edit was ignored because no change was made to the text." How do I remove it from the moderation list? How do I clear already approved revisions from the list? Thanks. --Postprefix (talk) 02:03, 7 June 2019 (UTC)

1) This is super odd. "Approve" always removes the edit from the list (in fact, it shouldn't even be in the database after Approve, so Special:Moderation can't possibly keep showing it). 2) Message "no change was made to the text" is a normal situation, it's a so-called "zero edit". Reject these edits. They can appear if, for example, an automoderated user forgot to login, his edit was queued for moderation, user realized this and saved the same text as logged-in user. Then when you click Approve on his prior anonymous edit, it would make no sense, because the article already has exactly the same text as what you are trying to approve. These edits can be safely Rejected, as they would have no effect if approved. 3) "zero edits" are not suppressed automatically, because sometimes people write meaningful things in edit summary when doing zero edits. Edward Chernenko (talk) 12:46, 7 June 2019 (UTC)