`draft` field does not draft an article.

[ozkxr]

Bug Report

I'm not sure this is a bug. I think I'm doing something wrong. I will apreciate any help.

Environment

Zola version: 0.8.0 System: Windows 10 with WSL (Ubuntu)

Expected Behavior

It should not render draft pages. (?)

Current Behavior

It render draft pages when I use {% for page in section.pages %} in a section or index.

Step to reproduce

• Create a Zola website.
• Create a index.md template and use {% for page in section.pages %} to list pages.
• Put draft = true in a markdown file in the content directory to try to draft it.
• $ zola serve

This is my code

The index.html

{% extends "base.html" %}

{% block content %}
<section>
  <ul>
  {% for page in section.pages %}
    <li><a href="{{ page.permalink }}">{{ page.title }}</a></li>
  {% endfor %}
  </ul>
</section>
{% endblock content %}

My _index.md under content/

+++
+++

And the article itself, also under content/:

+++
title = "Article 1"
draft = true
date = 2019-07-10T14:00:00-06:00
+++

This is the content of article one.

[Keats]

argh looks like I forgot to filter out draft pages when serializing sections

[Keats]

On a second thought, it is working as intended: a draft page is not present in sitemap/rss/pagination but is present as a section child and you can filter them out in the templates with an if

[ozkxr]

So, Should I filter out manually? What's the best way to do that?

EDIT:

I've tried this: {% for page in section.pages | filter(attribute="draft", value=false) %} And yes, it works. The index doesn't lists the page anymore but the page itself is still generated. I mean, if I visit the URL of the page, the page still appears.

[Keats]

Hmm I don't use draft myself but don't you want to actually look at it while working on it? If it's not generated then you can't do that.

[ozkxr]

My workaround was to move my drafts out of the content dir. I think that will do it for a while.

[awulkan]

@Keats I think this is a big problem, with an accident just waiting to happen as more people and companies start using Zola. Pages that are in draft gets published when the site is built, which means they end up on the Internet. And it's not too far fetched to imagine that they could be indexed into search engines or found by visitors.

This can result in leaked information that wasn't supposed to be found by the public until you decide to publish it. Such as product announcements, private information, or similar.

I guess you could be really defensive and have an if statement that prevents draft page content from being rendered, but then you would have to toggle the draft value in the markdown file during editing, which is pretty easy to forget to put back again. It would be really nice to have some way of not even creating the page when building the website for production.

Maybe by making the draft key determine if the page should be rendered for production, or by having another key like "render", which can be true or false. I don't see a reason why a draft page should ever end up in the released website.

I would help implement a solution to this, but unfortunately I'm still very new to Rust. Maybe in the future unless someone else beats me to it. Because I really do think it should be addressed as soon as possible.

Also, by handling the problem at build time, you no longer need to clutter your templates with if statements to prevent draft pages from being listed when looping a section's pages.

[Keats]

So a draft shouldn't get loaded at all in Zola? That's easy to change if so (just discard any page with draft = True when loading them) but are people not using the rendered version while they write it?

[onelson]

I struggled with this a bit myself in zola.

The workflow with jekyll is what I expected, but didn't find. It basically works like this:

• While authoring via the local "serve" drafts are rendered like any other article.
• When "building" the static output, drafts are withheld from rendering and linking unless a flag is passed to include them.

I worked around this by adding a filter to the index template to omit items when drafts is True AND a custom config setting is True, then I use a different config for local vs deploy, which is sort of annoying to have to keep the two in sync.

I think it'd be great to have better support provided out of the box for this sort of "double standard" for rendered output.

[awulkan]

@Keats Drafts should optimally get loaded during development, but not included when building. How do you discard a draft page during the production build only?

[Keats]

There are currently no differences between build & serve other than the base URL, I'm a bit reluctant to change that aspect :/

[awulkan]

Then the developer has to manually implement a bunch of if statements and redirects to 404 pages to block draft posts manually. And if they do that, they can't see the drafts during development. I don't know of any other static site generator that renders draft pages in the final build. Draft usually means "do not publish". But Zola publishes it anyway, and I don't think most developers realize this. And I don't think it's a good idea to do it.

[Keats]

By having different mode for dev/publish you end up with issues like using an internal link working in serve but failing in build because the page is not loaded in that case. I would rather not load draft pages at all but again, my drafts are on git branches so I don't use draft (https://github.com/Keats/vincentprouillet/commit/c5db5e8fde18145879f61d959b4a13b1c607c0e6 was probably me testing the new filter Tera filter)

[awulkan]

If someone links to a draft page, then that's a user error and easily fixed.

But preventing draft pages from being published is very daunting (impossible?) right now. No one expects a draft page to make it into production in my experience. In what scenario would you want an unfinished page to be exposed publicly?

That filter in your theme won't stop draft pages from being published.

[Keats]

I stopped loading the drafts in the commit above in the next branch, very basic but at least it ensures drafts are not rendered.

[awulkan]

@Keats Thanks, you're the best.

Edit: Does this mean we won't see them during development? It's still better this way I think, but maybe they should be visible during zola serve. I guess it's a matter of taste.

I'm fine with the current solution, even though it requires me to toggle the draft field between true and false when editing. At least it wont be rendered now in production.

[Keats]

I've just added some modes to Zola (build,serve,check) for conditional logging in zola check and adding drafts was only a few characters. Can someone try the next branch to see if it fits the expectation? I'll update the docs afterwards if so.

