Last modified: 2009-03-30 09:48:23 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 T20241, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18241 - Large problem with vandalism patrolling because restriction Special:Recentchanges
Large problem with vandalism patrolling because restriction Special:Recentcha...
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Nobody - You can work on this!
http://nl.wikipedia.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-29 01:52 UTC by Lolsimon
Modified: 2009-03-30 09:48 UTC (History)
2 users (show)

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


Attachments

Description Lolsimon 2009-03-29 01:52:03 UTC
Since a few days it is not possible to view more than 500 edits in the Special:Recentchanges page (for resource limits?). At the Dutch wikipedia (nl.wikipedia.org) we have a vandalism system with 'patrolled versions', and have a backlog with +/- 2,000 pages. Our vandalism patrollers are now not able to patroll the oldest vandalism, from 16 march (already a week more than normal!).

It is not possible to use any other tools, only the Special:Recentchanges page were used to do this work, and external tools (such as VPopSpeed) does also not work. If there isn't soon (about 2 weeks from now) a solution to this problem, some of the vandalism will stay at our wikipedia without revert, so this problem should be taken seriously.

I have heard some wiki's also doubt with this problem, but at our system of vandalism patrolling it is now impossible to do the patrolling work as normal, we just can't do the vandalism patrolling properly and when there isn't a sollution soon, it will get really, really problematic!
Comment 1 Splarka 2009-03-29 14:58:19 UTC
Probably either bug 18228 or bug 18229 could solve this in the long run. Note that domas has optimized rc by about 30% with some live hacks, but is not yet willing to reinstate a higher limit.

I've created a little script that might help you in the (time-critical) meantime: 

http://en.wikipedia.org/wiki/User:Splarka/ajaxrecentchanges.js

It takes advantage of the fact that the API can paginate recent changes data. It works pretty good, and immitates most featurs of regular recent changes, plus lets you sort with very advanced options (any grouping of namespaces, any type/filter combo) and has ajax patrol buttons for one-click patrol (disabled by default) and can be localized by editing the arc-i18n.

It does have limitations (as of this comment):
* If you leave the page, all your data is lost, best to do all operations in new tabs.
* It doesn't perfectly immitate the RC, I skipped some pointless UI and didn't put in rollback links.
* If rc patrolling is disabled, it mistakenly shows a red "!" for every edit, this will be fixed in the next scap.

If you have any questions about it -> http://en.wikipedia.org/wiki/User_talk:Splarka
Comment 2 Domas Mituzas 2009-03-29 15:01:52 UTC
for now the limit is higher, btw
Comment 3 Lolsimon 2009-03-30 09:48:23 UTC
Indeed, the limit is higher and we don't have any problems any more. Our vandalism patrollers can get back to work ;-) - Thanks!

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


Navigation
Links