limit="" and paginate="" are inconsistent

[pmeissner]

Not sure if this is a bug or a feature request, but…

USE CASE:
My client has a collection with 1,000 non-dated entries. They would like to show four pages with 50 entries each (200 limit). Then, they want a "show archive" button to view the rest on a separate page.

I TRIED:
{{ collection:stuff limit='200' paginate='50' }}
I expected four pages of 50. But the collection tag returns all 1,000 entries on 20 pages.

The collection tag seems to always pull ALL of the entries when the paginate is set to "true" or has an int.

The nature of the limit="" parameter changes when paginate is used. This seems wrong.
Limit should ALWAYS refer to the total result returned. The paginate int should always be an int that divides those results into pages. Not sure what paginate="true" should do.

Put another way… the collection tag should apply all of it's limit and filters FIRST to get the total results and THEN paginate them based on a paginate int.

Maybe a bug fix that wouldn't break too much would be going forward when a paginate has an int the limit="" should be respected as the total results returned. But if paginate is set to TRUE, then the limit="" would be the number of entries on a page. Seems icky.

Is there a workaround?

[jesseleite]

@pmeissner So, the limit param is not meant to be used with a paginate param integer like that. There are basically two main ways of paginating...

1. {{ collection:stuff paginate="50" }}
   • shows 50 per page
   • relies on &page=2 GET param to intelligently control which entries you're showing for that page
2. {{ collection:stuff limit="50" offset="50" }}
   • show 50 per page
   • the &page GET param has no effect
   • you instead use offset param offset to control pagination
     • limit 50 + offset 0 would be page 1
     • limit 50 + offset 50 would be page 2
     • limit 50 + offset 100 would be page 3
     • etc.

Think of paginate as the smarter / higher level thing, already wired up to &page GET param, whereas limit + offset is the lower level param combo for controlling pagination more programatically, if that makes sense ❤️

[jasonvarga]

We should probably throw an error if you have both limit and paginate with a number as it becomes ambiguous.

[jesseleite]

@pmeissner In fact, when you use paginate int, we don't even process the limit param (you can see the early return here).

For your use case, where you want to show only first 4 pages and archive the rest, you could do something like this on your main entry listing...

{{ if get:page > 4 }}
    {{ 404 }}
    // or
    {{ redirect to="/articles/archive" }}
{{ /if }}

{{ collection:articles paginate="50" }}
   ...
{{ /collection:articles }}

And then on your archived entries page, utilize offset by itself to skip the first 4 pages / 200 entries...

{{ collection:articles offset="200" }}
   ...
{{ /collection:articles }}

[pmeissner]

Thanks @jesseleite for the code strategies to get it working!