Can we modify frontmatter cascade values via config?

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 documentation by putting them in “internal” subfolders, and use draft = “true” in the cascade block:

title = "Home"
linkTitle = "Home"
  draft = "true"
  path = "/**/internal/**"

The howto I’m still looking for is how I can influence the draft value with a parameter in the config.toml file, or another smart way to set a different value depending on the environment setting (hugo --environment ).

I tried shortcodes inside the frontmatter, but that area of a content file seems not in scope of shortcodes.
Or is it somehow possible to define cascade constructs outside a content file frontmatter?

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 via site.Params.parametername. That you can use to override the frontmatter parameter.

in toml frontmatter:

myparam = false

in config.toml

myglobalparam = true

in your shortcode

{{ if site.Params.myglobalparam }}
// do something
{{ else if .Params.myparam }}
// do something else
{{ else }}
// fallback if none is true
{{ end }}

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 environment used) this is not sufficient. In best case you still end-up with empty but still generated index.html files, and the 404 error is not triggered validating the page URL.

Only the following in the toml frontmatter will avoid the generation of the index.html page and drops the hyperlinks to it in the different list pages, RSS, etc. , using hugo or hugo server (without the -D flag):

draft = "true"

The only way I found to do this recursive on multiple places is with this construct in the home page toml frontmatter, the “draft = true” is only applied to “internal” subfolders of the /content directory:

  draft = "true"
  path = "/**/internal/**"

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 what you are trying to accomplish. It might be solvable completely different.

You currently cannot do this.

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 [[cascade]] block to make the purpose more clear.
But I have to document this well, because it impacts more than only draft pages.

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 it as a data format in Hugo.

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 it proper. Now it is a mix of config.toml and home.Params.

This is realllyyy niceee,
if we can use cascade _target options via config file. :exploding_head:
setting page params without editing each content files, only need one place in the config file.

See Add config.cascade by bep · Pull Request #8742 · gohugoio/hugo · GitHub

@pamubay yes, you can.