WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 11 months ago

#16356 closed defect (bug) (wontfix)

Pagination UI different between top and bottom on administration screens

Reported by: linuxologos Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: Administration Keywords: has-patch needs-testing
Focuses: Cc:

Description

Go to any paginated administration screen. At the top of the items listed (posts, users etc.) you are allowed to enter the number of the page you want to go to directly, whereas at the bottom only arrows exist.

The issue must have appeared in recent revisions, maybe during the process of the AJAX removal. It already exists in [17330] at least. It affects all administration screens.

Screenshots attached.

Attachments (4)

pagination.PNG (15.2 KB) - added by linuxologos 4 years ago.
difference in pagination UI
16356.patch (1.4 KB) - added by SergeyBiryukov 4 years ago.
garyc40.16356.diff (4.1 KB) - added by garyc40 4 years ago.
fix redirection inconsistencies in edit-tags.php, users.php, network/users.php
garyc40.16356.2.diff (9.0 KB) - added by garyc40 4 years ago.
centralize redirection in set_pagination_args()

Download all attachments as: .zip

Change History (15)

@linuxologos4 years ago

difference in pagination UI

comment:1 follow-up: @PeteMall4 years ago

  • Milestone changed from Awaiting Review to 3.1

Also, we are not redirecting to the last page when the user enters a page number higher than the max pages.

comment:2 @nacin4 years ago

By design, so it's not changing at this point. Otherwise on form submit we will always assume that the bottom input received the enter. There are some creative ways to remedy this but it was decided that you'd most likely do an arbitrary adjustment of the pages from the top. One of the alternatives was to simply remove the arbitrary input all together, which I didn't like.

Pete's bug sounds legit though, but honestly extremely minor.

comment:3 in reply to: ↑ 1 @linuxologos4 years ago

Replying to PeteMall:

Also, we are not redirecting to the last page when the user enters a page number higher than the max pages.

I can reproduce this only on Users screen, where entering a page number higher than the max pages not only doesn't redirect to the last page, but also brakes the screen in some way ("No matching users were found" and the Search Users field is also gone...)

@SergeyBiryukov4 years ago

comment:4 @SergeyBiryukov4 years ago

Here's a patch for the Users screen. Some other screens are redirected to the first page instead of the last, which seems a bit inconsistent. However it doesn't break anything, so I guess we can leave it as is for now.

comment:5 @scribu4 years ago

The current behaviour is consistent to that on the front-end: going to /page/999 results in a 404.

An alternative approach to 16356.patch would be to limit the page number in JS, before the request is sent.

This would have the advantage that it would be consistent for all screens. The disadvantage of course would be that it wouldn't work without JS.

@garyc404 years ago

fix redirection inconsistencies in edit-tags.php, users.php, network/users.php

comment:6 @garyc404 years ago

There are a few additional bugs with pagination that I found (which are also addressed in garyc40.16356.diff

  • Go to edit-tags.php, navigate to the 3rd page, for example. Then enter 2 in the pagination input box and press enter. You'll be in page number 3.
  • Go to network/users.php , enter a page number in the pagination input box and press enter. It simply redirects to page 1.
  • WP_Users_List_Table and WP_MS_Users_List_Table doesn't set the proper pagination args when $pagenum > $total_pages . This is because total user count is not executed when no results are returned from the query. See the change I made in wp-includes/user.php.

Should all the redirection when $pagenum > $total_pages be centralized in WP_List_Table? We can put that logic inside WP_List_Table->set_pagination_args().

Last edited 4 years ago by garyc40 (previous) (diff)

comment:7 @scribu4 years ago

Should all the redirection when $pagenum > $total_pages be centralized in WP_List_Table? We can put that logic inside WP_List_Table->set_pagination_args().

That's a good idea.

@garyc404 years ago

centralize redirection in set_pagination_args()

comment:8 @garyc404 years ago

  • Keywords has-patch needs-testing added

Related to #16208, if not duplicate.

Since #16208 is marked as 3.2-early, and the centralization of redirection is kind of too much change for 3.1 especially when we're already at RC3, I think we should only focus on the bugs outlined in comment:6 (addressed in garyc40.16356.diff) .

I attached garyc40.16356.2.diff here anyways, just in case someone wants to test it.

Version 0, edited 4 years ago by garyc40 (next)

comment:9 @markjaquith4 years ago

garyc40 — can you please open a new ticket for the issues that garyc40.16356.diff fixes and then close this ticket as "WONTFIX" ? Agreed, let's just fix the bugs, and leave #16208 for 3.2.

And c'mon everyone — distinct tickets for distinct issues. The originally reported issue on this ticket is intentional and is a WONTFIX for 3.1.

comment:10 @garyc404 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

Sorry for unintentionally hijacking this ticket :(

Reposted pagination issues as a separate ticket @ #16357 along with patches

Closing this as wontfix.

comment:11 @SergeyBiryukov11 months ago

  • Milestone 3.1 deleted
Note: See TracTickets for help on using tickets.