Join GitHub today
Allow cascading Front Matter #6041
This issue adresses batch assignment of Front Matter values to descendants of any given content file and is inspired to some extend by the data assignment logic of https://github.com/11ty/eleventy.
Batch assign is already addressed here #5455 but from a single entry point.
Here, we would simply create a new reserved key in Front Matter underneath which any number of key/value pair could be cascaded through the page’s descendants.
Consider the following structure and content files' Front Matter:
├── _index.md ├── blog │ ├── _index.md │ ├── san-fransisco-series │ │ ├── _index.md │ │ ├── castro.md │ │ ├── lombard.md │ │ └── presidio.md │ └── moving-again.md └── contact.md
# content/_index.md title: Home cascade: banner: images/windows-bliss.jpg
# content/blog/_index.md title: Blog cascade: banner: images/typewriter.jpg
# content/blog/san-fransisco-series/_index.md title: San Fransisco cascade: banner: images/golden-gate-sunset.jpg
# content/blog/san-fransisco-series/lombard.md title: San Fransisco banner: images/herbie-lombard.jpg
Looking at the different content files above, and from within the template files,
They're safe as those "special" key/value pair would be stored in a reserved map.
On the other hand this could take care of #5652 and potentially other issues not yet identified.
How to overwrite with an empty value?
What if a page does not want a banner?
# /blog/rip-dear-celebrity title: Rest In Peace dear celebrity banner: false
It becomes the user responsibility to allow an empty or boolean overwrite to editors. I think it's a fair trade-off.
This for now does not solve the problem of batch assigning Front Matter to remote content, but it could if the user can create a content file matching the remote’s content section and store the section’s Front Matter (cascading or not) in there.
Sounds like a good idea. About the naming, how about
The name implies that all the parameters under
I like this very much, and as long as we restrict the
I think this should be able to solve some other long-standing issues:
It does not solve (my) primary motivation behind # #5455 -- which I vaguely remember as a way to batch-reorder pages (by setting
I’m glad you guys are on board.
@kaushalmodi, I’ll never get bored of discussing parameter names with you :)
I think such a feature should be called Cascading Front Matter because I believe everyone will instantly understand what this does just by reading those 3 words.
Hence using cascade as parameter.
But it’s also safer than
I would suspect someone somewhere is already using defaults in their front matter.
Also defaults are temporary values to be overwritten. Here they will rarely be (I suspect).
@regisphilibert a quick yes and no question to verify that we're in line here: The values defined in
You can, but it will not apply to the home page itself (we could of course decide to make an exception for the home page, which I guess would make sense).
I have a related question that, while testing this, surprised me a little. But I guess it is how it is going to be.
If you say for
cascade: outputs: [HTML]
It means that you want all the ancestors to output HTML only (unless overridden by front matter or another cascade).
But then you somewhere in the tree do something like this for
cascade: icon: "flag.png"
So, by adding the cascade with that
I don't think we can ... cascade (or merge) the cascades, so to speak. Or, not as the default behaviour. We can maybe add a
I thought they would merge.
I really see this as a parallel to CSS (and other) cascading mechanism. Everything from the ancestors' tree is kept unless overwritten.
If ultimately this is not possible, this will still be a very useful feature but maybe with a different name though.
OK, let's do that. There are maybe some potential issues with that, too, but probably less confusing than the other variant.
You would then maybe typically end up with something like this for a section:
title: "My Section icon: "flag.png" outputs: ["HTML"] type: "blog" cascade: icon: "flag.png" outputs: ["HTML"] type: "blog"
Which I guess is fine?
But not great I suppose.
If we go back to the CSS comparison,
It seems okay in this context that a regular FM would overwrite the section's
To use your example:
title: "My Section" icon: "world.png" cascade: icon: "flag.png" outputs: ["HTML"] type: "blog"
The section would send down the cascade the
Again, route A is fine as well, but will lead to more copy/paste than B I think.
I'm not sure I'm totally getting the CSS allegory, but both B and my initial question about "to merge the cascades" or not have the same problem in that it's not possible to delete elements set in the cascade, you need to somehow set a zero value, e.g.:
title: "My Section" icon: "" # I don't want an icon cascade: icon: "flag.png" outputs: ["HTML"] type: "blog"
title: "My Section" icon: "flag.png" cascade: icon: "" # I don't want my ancestors to have an icon. outputs: ["HTML"] type: "blog"
But the above avoids the most copy/paste and I suspect is the least surprising. So I suggest: