Control pagination and page collections from baseof.html

From this comment, look into base templates and blocks and make sure it is created with the params you want before you access it. How is this done? Can’t find anything in the docs. For example, I want to pass a global paginate for homepage and another for section templates.

I haven’t read through the parent issue, but you can probably have 2 flavors of paginate saved as partials. You can then use the page object’s .IsHome variable to check if the page is a homepage and call the partial you designed for pagination on homepage. Otherwise if .IsSection (also a variable in the page object) is true, you call the other partial you designed for pagination on sections.

I want to use the pagination more than once on the same page (for canonical URL and content). Will this work? (Edit: didn’t work. one pagination is broken. I am looking for something similar to this. I am trying to get around this issue.)

No. Paginate is restricted to one single item per page.

Once it ran it’s done and any subsequent call will use the same result. This is due to it’s resource-hunger. I have a site with around 2k posts and was paginating through them (number pagination, 10 items per page). that took 3 to 6 minutes until i removed it and just started using next/prev navigation.

Create your own pagination with a partial that runs through a selection of pages. Select the pages with where and in and all these nifty section commands. Hand a dict containing pages to that partial, then do some magic (total number of items, items per page, current page as parameters) and find a way to cache that properly, because it will be a very time intense procedure.

An idea: Maybe the newly introduced page.Store (very undocumented) might be helpful. It works like a page scratch that is saved over the whole hugo run, if I get that right. I have the feeling that might be in some magical way useful for this.

There will always be the issue, that you don’t know which page Hugo will run first - so using paginate will still not work here, but the times to create the pages-object you want to create a pagination for and the main variables you want to create might be done once and cached and independent of the amount of pages you want that created for. Maybe. Didn not use page.Store yet.

But in the end: There is the point of usability: what is the reason for this pagination? How would people use it (hint: they don’t, my number pagination was never used, only the next/prev arrows on it).


@anon44707125 Apologies for the incorrect info.


We improved the performance of the internal pagination template about 9 months ago: See the “Performance” section. Adding pagination to a 10,000 page site increased the build time from 1.8 seconds to 2.1 seconds (based on a average of 3 runs).


True. I changed that over a year ago and never checked with a recent version. Probably should try that out. Doesn’t change though that a page 1, page 2, page 3 etc pagination does not make much sense in a 2000 blogpost site. It’s a nice feature, but nobody will have any use of it. Just because it works does not mean it brings any additional value to a site. I wonder what Jacob Nielsen thinks about that… let me google…


git clone --single-branch -b hugo-forum-topic-37643 hugo-forum-topic-37643
cd hugo-forum-topic-37643
hugo server

To verify that we’re not clobbering our pagination parameters:

  • The articles list page will show 3 articles per pager, by title
  • The books list page will show 5 books per pager, by title (reversed)
  • The films list page will show 7 films per pager, by date
  • The quotations list page will not be paginated


At the top of the file we define our pagination strategy, by section, for the entire site. This means that later on in the file we have access to the paginator properties (e.g., the current pager number, total number of pagers, etc.).


Uses a conditional to define the page collection, mirroring the logic used in layouts/_default/baseof.html.


While this is functional, it makes pagination a “site wide” feature, instead of something you can just add when needed on any given list page. For example, with this approach, you cannot easily split an article into multiple pages using this method.



Still need an answer if this is possible. If not, I decide what to do next. I have discovered all my related questions are about wanting to define two different paginations on the same page.

Do you understand “No. Paginate is restricted to one single item per page.” ?

Only if this issue is resolved, and all this headache would be over.

Try the example I posted. There are some edge-case limitations, but no headache.

My case involves the canonical URL in <head></head> and this example you shared. I still get build errors if or the cached pagination breaks either the canonical or the number of items in the first page.

Have you cloned and built the example that I posted above?

If no, please do so.
If yes, please explain what is missing.

1 Like

I just got it to work through trial and error, thanks to @jmooring’s test site. I am not sure how I got it to work, but until I do, I will mark his answer as the solution.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.