Last modified: 2014-11-17 10:35:26 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 T20228, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18228 - Add pagination (offset, prev/next, until/from/to) to Special:RecentChanges UI
Add pagination (offset, prev/next, until/from/to) to Special:RecentChanges UI
Status: NEW
Product: MediaWiki
Classification: Unclassified
Recent changes (Other open bugs)
1.15.x
All All
: Low normal with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 17749 (view as bug list)
Depends on:
Blocks: 11551
  Show dependency treegraph
 
Reported: 2009-03-28 12:54 UTC by Splarka
Modified: 2014-11-17 10:35 UTC (History)
5 users (show)

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


Attachments

Description Splarka 2009-03-28 12:54:25 UTC
Recent Changes limits were recently reduced to a maxmimum of 500, and this is a bit low for some projects. http://wikitech.wikimedia.org/index.php?oldid=19388#March_24

Several have suggested that Recent Changes be paginated, and I have not yet seen an open bug for this (although bug 17749 is related and might be solved by a good pagination system)

The best UI for this would probably be the type used on Special:Log and Special:Contributions. The Allpages/Prefixindex next/prev, and the TablePager big blue buttons are more for alphabetical listings and tabled/columned lists. The UI could just add inside the existing form:

 (latest | earliest) View (newer 50) (older 50) (20 | 50 | 100 | 250 | 500)

This isn't ideal for a recent changes field (where the tail end of the information is trimmed), but it is already used by Special:Newpages so should suffice.

Another problem, is the &from= URI already used in recent changes, has contrary meaning to some interpretations of what it should do. The best solution probably is to just ditch this parameter (or leave it for legacy, possibly interpret it as an alias for &timestamp=X&dir=prev) and use the same thing done for almost all other time based pagination: &offset=TIMESTAMP combined with &dir=next/prev.
Comment 1 Niklas Laxström 2009-03-28 14:02:15 UTC
Imho a link in the bottom for "Show older changes" is enough.
Comment 2 Niklas Laxström 2009-05-23 09:11:11 UTC
Not an enhancement. The 500 limit greatly limits the ability to browse history
in most wikies. In any but the smallest wikies there is data that cannot be
browsed trough Special:Recentchanges.
Comment 3 Gurch 2009-05-23 18:00:39 UTC
(In reply to comment #2)
> Not an enhancement. The 500 limit greatly limits the ability to browse history
> in most wikies. In any but the smallest wikies there is data that cannot be
> browsed trough Special:Recentchanges.

* The limit is 5000, not 500. (Half an hour on en.wikipedia, yay)
* Since data is kept in recentchanges only a short time anyway (1 month?) there is plenty of data that cannot be browsed through Special:Recentchanges even on the smallest wikis. This is by design.
Comment 4 Niklas Laxström 2009-05-23 18:07:25 UTC
(In reply to comment #3)
> (In reply to comment #2)
> * The limit is 5000, not 500. (Half an hour on en.wikipedia, yay)
Was, see r48735.
> * Since data is kept in recentchanges only a short time anyway (1 month?) there
> is plenty of data that cannot be browsed through Special:Recentchanges even on
> the smallest wikis. This is by design.
Now three months by default (was one week), see r50930. Of course the history is truncated at some point, but it should be possible to browse what there is.
Comment 5 Alexandre Emsenhuber [IAlex] 2009-07-26 21:25:47 UTC
*** Bug 17749 has been marked as a duplicate of this bug. ***

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


Navigation
Links