Topic on Project:Support desk

How to disable vandalism checks

9
129.7.105.17 (talkcontribs)

I've scoured to find documentation pertaining to how to disable these vandalism checks. My contributors and I make massive changes throughout the site; it's normal to gets reverted back to previous content since upgrading to a newer version of mediawiki. I would think the tips from using mediawiki as a CMS would be enough to cover it, but it seems not.

Example:

(diff | hist) . . m page-name; 22:51 . . (-47,412)‎ . . ‎User2 (Talk | contribs)‎ (Reverted edits by User2 (Talk); changed back to last version by User1)

Thanks!

87.123.60.188 (talkcontribs)

Is your wiki public so that I could have a look? What is its URL?

Your configuration obviously is that the same user, who did an edit, automatically(?) undoes it again, if some magical criteria are met. I would guess that it is some kind of extension, which might do that.

Please check your Special:Version page in your wiki and see, which extensions it lists there!

129.7.105.17 (talkcontribs)

Not really sorry. Everything is fairly default.

Product Version MediaWiki 1.23.13 PHP 5.4.16 (apache2handler) MariaDB 5.5.44-MariaDB

Last time I looked at the problem I could tell it was something around this mechanism.

https://www.mediawiki.org/wiki/Manual:Interface/Revertpage

You can see it follows the example of the resent change format. Something is triggering a rollback and this revertpage functionality.

I do not have any extensions enabled, no require once in LocalSettings.php.

129.7.105.17 (talkcontribs)

Apparently showing apache logs is a bad idea here.

129.7.105.17 (talkcontribs)
87.123.5.214 (talkcontribs)

I am pretty sure that MediaWiki itself does _not_ contain a functionality, which would do automatic reverts.

There are some extensions, which can be used to do automatic reverts (and if these extensions are configured incorrectly, they could show the undesired behaviour, which you see). One of these extensions is Extension:AbuseFilter. However, if you do not have any extensions installed, then this cannot be the problem.

The log excerpt, which you posted, only contains hits, which have been done by one and the same user. To me it looks like this has happened: The user visited Special:RecentChanges and then he hit one of the rollback links, which are present on that page. At least judging from the URLs, which have been requested, this is what happened.

Based on these observations, I would expect that, if you do _not_ visit Special:RecentChanges, _no_ rollback occurs. That mightbe a workaround until the problem is really solved.

Does that happen for _all_ users? Or only for some?

Do you maybe use some JavaScript, which automatically clicks certain links for you?

129.7.105.17 (talkcontribs)

I observe it very rarely. Two or three heavy committer seem to be have this issue. In the database the rc_comment notes the following on the rollback.

Reverted edits by user2 (Talk); changed back to last version by user1

Also rc_log_action and rc_params are blank instead of null for both the commit and the rollback. This differs from normal commits that have null for both fields.

I'll ask the committer not to look at the page and I'll examine it in the database. As for javascript very doubtful. Text data is what the wiki is used. Everything is very vanilla, no customization other than the banner icon.

Since i'm not referencing any extensions I'm just going to delete the directory and see if I notice anything different.

129.7.105.17 (talkcontribs)

I'm not 100% sure yet, but disabling Special:RecentChanges seems to stop this behavior. I disabled access to Special:RecentChanges via the extension Lockdown and I have not seen the activity since. The problem is I know the users are not actively pressing the rollback for the changes. I would like to have the functionality to see changes, but at least it seems working correctly again. Thanks for your suggestions! I'll leave an update when I know for sure.

101.160.16.110 (talkcontribs)

It seems highly likely that they are just accidentally (or maybe purposely) clicking on the rollback link. You could simple hide that link to test that theory.

.mw-rollback-link {
	display: none;
}

You could also remove the rollback right from their user group, and if you still want to have it, make a new group that contains the rollback right and give your account that group.

Reply to "How to disable vandalism checks"