New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Page.Params more consistently when adding metadata #3033

Merged
merged 1 commit into from Feb 21, 2017

Conversation

Projects
None yet
2 participants
@fj
Contributor

fj commented Feb 12, 2017

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 by Page fields generally don't wind up in .Params. But this has exceptions -- for instance, Description is both a Page field and will be present in Params, even though the documentation says it won't be present in Params.

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 no date stored in Params, even though date 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.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Feb 19, 2017

Member

I agree that this is a good change, but it would be good to get the heads up from some others ... @digitalcraftsman @moorereason ?

Member

bep commented Feb 19, 2017

I agree that this is a good change, but it would be good to get the heads up from some others ... @digitalcraftsman @moorereason ?

@fj

This comment has been minimized.

Show comment
Hide comment
@fj

fj Feb 19, 2017

Contributor

Note: I've updated this branch to remove the conflicts that arose from the Test.Parallel enhancements. If there's anything else I need to do to make this qualify for 0.19 please let me know.

Contributor

fj commented Feb 19, 2017

Note: I've updated this branch to remove the conflicts that arose from the Test.Parallel enhancements. If there's anything else I need to do to make this qualify for 0.19 please let me know.

@bep bep merged commit df1ff57 into gohugoio:master Feb 21, 2017

3 of 4 checks passed

continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/wercker Wercker build passed
Details
licence/cla Contributor License Agreement is signed.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment