New pagination style on list-type screens

[jane]

On screens like edit.php where all posts are listed (or where comments are listed, media library, etc), the pagination we have is a little bit bulky, with arrows, numbers, dots, numbers and arrows. If you want to jump 10 pages in, for example, it takes several clicks to get to a place where you have the option. I propose we adopt a different style of pagination, one that allows entry of the page number directly in addition to using previous/next arrows. I'm attaching a snapshot of how Hulu does it, which is fast, easy to use, and very unobtrusive.

Marking as 3.0 in case someone feels like coding up a patch before freeze next week, but at that point I'll go ahead and punt it.

[janeforshort]

Hulu-style pagination

[jane]

@ryanfitzer: You set yourself as owner on this, but there's no patch. Freeze is today, and no one else is working on it since you assigned it to yourself. If you don't have a patch that can be uploaded, please remove yourself as owner. Thanks.

[dd32]

This has missed the boat for 3.0, I'm setting to 3.1 early, It looks like a positive step forward to me and I'd like to see it implemented.

I'm accepting this ticket for now, but if someone else feels like implementing this before I get to it, please do so, take over the ownership. I'm mainly accepting it so as to be reminded in 3.1 :)

[edward mindreantre]

Basically: I'm on it.

[edward mindreantre]

I've attached a whole zip file with the changed files. Kinda hard to make such ginormous patches...

Anyways... here's what's new.

Two css files. Search for NEW TABLENAV STUFF. I've commented out the old stuff. Don't know what's needed and not needed for the other stuff in the tablenav.

One sprites image file.

general-template.php - Search for function paginate_links. I've commented out the old function just for comparison reaons.

edit.php - Search for $page_links = paginate_links. Basically I've removed two unnecessary strings from there. There is not only one string that gets translated: Page. And I'm not even sure that it's necessary. I think all the other paginate_links() calls will need to be slightly tweaked.

I'm gonna mark it as has-patch, even though this isn't a patch. Someone more familiar with the rest of wordpress can make a patch, I figure.

[jane]

"I'm gonna mark it as has-patch, even though this isn't a patch."
I'm sure you can understand that doing so messes with the system. removing keyword as well as owner/accepted status, since you're asking for someone else to make the patch.

[edward mindreantre]

There's your patch.

[edward mindreantre]

Removed something that was used for testing.

[scribu]

I'm reassigning this to myself as I'll be working on it as part of my GSoC project.

We currently have this:

Displaying 51-100 of 1200 [«] [1] [2] [3] [4] ... [24] [»]

Hulu has this:

[<<] [<] [ 2 ] of 24 [>]

I think we'll have to get rid of the "Displaying 51-100 of 1200" part to avoid confusion.

[voyagerfan5761]

Replying to scribu:

I think we'll have to get rid of the "Displaying 51-100 of 1200" part to avoid confusion.

I think that's something to bring up on the wp-ui mailing list. It's often very useful to know how many items there are, rather than just how many pages of items.

[nacin]

Agreed, knowing how many total items can't disappear. How many per page could probably be sacrificed.

[voyagerfan5761]

How many per page is a setting, usually a screen option, so it could go. Then again, the range of "51-100" is useful for orienting oneself inside a collection of items.

It's hard to think of losing cues like that.

[johnonolan]

My vote would be for something like WP Pagenavi - "Page 1 of 100" followed by the links.

[scribu]

Note that the "Displaying 51-100 of 1200" text isn't always correct when displaying hierarchical items (taxonomies and post types). This is because child items are repeated when going between pages.

Thus, I will be replacing it with "1200 items", which is always correct and shorter too.

[voyagerfan5761]

If the range of items displayed isn't always correct, there are two options. One is to remove that information (what you've chosen to do).

The other, (arguably) more useful option is to fix the display or counting code such that the displayed range is correct. Instead of counting repeated items, they should be excluded from the range.

Just a comment. Removing potentially useful information should be done only with a very good reason.

[scribu]

See #14579.

[scribu]

[15491]