I have a site that will utilise a similar setup to the one described here. Isnβt there a way to cascade from _index.md file instead of hugo.toml? Since I would hate to clutter my configuration file with tens or hundreds of these entries.
when testing this one Conditionally hide section of site not working
i found no problem when cascading from using _index.md
. except if you have a multilingual site. In that case you would have to duplicate the cascades to every languages _index.html
you may switch to a
config` directory which a- as of the docs - could have a separate cascade config file
I actually tested a cascade.toml
file in the config directory but it does not work. I am assuming from the docs that such a file is possible?
[cascade.build]
list = 'never'
publishResources = false
render = 'never'
[cascade._target]
path = '{/glossary,/glossary/**}'
lang = '*'
shouldnβt you omit the root key?
You are correct, but now another issue arises with toml. For example, I have a build and a params key. Using _target
throws an error unmarshal failed: toml: table _target already exists
.
[build]
list = 'never'
publishResources = false
render = 'never'
[_target]
path = '{/glossary,/glossary/**}'
lang = '*'
[params]
foo = 'bar'
[_target]
path = '/books/fiction/**'
You must define cascades in the root config file (e.g., hugo.toml). See:
https://github.com/gohugoio/hugo/issues/12899
Bummer! And the fact that it is set to unscheduled means it will not be acted upon anytime soon.
Well, itβs open sourceβ¦
And the beauty of it is that there are other solutions out there . I will see if I can restructure the site or find another solution out of Hugo.
Out of curiousity, why canβt you place the cascade
tables in config/_default/hugo.toml
?
Will that work with the default hugo.toml in root? If it works, then I will go with that. I just didnβt want to clutter the root one.
If you are asking, βDoes this work?β
project
βββ config/
β βββ _default/
β βββ hugo.toml
βββ hugo.toml <-- cascade tables here
The answer is, βYes.β
However, I find that confusing.
Getting back to the original problem, why would your file be cluttered? Or to put it another way, why would you need hundreds of cascade
tables?
Like in the link post shared, somehow a decision was made at a place I volunteer to group together some content and I presented the multipage posts solution you shared in another post. However, they wanted again to break that content down like in the linked forum post so that similar content share different titles across different folders in the multipage bundle. I tried that trick and it worked, but when we are talking about more than one multilingual posts, those cascades will add up. Hence my concern about cluttering the hugo.toml at root (and back to my first post about using _index.md to cascade instead).
I donβt understand the above, but needing hundreds of cascade values to make it work suggests a design flaw.
My thoughts too. But I cannot find a solution yet. So, for now, Hugo might be limited to what we thought we wanted with this project.
content/
βββ books/
β βββ fiction/
β β βββ book-1.md
β β βββ book-2.md
β βββ non-fiction/
β β βββ book-3.md
β β βββ book-4.md
β βββ _index.md
βββ _index.md
I was thinking of doing this but books becomes a nested section of a section. then other pages will be branch bundles in the same structure. So, posts/books
, news/books
, etc.
So, we will only operate with branch bundles as pages, not leaf bundles.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.