-
Notifications
You must be signed in to change notification settings - Fork 991
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow not rendering pages #2388
Conversation
a144c3f
to
3c8284a
Compare
Can you split the refactoring in another PR? |
Just to clarify, which specific refactorings? I am fine with just merging the first two commits if that's what you mean, or I could modify the latter three commits to remove |
@@ -39,6 +39,11 @@ pub struct PageFrontMatter { | |||
pub datetime_tuple: Option<(i32, u8, u8)>, | |||
/// Whether this page is a draft | |||
pub draft: bool, | |||
/// Whether to render the page or not. Defaults to `true`. | |||
/// Useful when the page is only there to organize things but is not meant |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does it mean to have a page to organize things?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not quite sure the best way to word things. One example of something I use it for is my CV - I have jobs as different non-rendered pages in a non-rendered section and just output them directly onto the template for the parent section. This way, it's organised into different parts but this doesn't affect the final output.
Basically split the render = false and the rest in 2 different PRs |
3c8284a
to
f3c63d6
Compare
Alright, I'll just start with the first two commits for now. Those are now #2407. |
f3c63d6
to
72801c3
Compare
Going to close this for now, will provide another PR when I come up with a better version. |
next
branch?Depends on #2407.
render = false
First, this updates the meaning of
render = false
:SITE_CONTENT
instead of disk (the big change)This means that
zola serve
will still render non-rendered content, although I consider this mostly a benefit to debugging, not an issue. Sincezola serve
is not intended for anything besides local development, I consider this a reasonable compromise.The way I actually implemented this change was by simply updating
write_content
to allow writing toSITE_CONTENT
even if it's run underzola build
, so that non-rendered pages, sections, and taxonomies can still be accessed, but aren't actually written to disk. This helps ensure that things are more consistent (you don't have to break at the right point in a function) and hopefully things just work how people expect.Exposure to templates
This was another thing I added after realising that, since
render = false
doesn't affect creating permalinks at all (and probably shouldn't), it would be nice for templates to be able to detect whether a page/section is rendered so they can avoid linking things. So, templates now have access to therender
variable, which is defaulted to true so you can just checkpage.render
, etc.Explanation
Right now, the reasoning behind
render = false
for sections is so that people can useget_section
orget_page
internally without actually rendering pages for things. So, by this logic, ensuring that these rendered pages show up inSITE_CONTENT
feels like the most straightforward way of doing things.