Error calling GroupByParam: there is no such param

support
1

Not sure what to make of this one. This:

{{ range site.Pages.GroupByParam "pin" }}
    {{ . }}
{{ end }}

causes an error:

Error: 
error building site: render: 
failed to render pages: 
render of "taxonomy" failed: "/Users/will/Developer/paige/layouts/_default/list.html:5:3": 
execute of template failed: 
template: _default/list.html:5:3: 
executing "main" at <partial "paige/pages.html" $page>: 
error calling partial: "/Users/will/Developer/paige/layouts/partials/paige/pages.html:27:13": 
execute of template failed: template: 
partials/paige/pages.html:27:13: 
executing "partials/paige/pages.html" at <site.Pages.GroupByParam>: 
error calling GroupByParam: there is no such param

It also fails for a .Pages value for a list page.

I copied the above code from one of @jmooring’s comments here. It should work.

Note that ByParam does work:

{{ range site.Pages.ByParam "pin" }}
    {{ . }}
{{ end }}

Searched all over this site. Couldn’t find an answer.

2

I suspect you have a site where none of the pages have pin set in front matter (e.g., a brand new empty site).

You can handle this by coding defensively:

{{ with where site.Pages "Params.pin" "ne" nil }}
  {{ range .GroupByParam "pin" }}
    {{ . }}
  {{ end }}
{{ end }}

Comments:

  1. The GroupByParamDate function doesn’t care if the parameter is defined anywhere. I expected the same behavior as GroupByParam.
  2. Should you have to code defensively if the parameter is not defined anywhere? I don’t think so given (a) the above, and (b) sorting ByParam doesn’t care either.

This should be logged as a proposal. I guess we should return nil. See:

The PR above has been merged. The fix will be available in the next release.

Although coding defensively is preferable until the above is changed, you could also cascade a default value down to all pages, something like:

[[cascade]]
  [cascade.params]
    pin = false
  [cascade._target]
    path = "**"

This is just a little bit related, but good to keep in mind:
https://github.com/gohugoio/hugo/issues/12289

3

Yep.

You can handle this by coding defensively:

Unfortunately, that won’t work in this case. The point was to have the pages grouped into “pinned” and “unpinned” (nil means unpinned). That code will only group true and false values (and there probably won’t be any false values, just nil values, so there will only be one group). So the whole point of GroupByParam is negated in this case, unfortunately. Perhaps if the field type had more cardinality than the Boolean type, this approach could still be useful.

This is just a little bit related, but good to keep in mind:

I was sorry to see that wasn’t supported yet, because in my case, the attribute is “paige.pin”, not just “pin”.

4

This is where cascading will help. Regardless, this is fixed in the next release.

5

Excellent!

6

Thank you!

1 Like
7

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