Page MenuHomePhabricator

Revert recentchanges limit to 5000 (id.wikipedia)
Closed, DeclinedPublic

Description

Author: stanley

Description:
For the reason of vandalism patroll, please revert recent changes limit to 5000 on id.wikipedia.


Version: unspecified
Severity: normal

Details

Reference
bz18197

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:33 PM
bzimport set Reference to bz18197.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

This is not currently configurable on a per-wiki basis. Ideally, we should fix the code so that it doesn't take a ludicrous amount of time to format 5000 rows, and reenable it for everyone . . . or just add paging.

stanley wrote:

The current recentchanges url is not consistent with its logic. According to logic, "..&from=20090326145934&limit=500&..." should provide all recent changes started from the older post (20090326145934) and 500 newer post. The current logic is calculated from the newer post (now) and 500 older post, therefore it should be changes to "..&from=now&limit=500&..." :D. I can live with the 500 limit if you change this sort method. :D

stanley wrote:

Anyone. Please dont limit rc to 500. If 5000 is too many, 3000 or 2000 is fine. 500? How can you expect people to monitor vandal with this restriction?

herd wrote:

(In reply to comment #2)

The current recentchanges url is not consistent with its logic. According to
logic, "..&from=20090326145934&limit=500&..." should provide all recent changes
started from the older post (20090326145934) and 500 newer post. The current
logic is calculated from the newer post (now) and 500 older post, therefore it
should be changes to "..&from=now&limit=500&..." :D.

That is bug 18228. Note this is possible with the API, so you can fake it (eg: http://en.wikipedia.org/wiki/User:Splarka/ajaxrecentchanges.js ).

Now the maximum limit seems to be 5000. So WORKSFORME (or maybe dupe of bug 18241).