ByParam not playing well with pagination

This took me hours to debug. Related to ByParam not playing well with pagination · Issue #12986 · gohugoio/hugo · GitHub

Please run GitHub - ka259/hugo-test and see the error about paginate. Removing the .Pages from the head.html file ()).Pages) and the error disappears. Why is the .Pages part throwing an error? (See layouts/items/list.html also where the code is used)

In the head you want the Pager, not the Pages.

{{- if or (and (.IsSection) (eq .Section "items"))}}
  {{- $paginator = .Paginate ($pages.ByParam "price") }}
{{- end }}

Keeping the rest of the code produces different canonicals

Page 1: <link rel="canonical" href="http://localhost:1313/items/">
Page 2: <link rel="canonical" href="http://localhost:1313/items/page/2/">

Hint: your code paginates twice with the same settings. (baseof and head) Thats ok but be aware of the hint on caching and paginate once in the docs. Just if you try to paginate later with different settings…

Please note that the results of pagination are cached. Once you have invoked either the Paginator or Paginate method, the paginated collection is immutable. Additional invocations of these methods will have no effect.

The limitation of Hugo’s Permalink necessitates running paginate twice in the head and list page.

Is there a section in the docs that references the pagers thing?

This may not address your setup, but it’s a better way to meet the objective described in #4507.

https://discourse.gohugo.io/t/pagination-using-pager-values-within-the-head-element/50340

From the date of the post you can see that this only occurred to me a few months ago, and it’s much simpler than earlier approaches described by me and other forum users.

Cmon. The docs are not that bad. :wink:

First hit in search for “Pager”

I actually tried it, but more errors popped up due to the .Pages part (two errors in fact), so I referenced the github issue and tried the solution in my test site. One error if I remember was the .Pages inside the with code in layouts and hugo wouldn’t recognize it. But now that I know the pager is only what is required, I will give it another test.

As I said, my question was why the .Pages part is triggering the error. I just need a clear and concise answer. (I am working on someone’s project and I chose Hugo over other SSGs basically for this project)

sry, missed to scan up to your first and “the pages thing” could be…

ERROR render of "section" failed: "C:\_repos\github\clone\topic-52202\layouts\_default\baseof.html:4:5": execute of template failed: template: items/list.html:4:5: executing "items/list.html" at <partial "head.html" .>: error calling partial: "C:\_repos\github\clone\topic-52202\layouts\partials\head.html:9:24": execute of template failed: template: partials/head.html:9:24: executing "partials/head.html" at <$paginator.PageNumber>: 

can't evaluate field PageNumber in type page.Pages

If you talk about documentation which exact error messages could be thrown

No, I don’t think so. Docs state often if … “hugo will fail the build”

If you want to know why it fails

You cannot access the field or method of an object if that method does not exist

and that is the Hugo way to handle this:

  • report the error
  • break the build

hard to tell how deep I should explain if that above does not answer your question cause I don’t know your background.


TL;TR

{{- $pages := .Pages }}
{{- $paginator = (.Paginate ($pages.ByParam "price")).Pages }}
  • . (dot) is the current Page
  • Pages is a Method defined for a Page-Object which returns a Pages-Object
  • So $pages is of type “Pages” which holds a “Collection of Pages”

Each Hugo docs page of an object describes available methods and it’s return values. Follow that chain in the lines of code (inner parentheses to outer)

You will see $paginator in the code is a “Collection of Pages” Object - If you check the docs for “Pages”, this does not have a Field/Method named “PageNumber”.

so it will fail.

template basics at Go template functions, operators, and statements | Hugo which references the underlying go templating packages

Not sure if that helps in any way or is even connected, but I have an init-partial that does create the pagination and stuffs it into a scratch and then retrieves it where ever needed. Running paginate twice is not needed.

create the pagination object and stash it:

retrieve the pagination object and use it:

@irkode I have a few Hugo sites I did for friends for fun, but I am just learning the basics of dev. So, the familiarity with terms is not there yet. So, I understand that the call of paginate ‘being similar’ to avoid caching does not necessarily mean I copy what’s in the list file directly to the head file.

@davidsneighbour you should probably check @jmooring’s example. With the limited understanding I have from the docs, am not a big fan of scratch over store.

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