Pages in unrendered sections still get rendered

[paulcmal]

While trying out a weird-and-modular footer architecture i encountered an unexpected behavior. In my content folder i have a _common folder containing an _index.md and a footer.md page. The index page has a render = false setting in frontmatter and therefore http://127.0.0.1:1111/_common/ returns a 404 (as expected).

However, gutenberg actually renders the footer.md page. So first it failed to build the site because i had not set a date setting in the footer page's frontmatter:

Error: Failed to render page '/home/user/Sites/Gutenberg/content/_common/footer.md'
Reason: Failed to render 'even/templates/page.html': error while rendering a macro from the `post_macros` namespace
Reason: Filter `date` received an incorrect type for arg `value`: got `Null` but expected i64|u64|String

When i set the date in footer.md, the site built properly and http://127.0.0.1:1111/_common/footer/ was actually generated and published.

I believe the expected (yet undocumented) behavior of render = false in a section would be to not render any of its children pages, either. So i consider this a bug :)

[Keats]

That's expected, render = false only affects the rendering of the section index page itself. It's used when a section is only there for organisation purpose but you don't want to actually render an empty page

…

On Tue, 14 Aug 2018, 19:12 cmal, ***@***.***> wrote: While trying out a weird-and-modular footer architecture <#111 (comment)> i encountered an unexpected behavior. In my content folder i have a _common folder containing an _index.md and a footer.md page. The index page has a render = false setting in frontmatter and therefore http://127.0.0.1:1111/_common/ returns a 404 (as expected). However, gutenberg actually renders the footer.md page. So first it failed to build the site because i had not set a date setting in the footer page's frontmatter: Error: Failed to render page '/home/user/Sites/Gutenberg/content/_common/footer.md' Reason: Failed to render 'even/templates/page.html': error while rendering a macro from the `post_macros` namespace Reason: Filter `date` received an incorrect type for arg `value`: got `Null` but expected i64|u64|String When i set the date in footer.md, the site built properly and http://127.0.0.1:1111/_common/footer/ was actually generated and published. I believe the expected (yet undocumented) behavior of render = false in a section would be to not render any of its children pages, either. So i consider this a bug :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#373>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApho7wKD-cAc3ObUWqUwyx8fWjUE3EHks5uQwT5gaJpZM4V81Pn> .

[paulcmal]

Thanks for the explanation, i just took a look at the code and i can see that. I'll try to write something more clear in the docs about it.

So if i'm correct, something along the lines of headless bundles (as they're called in hugo) is not supported at the moment in Gutenberg?

Could this be implemented by either having the render setting work as i expected it, and allowing overwriting it in children sections/pages (breaking change but more consistent imho), or by having a separate render_children setting in sections? Or a mix of both (such as render = false and render_children = true to address your use-case)?

I'd be willing to try and contribute to this feature :)

[Keats]

So if i'm correct, something along the lines of headless bundles (as they're called in hugo) is not supported at the moment in Gutenberg?

Yeah it isn't supported and I'm not sure I see the point in them? What is the usecase for a headless bundle?

[Keats]

@paulcmal ping, still not sure what's the point of headless bundles after looking at the Hugo docs

[paulcmal]

Well, the idea is to bundle textual content (markdown-rendered) with assets (such as images). This way you can make whole parts of your website editable/translatable (← i18n integration is key to the usage) without having untechnical people edit the templates directly. That's at least my understanding and usage of the feature.

That works for footer content, for instance. Or for a banner that you would like displayed across different pages, but not all. Or for just any piece of reusable content that you would like to be editable directly in Markdown and to be associated with assets. I believe if you have a whole markdown rendering and user-friendly tools ready to go, it would be a miss to only use them for article bodies :)

Actually, I just reread the section docs and i think what i'm trying to do is to have a way to have orphan pages not be included in the public/ folder output? It would be nice, but i think it's just a detail in the end. Unless they guess the path of the orphan page, the result is the same to an end-user, isn't it?

[Keats]

That works for footer content, for instance. Or for a banner that you would like displayed across different pages, but not all. Or for just any piece of reusable content that you would like to be editable directly in Markdown and to be associated with assets. I believe if you have a whole markdown rendering and user-friendly tools ready to go, it would be a miss to only use them for article bodies :)

Hm you can use blocks/macros/shortcodes for that. There is a markdown filter so you can render markdown from templates as well.

Unless they guess the path of the orphan page, the result is the same to an end-user, isn't it?

They will be present in the sitemaps so users could potentially see them but not really a problem in practice.

I'm not planning to add headless bundles as there are ways to do it already so closing this.

[yacoob]

I found a use case for this behavior: with a structure of content like this one I'd like to render just one html page for the whole section at /hg/exia/index.html and skip all of the individual /hg/exia/foo/index.html pages. Having render_children = false would allow me to achieve that.