Liquid paginate limit: Only 250 products showing despite paginate by 1000 – any workaround?

Online Store and Theme Development
25

Thanks for reporting this too @tim_tairli. Just to clarify to make sure I’m understanding correctly here, is what you’re seeing essentially that when a collection or blog is selected via section settings, Shopify only seems to surface a capped subset (about 50 items) that paginate can’t extend, and that re-querying the same resource by handle (collections[...]/blogs[...]) or using a metafield reference returns a full object that respects paginate?

Just wanted to make sure I’m understanding the behaviour you’re seeing there.

1 Like
26

Yes, exactly like this.
If I get an object (say, collection) from settings and try to paginate its property list (collection.products) there is no error, paginate object looks fine, but pagination size I request is silently ignored. Its’ fixed at 50, can’t make it more or less.

I mentioned metafields here because the “magic” is very similar – settings/metafield only store the GID , but when referred, it’s converted to an actual object. But in case of settings it’s kinda handicapped :wink:

27

Thanks @tim_tairli , appreciate you confirming this! I’ll do some further digging on my end to see if we can confirm expected behaviour here as well/if we need to make any changes on our end.

I’ll loop back with you as soon as I have more info.

1 Like
28

Hey folks - thanks for your patience. We’ve just pushed a fix for this that should be live. Can you let me know if you’re still seeing the error, if so, feel free to share a new example and I’d be happy to take a look :slight_smile:

1 Like
30

Hey Alan,

I had a similar issue with the pagination before in that when I first stored collection.products into a variable and then paginated collection.products, I could utilize that variable, apparently up to 250 50 items it seemed, with an offset (from 0) and limit set but when I tried to do the same with search results it did not work.

The use case here was inserting CTA cards inline with product cards, and keeping the same page size, so on certain pages cards may be skipped where all of the pages following that would need to put that number of skipped cards upfront. (Hence the use of the offset from 0, as it would involve at least the previous page of items.)

In my initial testing I never tried a collection with more than 250 3 pages of products (24 per page) so I did not catch the issue with the approach I used initially, and needed to opt for the JS page-based approach I was using for the search results that grabbed any skipped cards from the previous page. The issue being that apparently I could not offset past 250 50 items to have a non-JS solution in place where the cards did not need to be injected during/after page-load.

I am assuming at least the not being able to offset past 250 50 items was expected behavior, but I was surprised that I could not use that approach with the search results — it was not letting me offset from the beginning of the entire result set. (Maybe search results are specific to the page parameter, regardless if pagination is used.)

That said, and while it’s not exactly the same as what was originally brought up here, it would be nice if we could offset from base past 250 50 items, which should enable the functionality I needed to reach to JS for directly within Liquid — so that we would not need to inject items into the front of the product grid after the customer may have already seen what is there for use cases like I described.

Anyway, I figured I would share these thoughts on the off chance we could gain some new functionality regarding accessing subsets of items from resources. (Or the ability to prefilter them like the use of where: but with item indexes, start and stop, instead of a specific property value.)

(Edit: Originally I had put in 250 there but I believe it was really 50. I was testing with 2 CTA cards on the first 2 pages of products which when going through 3 pages, it was working but thinking back, with more testing I believe I found out it stopped working after that when testing using a collection with more products. I checked the old code and remembered the actual issue was at 50 and not 250 regarding the use of the offset.)

31

Hey @RobDukarski - thanks for sharing this and no worries. Just want to make sure I’m understanding your use case correctly.

It sounds like the main limitation you’re running into is with search results having a hard 50-item-per-page limit. That limit is documented behavior and you can see it mentioned in the search object docs.

If I’m understanding correctly, your feature request is around being able to access items across multiple pages (like offsetting from the beginning of the full result set) so you can insert CTA cards, etc inline without needing JavaScript?

Would having a higher page limit for search results solve your use case, or do you specifically need the ability to access items from previous pages within the current page context? Just wanted to make sure I was understanding things correctly here - hope to hear from you soon.

32

Hey @RobDukarski - just following up here to see if I can still help, let me know!

33

Hey @Alan_G,

Sorry for the delay! Both are needed I believe. We would need to be able to go for the previous page of results to grab the last X to display in front of the current page results. We would also need to be able to go past 50 (non-paginated, specifically offsetting from the first result) in order to make it work without JS. So it would be something like for item in search.results offset: 248 limit: 2 where we’re grabbing the next 2 items to display in front of the items for the current page.

If we could grab them upfront, something like assign skipped_results = search.results | where_by_index: 249, 2 that would grab 2 items starting at 249, which we calculate as (number of items per page * page number) - number of skipped items, making sure the number is within the total item count, of course.

Currently it does work with the JS approach, it is just that on slower connections, I am sure the cards would load in slower than they do when I test in my environment.

I also believe I could not really move the fetch code in the head because it utilizes the pagination and we’re limited to one paginated array per page load (unless we can reuse the same attempted one lower on the page — I have not tested).

(Another thought here is that I may not have tried to test a result set or collection that has exactly the number of products as the page size for the last page, where if I went to another page that does not have any matching results, to for example get 2 skipped results, it may not display something… Granted if it simply would not output any cards among the paginate, but still output the JS for fetching the skipped cards, then it may still work like I would want. I did a quick test of an extra page on one without a full last page and the count said 623 - 613 of 613, so I would at least need to adjust that part, granted there is currently no way of getting to an extra page there without manipulating the URL.)