Last modified: 2014-06-02 11:29:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T66614, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 64614 - SpamBlacklist catches harmless edits due to inconsistent externallinks table on commonswiki
SpamBlacklist catches harmless edits due to inconsistent externallinks table ...
Status: RESOLVED WORKSFORME
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
wmf-deployment
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-29 17:02 UTC by Jarek Tuszynski
Modified: 2014-06-02 11:29 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jarek Tuszynski 2014-04-29 17:02:44 UTC
Many files in the https://commons.wikimedia.org/wiki/Category:Masopust_dr%C5%BE%C3%ADme_%281910%29 category can not be edited. The problem is that the source website was added at some point to spam filter black list, which for some reason blocks edits not related to external links. 

I asked about it on wikitech-l and Brad Jorsch (Anomie) looked into the issue (http://marc.info/?l=wikitech-l&m=138868325110772&w=2 ) and concluded that there is some unexplainable behavior. He also fixed files I had problems with then by "purging the page via the API with the forcelinkupdate".

Currently I have similar problems with:
File:Masopust držíme 03.jpg
File:Masopust držíme 10.jpg
File:Masopust držíme 18.jpg
File:Masopust držíme 24.jpg
File:Masopust držíme 29.jpg
and purging with forcelinkupdate does not seem to work. Can someone purge those pages, so they allow edits again?
Comment 1 Andre Klapper 2014-05-03 18:38:36 UTC
Hi Jarek,
hmm, is this report about a potential code problem in the code of AbuseFilter, or about fixing the affected files on Commons, or both? :)

I also wonder how I could reproduce the problem - would I edit https://commons.wikimedia.org/w/index.php?title=File:Masopust_dr%C5%BE%C3%ADme_03.jpg&action=edit&section=1 ?
Comment 2 Marius Hoch 2014-05-03 18:55:21 UTC
After running LinksUpdate for "File:Masopust držíme 03.jpg", editing it works indeed.

Also this is anything but an AbuseFilter bug (also not a title blacklist bug), but rather a Wikimedia thing.
Comment 3 Marius Hoch 2014-05-03 18:59:19 UTC
BTw: You can purge the links by using the action=purge API with forcelinkupdate (that worked for me)
Comment 4 Marius Hoch 2014-05-03 22:14:10 UTC
Updated the title to match what actually is happening over here. Not sure what the concrete solution would be.

@Jarek: Do you have a complete list of all pages that would need to be purged or something like that?
Comment 5 Jarek Tuszynski 2014-05-06 12:08:26 UTC
I do not have a list of files that this happened to, but I run into the occasionally. I thought that maybe there is a way to create an DB query to find files with  inconsistent externallinks table and purge them. I tried "action=purge API with forcelinkupdate" before but maybe I misunderstood how to do that. I just succesfully purged the last 3 files from my set in the first post.

If there is not way to search DB then I would propose to close the bug, as the specific files I had issues with are now fixed.
Comment 6 Andre Klapper 2014-06-02 11:29:50 UTC
Closing as per comment 5.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links