Imho a link in the bottom for "Show older changes" is enough.

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.

matthew.britton wrote:

(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.

(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.

• Bug 17749 has been marked as a duplicate of this bug. ***

Extending this task to watchlists (they have largely overlapping implementations so it doesn't make sense to change one but not the other) and limiting to the old UI, since we already have a task for the new one, and the required changes are substantially different and can be done separately.

I removed this part of the old task description:

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.

as it doesn't seem really related.

Old here refers to the "Use non-JavaScript interface" preference. Grouping vs. non-grouping shouldn't make any difference for paging.

Oh, then the title of the other task needs to be changed. When it comes to Watchlist/RecentChanges, "the enhanced UI" can only mean the grouping interface.

In T20228#8632726, @Nardog wrote:

Oh, then the title of the other task needs to be changed. When it comes to Watchlist/RecentChanges, "the enhanced UI" can only mean the grouping interface.

Both of those were called "enhanced" at one point. (The "Use non-JavaScript interface" setting is still internally called rcenhancedfilters-disable.) But yeah, it's not a helpful qualifier.