I’m already very pleased with the (multiple) cascade with filters feature (Hugo 0.76), to influence build options for certain sections in a documentation website I’m building. With this small cascade block in the frontmatter of the home page, I can simply drop internal sections from the documentati…

The “overwriting” of these variables is only possible in one direction, and having config.toml override somehow folders is the wrong direction. You could work with a shortcode. You send it the . (which has the page and with that it’s params (= frontmatter) and then retrieve the config parameters vi…

Hi @davidsneighbour , thanks for your suggestion. But I investigated this one already. I case of modifying content on pages this is indeed a possible way. But in case you just don’t want page(s) or section(s) be available in the final build under certain conditions (or depending on the hugo environ…

Hmm. I am pretty sure we talk across each other :slight_smile: I am saying that “recursive” means DOWN THE RABBITHOLE. You can’t override in config.toml, what you define in frontmatter. Only the other way around. Also, with some sample code and a real world example it might be easier to understand …

Thanks for the confirmation @bep Is this use case worthwhile an enhancement request? Or do you have this somehow already covered in other plans? For now I can enable/disable the expected outcome by using the hugo -D flag or not in a certain environment. And maybe add a dedicated taxonomy in the […

[image] pschrey: Is this use case worthwhile an enhancement request? Yes, but I think there are similar requests in already. The main problem is, YAML isn’t very scriptable and I would hate to come up some custom syntax … That said, I’m waiting for this project to mature enough so we can use…

[image] bep: What we could consider, though, thinking about it, would be to have a cascade block in config.toml (which would be the top top level cascade block). Would that solve your case? Oh yes :slight_smile: In that case I can keep all configuration parameters in one place, and document i…

[image] bep: What we could consider, though, thinking about it, would be to have a cascade block in config.toml (which would be the top top level cascade block). Would that solve your case? This is realllyyy niceee, if we can use cascade _target options via config file. :exploding_head: set…

See Add config.cascade by bep · Pull Request #8742 · gohugoio/hugo · GitHub @pamubay yes, you can.

Can we modify frontmatter cascade values via config?

support

pschrey July 9, 2021, 6:48am 8

Oh yes In that case I can keep all configuration parameters in one place, and document it proper. Now it is a mix of config.toml and home.Params.

Topic		Replies	Views
How to set all md files front matter draft false default ,in config file or other method? support	3	1387	January 18, 2023
Why frontmatter in config doesn't support custom params? support	15	1038	September 30, 2019
How to target pages within cascades (config) according to a frontmatter parameter? support	7	248	March 15, 2024
Define draft variable in config.toml support	2	80	September 27, 2024
How to create the cascade in front matter and display them in html or in netlify config support	0	435	March 6, 2020

Can we modify frontmatter cascade values via config?

Related topics