I’m looking at adopting Hugo for publishing our company blogs. One requirement we have is the ability to review changes for important pages prior to going live.
I know this can be done by setting draft=true in a post’s front matter, which is great for reviewing it before it’s initial publication, but can it be used to draft subsequent modifications to a post? i.e. a page is published to production, then sometime later a major change is made that needs review. Setting draft=true at this point will prevent the post from being generated, effectively removing it. Am I right?
Is there a way to achieve this behaviour directly with Hugo? Or do I need to rely on some other mechanism, such as a branching model in Git?
You would have to do that outside of Hugo; maybe you can get some inspiration from how the Netlify pull request / preview workflow works, see Pull requests · gohugoio/hugoDocs · GitHub
@noelob Not sure how your authorship is distributed–and I agree that Netlify has the best approach to this, but you could always keep a content branch alive, push that to a subdomain–or whatever domain you want, really–create a policy with something like S3 so that it’s only accessible on your network, build that branch with Wercker, have it check for an env (or just watch for changes specifically to your content branch), and run Hugo with the --buildDrafts flags.
This is assuming, of course, that you’re looking for previews for content changes to share with some sort of internal stakeholder/colleagues for a blog before you share it with the world.
I also appreciate it’s a pretty specific use case, but I’m throwing it out there because I have a couple internal-only Hugo sites I’ve built at my current company, including my Digital Strategy Team’s blog
Thanks for your input, @rdwatters! Authors are all in-house (marketing team), situated in two countries. The blog will be built via our Jenkins CI pipeline, and served via a path under the parent site (example.com/blog) which complicates things a little.
My current thinking is to use git flow (or possibly a simpler branching model); Jenkins could build from a ‘develop’ type branch, which contains WIP, for the development environment, and from master when building the site destined for production. This would mean that we’d never need to use Hugo’s draft mode, otherwise, it would require someone to manually change it prior to merging to master, which would be error prone
