I love the flexibility this plugin offers and I hope I can use it for our website!
One real problem I found so far though. Our layouts are nested, roughly something like:
Page, contains layout: specific
/_layouts/specific.html: contains layout: general and show_banner: false
/_layouts/general.html
In general.html we check frontmatter properties from the specific layout like {% unless layout.show_banner == false %}.
With pages that are created by the data page generator, such a check no longer works. However, I can access the value via page.show_banner! The workaround would be to update the various levels of nesting with the properties in the layout we're using for the data-generated pages. Then the check would be % unless layout.show_banner == false or page.show_banner == false %}.
As I'm not looking forward to adding that extra check, I'm wondering, is this behavior intentional and reliable? is this perhaps just how Jekyll works, like "the highest level must be a page, even if there's no file for it"?
I love the flexibility this plugin offers and I hope I can use it for our website!
One real problem I found so far though. Our layouts are nested, roughly something like:
Page, contains
layout: specific/_layouts/specific.html: containslayout: generalandshow_banner: false/_layouts/general.htmlIn general.html we check frontmatter properties from the specific layout like
{% unless layout.show_banner == false %}.With pages that are created by the data page generator, such a check no longer works. However, I can access the value via
page.show_banner! The workaround would be to update the various levels of nesting with the properties in the layout we're using for the data-generated pages. Then the check would be% unless layout.show_banner == false or page.show_banner == false %}.As I'm not looking forward to adding that extra check, I'm wondering, is this behavior intentional and reliable? is this perhaps just how Jekyll works, like "the highest level must be a page, even if there's no file for it"?