Change Details

**Author:** `herd` **Description:** 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. -------------------------- **Version**: 1.15.x **Severity**: normal

Recent changes / wishlists are one of the very few interfaces that offer no pagination or other way to access older results, even though at the API level the functionality exists. 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. **See also** * [[https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Notifications,_Watchlists_and_Talk_Pages/Allow_going_beyond_the_first_page_on_RecentChanges/Watchlist_(%22older_n%22)|2023 wishlist proposal]] * {T163429}

**Author:** `herd` **Description:** 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 paginatedRecent changes / wishlists are one of the very few interfaces that offer no pagination or other way to access older results, 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)even though at the API level the functionality exists. 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. --------------------------**See also** **Version**: 1.15.x [[https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Notifications,_Watchlists_and_Talk_Pages/Allow_going_beyond_the_first_page_on_RecentChanges/Watchlist_(%22older_n%22)|2023 wishlist proposal]] **Severity**: normal* {T163429}