-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Add the [params] concept to front matter #11055
Comments
Makes sense to me. I have seen things like this in the wild
So, to be backwards compatible, predefined fields (in the root of front matter) need to be available under Taxonomy termsWhich would be the correct way?
or
or
|
Another thing to watch out for. If you define the summary in front matter, and then use the .Summary method in a template, it returns the rendered summary, not the raw field value. To get the raw field value, you currently have to use |
This is deliberately very simple, but should not break anything. We need to introduce this in baby steps, but this should allow us to introduce this in the documentation. Note that the `params` section's key/values will be added to `.Params` last. This means that you can have different values for "Hugo's summary" and the custom ".Params.summary" if you want to. Updates gohugoio#11055
This is deliberately very simple, but should not break anything. We need to introduce this in baby steps, but this should allow us to introduce this in the documentation. Note that the `params` section's key/values will be added to `.Params` last. This means that you can have different values for "Hugo's summary" and the custom ".Params.summary" if you want to. Updates gohugoio#11055
This is deliberately very simple, but should not break anything. We need to introduce this in baby steps, but this should allow us to introduce this in the documentation. Note that the `params` section's key/values will be added to `.Params` last. This means that you can have different values for "Hugo's summary" and the custom ".Params.summary" if you want to. Updates gohugoio#11055
This is deliberately very simple, but should not break anything. We need to introduce this in baby steps, but this should allow us to introduce this in the documentation. Note that the `params` section's key/values will be added to `.Params` last. This means that you can have different values for "Hugo's summary" and the custom ".Params.summary" if you want to. Updates #11055
I'm marking this as closed for now, I'll create another issue(s) for following up work. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Note that this is
We had a similar situation in
language.params
, where we allowed custom params at the top level. Now we warn about that and we will eventually remove that option.So, from a documentation standpoint (API spec) this is problematic because it's hard to define which fields that makes up the API when "field A, B, C are Hugo configuration, all the rest are params".
So this proposal suggest that we from a documentation standpoint encourages front matter on the form:
And just to make this clear, this would also continue to work:
The "world" is a little more complicated than the above, but let us keep it simple for now.
/cc @jmooring
The text was updated successfully, but these errors were encountered: