Skip Navigation

[Resolved] New features for Views pagination

This support ticket is created 7 years, 7 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 8:00 – 17:00 8:00 – 17:00 8:00 – 17:00 8:00 – 17:00 8:00 – 17:00 -
- - - - - - -

Supporter timezone: America/Sao_Paulo (GMT-03:00)

This topic contains 34 replies, has 13 voices.

Last updated by Adriano 6 years, 11 months ago.

Assigned support staff: Adriano.



We want to make sure that Views pagination covers all your needs. If there are major features that you cannot find in Views pagination, please describe them here.

We are starting now with Views 1.11 development cycle and we may be able to push new features for pagination.

When you describe these features, help us understand.

1. Give an example
2. Explain the missing feature in words
3. Say what you are doing now, as a temporary solution (even using a different plugin works)

We can't promise to include everything, but we promise to do our best!


Alright, let's go.
Views offers good basic support for <previous next> pagination plus numbered page links.
Under certain circumstances though a site may end up with dozens or even hundreds of pages.
In such cases you may wish to implement a commonly used pagination scheme where you display << + first pages links + ... + the last pages link + >> to save screen space or just avoid breaking your layout.
Here's an example of this scheme from a real estate site made by me: hidden link.
In this example I ended up using a custom function suggested by a member of the wp-types support team.
While this custom code sort of meets my need, it's not native to Views and so may stop working after a Views update. (This happened once)
Besides adding a hack layer over Views, this code doesn't support the ajax pagination feature.
I would be great for Views to expand its pagination feature including the above scheme with all the benefits of a built-in solution.


Sounds great :). It would be very appreciated if views 1.11 would integrate "infinite scroll" to a view listing. So - no pagination anymore, but "endless" scroling instead.


Hi Amir, a few months ago (Sept. 2014) I suggested a new pagination function, as Roberto request in this topic.

Here's my contribution:

It's a small code and to use it is made as the same Views paging shortcode, but adding a couple of new attributes, is used as follows:

[wpv-pager-current-page style="link2" mid_size="4" end_size="1"]

In which "mid_size" defines the number of page links inserted between the current page and the first/last one.
And the "end_size" defines the number of first/last pages links.

You can view it in action at: hidden link

I would really apreciate it if you implement this code in your next Views version, it's so simple and adds new features requested by many users.

Hope you like it.

Best Regards!


@roberto suggestion ... +1
@Angele suggestion ... +1


A big + 1 for this

"It would be very appreciated if views 1.11 would integrate "infinite scroll" to a view listing. So - no pagination anymore, but "endless" scroling instead."

It would be great to have a built-in infinite scroll option that just required you to check the box for infinite scroll and it would magically work.


Talking about "infinite scroll", please be aware of making it search-friendly ,otherwise crawlers will not be able crawl the content of those pages.
A recommendation from Google: hidden link

As Google Webmaster says:
"With infinite scroll, crawlers cannot always emulate manual user behavior--like scrolling or clicking a button to load more items--so they don't always access all individual items in the feed or gallery"
"If crawlers can’t access your content, it’s unlikely to surface in search results."

It would be cool but, please, SEO-friendly


Is the recent Ajax-Pagination method SEO friendly? Probably I am wrong, but those JavaScript methods are mostly used on archives, where every item of the archive (Post, CPT) has its own URL (SEO friendly). And with a good sitemap google can crawl all pages/posts/cpts.

For clarification: The feature suggestion "infinite scroll" is meant as an additional option, not as something that should replace the existing pagination options.

Also from me: +1 for Robertos proposal.



Timezone: Europe/Madrid (GMT+01:00)

HI everyone!

This is Juan, lead Views developer. First of all, lots of thanks for your suggestions 🙂 I see that we basically have two main requests here:

== Enhanced links-based pagination controls ==

We already have a working version that provides:
- A step attribute, so only pages which are multiples of that step value are shown.
- A reach attribute, so only pages within the reach of the current page are shown.
- An ellipsis attribute, so you can control what gets displayed in the gaps between links.

Of course, all those options can be combined and we will provide a GUI to set them. It will surely be included in Views 1.11 and I am quite happy we finally introduce this.

== Infinite scrolling ==

This one is a little more complex to implement, for a series of reasons.

- We do not entirely control the output structure.
Imagine you are using a View, and you return 7 items per page in a table layout, with two items per row: there is one orphan row with just one cell. Now, when we try to "glue" the second page results into this, it becomes extremely difficult to put the new content along with the old one. We might need some time to get this right, if this becomes a feature.

- As someone pointed above, AJAXed content is not that search-engine friendly.
No, the AJAX pagination as we have it now is not totally ready for SEO, basically because by the time the page header is displayed, we do not know whether a View will be displayed or not, so we can not display any pre/next meta-tags at all. Remember that Views are items inserted inside existing content, but not first-class WordPress conteint itself. We can (and we will) provide links so spiders can at least follow them, with query parameters that identify the View and the relevant page.

Now, infinite scrolling seems to be based on an entirely link-free workflow, so the above half-solution is lost. We might even want to explore infinite scrolling that gets triggered by a link or button in addition to by just scrolling. Anyway, I will be updating this ticket with further info as it becomes available.


In addition to those enhancements, we will be adding some new pagination shortcodes, because some of the existing ones have misleading handles.

Let's keep this ticket open for reference until the next release, so even more ideas can be tracked here 🙂



That's a great news, Juan!
Please just be sure to include ajax support in the new implementation.


A new influx of transition effects would be a nice enhancement. Checkout Layerslider to see 200+ transitions. hidden link . That's almost too many but an increase from 5 would be welcomed.


Client-side filtering would be nice. Say I've got just 10-20 items in 4 categories. I don't want the view to go to server every time he needs to filter something, as everything is already there...



Timezone: Europe/Madrid (GMT+01:00)

Hey Ronald

Very good idea! Thank you for ponting this out. In fact, I am reviewing the whole way we implemented our pagination effects, and I plan to fill it with actions, filters and methods to make it extensible. Who knows, w emight even see a WP Views Addon Pagination Effects someday 😛

Hello Lina

As much as I would love to be able to do so (shaving even one database query is what I dream of every night), it would be a little difficult. Yes, we do have the whole results there (well, not them al if you are paginating...), but we have no way of knowing what metadata each displayed post has. I mean, if you decide to filter by a category, but you are not displaying any category info whatsoever, how can we know which ietms stay and which ones need to go?


I have good news for everyone: we have a first working version of infinite scrolling. It is triggered by the "Next" pagination control (so it is not automatic), it works beter when you add a given classname to your loop outputs (but has a secondary method to work with existing Views) and I need to check what to do with the "Previous" link and all the other pagination controls, but we are in a very good path 🙂

I'll keep you all posted here.


Display information about the Post, Taxonomy, etc that will show up when clicking the next/previous pagination.

so if your order of slides is like this (each slide has 1 page, these are the titles):
1. treats
2. main dishes
3. drinks
4. appetizers

and say you were currently on the "main dishes" slide, you could set the shortcode to possibly show:
<- treats drinks ->

it could be as simple as something like this:

[wpv-pager-previous-page][pager-context="[wpv-page-title]" offset="-1"][/wpv-pager-previous-page]
[wpv-pager-next-page][pager-context="[wpv-page-title]" offset="+1"][/wpv-pager-next-page]


Timezone: Europe/Madrid (GMT+01:00)

Hi Corey

I like the idea, but I am not sure this can be available as a general rule. Note that when using Views pagination you can load more than one post, so there is no real "offset". I mean, sometimes when you click "Next" you are not going to load a Post, but a bunch of Posts. Maybe we could solve it my getting info from the first element in the new page, but this would need a complete set of coding iterations to get it right 🙂

Anyway, I'm taking note of it.