Use Page.Params more consistently when adding metadata #3033
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Right now,
.Params
is documented as being "everything you put into the frontmatter, except for a long list of specific variables". In particular, values which are otherwise subsumed byPage
fields generally don't wind up in.Params
. But this has exceptions -- for instance,Description
is both aPage
field and will be present inParams
, even though the documentation says it won't be present inParams
.The net result is that it's a little confusing and inconsistent about what does or does not wind up in
Params
.This problem makes it difficult to use certain other Hugo functions in your templates. For example, one cannot do
{{ .Param "date" }}
because there is nodate
stored inParams
, even thoughdate
is in your frontmatter. That means that if you invoke such values dynamically, e.g.,{{ .Param $k }}
, you can't be sure if it will work, even if$k
is the name of a valid key in your frontmatter.I think a more consistent and less surprising result is that
Params
should match your frontmatter as closely as possible. This PR attempts to fix this by making sure such assignments always happen.