Pagination UI different between top and bottom on administration screens

[linuxologos]

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.

[linuxologos]

difference in pagination UI

[PeteMall]

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

[nacin]

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.

[linuxologos]

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

[SergeyBiryukov]

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.

[scribu]

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.

[garyc40]

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

[garyc40]

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

[scribu]

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.

[garyc40]

centralize redirection in set_pagination_args()

[garyc40]

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.

[markjaquith]

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.

[garyc40]

Sorry for unintentionally hijacking this ticket :(

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

Closing this as wontfix.