[awulkan]

I tried compiling on Windows 10, but sass-sys failed. https://gist.github.com/awulkan/3690c1c6c23db9f6a72b521a510f41ba

I have the latest VS 2019 version with these tools installed: MSVC v142 - VS 2019 C++ x64/x86 build tools (v14.21) C++ CMake tools for Windows C++ ATL for v142 build tools (x86 & x64) C++/CLI support for v142 build tools (14.21)

I'll try again tomorrow if no one else has by then. Maybe I'll have to install some other tools.

[Keats]

The build tools for v142 (Platform Toolset = 'v142') cannot be found. To build using the v142 build tools, please install v142 build tools

Never seen that one before, I can't help you there :/

[norcalli]

I should probably make a new issue for this, but it's related to this discussion. I ran into what I thought was a bug, but I figured it out. I had an entry set to draft = true onaccident, and it caused a problem on building Reason:get_taxonomy_url: couldn't findsnippetsintagstaxonomy, which was actually due to the page being attempted to be rendered, and so page.taxonomies.tags was populated, but get_taxonomy_url errors since it's a draft and the only page with those tags.

On this topic of draft visibility, what is your opinion on how to handle this behaviour?

I personally found it surpising, and think this should still return correctly from get_taxonomy_url even if it is comprised solely of drafts.

[Keats]

Now that drafts are only loaded in serve, I can probably remove all the other drafts check of the codebase and it should work as expected.

[awulkan]

I can't get it working on Windows. Someone else will have to try it out.

Edit: I see that sass-rs has been bumped to the newest version of libsass, which should support VS 2017 and 2019 toolsets. But it still doesn't work for me.

Edit 2: Maybe the new sass-rs version has not been added to crates.io yet? The latest sass-rs version on there is from 2 months ago. I'm new to Rust though, so maybe I'm not understanding it correctly.

[awulkan]

Hey again, sorry for making a lot of comments, I'm still learning all of this. :) So I figured out that I could manually use a git link in the cargo.toml file that required sass.rs, and it worked! sass-rs = { git = "https://github.com/compass-rs/sass-rs.git"} So, when it eventually gets updated, it should make it easier for Windows users to compile Zola if they only have modern build tools installed.

Everything seems to be working correctly with the theme as well. I can see drafts in serve mode, but not in build mode. Good job.

[Keats]

Hmm master is exactly the same as the version in Cargo.lock, I don't see why it would work via git...?

[awulkan]

I guess because it hasn't been updated in crates.io for a while? Idk how that process is handled really.

[Keats]

I've pushed a new version of sass-rs to crates.io yesterday

On Sat, 13 Jul 2019, 19:09 Alex, notifications@github.com wrote:

I guess because it hasn't been updated in cargo.io for a while?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/getzola/zola/issues/742?email_source=notifications&email_token=AAFGDI4XJNN6V3LK3EDDC4TP7ID37A5CNFSM4H7Y6K32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ3VVCA#issuecomment-511138440, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFGDI33NWLPI6ZUT7CBL2DP7ID37ANCNFSM4H7Y6K3Q .

[awulkan]

Hmm, it says "Last Updated 2 months ago". https://crates.io/crates/sass-rs It seems like the cargo.toml version number hasn't been updated, maybe that's why it didn't publish the new version?

Btw, when I said "cargo.io" earlier I meant "crates.io" of course. :) I've edited my comments.

[Keats]

The important crate is sass-sys: https://crates.io/crates/sass-sys sass-rs will use the latest sass-sys

[awulkan]

But isn't sass-sys pulled in through sass-rs? And since sass-rs is not updated in crates.io it still has the older version of sass-sys, which doesn't allow for modern Windows build tools.

I'm just guessing, but at least it worked when I direct linked to sass-rs.

[Keats]

cargo uses semver for resolutions and sass-rs will pull any 0.4.x versions. You can have a look at the Cargo.lock to see what is being pulled: https://github.com/getzola/zola/blob/next/Cargo.lock#L2215

[awulkan]

Well, I'll be damned. I recompiled Zola without the git link now and it worked. I either did something else wrong then, or something magically fixed itself since yesterday. Maybe some build tool required a system restart. Sorry for wasting your time.

Anyway, your code changes appear to be working as expected for my cases at least. :)

Also, sorry ozkxr, you probably got a lot of off-topic messages from this github issue.

[ozkxr]

@awulkan no problem. I'm glad your issue was also resolved, one way or another =)

[Keats]

The next branch should have a fully working draft system. Would be nice to have people testing the system to make sure it behaves as expected.

[ozkxr]

I tested it in Ubuntu under WSL. It works. Drafts are generated in server mode and are ignored in build mode.

[awulkan]

Nice, then we have two working sites using the new system. I'll be testing it more during the upcoming week.

[Keats]

This has now changed in the next branch: all drafts are now disabled by default unless a --drafts is passed to zola {build, serve, check}`. If anyone can give it a try it would be great!

[izissise]

Hello, I'm still having a minor issue with this, so I know build with --drafts and I changed to

{%- for page in pages | filter(attribute="draft", value=false) %}

for atom.xml and section.html but it doesn't work for sitemap.xml

{%- for sitemap_entry in entries | filter(attribute="draft", value=false) %}

I guess an entry struct is different than a post, what should be the filter in this case?

Thanks, Hugues