Draft Handling

[biilmann]

While the live preview in the style of the site, should lower the need to publish draft versions before publishing the live version of an update, Netlify CMS still ought to have some handling for drafts.

Here's a few options for draft handling:

Rely on the static site generator

A lot of static site generators have support for draft content, typically in one or two ways:

1. There's a boolean value in the meta data like "published" or "draft".
2. There's two different folders, one for drafts and one for published posts.

It's definitively viable to build an abstraction on top of this, exposing a method to fetch all drafts, promoting a draft to published or demoting a published post to a draft.

The tricky part here is how to handle preview builds.

One option that comes to mind here is adding support on netlify's end to indicate a draft build in the commit message. The downside of this is that this would tie the draft feature a lot to netlify unless other continuous deployment services added support for the same commit message format...

Rely on Git

The other option is to ignore the built-in support for drafts in the different static site generator and use git branches for draft handling.

Pull Request

One way to handle drafts is to automatically create a new branch for each draft and trigger a pull request. Netlify has built-in support for doing preview builds of pull requests and this is something that can also be configured with other continuous deployment setups like Travis-CI.

This does leave the question of how to get the preview URL for the pull-request build back to the content editor?

Staging Branch

Another option is a staging branch. With netlify a really common pattern for sites is to have a private staging version of the site that builds from one branch and a production version of the site that builds from the master branch.

The very simplest draft handling in this case would simply be to have content editors just work with the CMS on the staging branch and always just see staging previews.

However, actually merging changes into the production branch can be tricky since we can't really guarantee that the changes can be trivially fast forwarded, if someone has been doing work directly against the master branch. On sites with many content editors it also makes it tricky to publish changes gradually. If several content editors are working on drafts for different entries, then simply merging the staging branch into the master branch would publish all of them.

Not sure if there's a way to handle this without accidentally introducing a lot of the complexity of handling branching and merging in git to content editors (which is a no-go).

Other suggestions/Comments?

What's the main use-cases for drafts? Any other ideas for draft implementations?

[digitalplaywright]

I do not think timed publishing of drafts is necessary for the first iteration on this. Copying what ghost.org supports seems sufficient:

• unpublished posts
  • save draft, publish now, delete post
• published posts
  • update post, unpublish, delete post

Implementing these would make this usable for us.

[jaysudodeveloper]

The simplest solution is usually the better one to consider. As you said static site generators typically support in one or two ways for handing drafts; to avoid complexity this handing should be left for them to handle and have netlify abstract on top of this. Although this would "tie draft feature a lot to netlify" it is something that can be controlled by netlify and allow for further abstraction to add support.

A staging and production branch pattern would be a good way to go as well but leaves less control on version handling unless each new draft was a branch of its own(don't want this) and have a method for pulling from specific draft branches to preview changes before a publish is made.

digitalplaywright is spot on with using a pattern of published posts and unpublished.