One thing that’s been annoying me recently with the static site publishing tool that I use, pelican, is how it treats draft posts and publishing. Out of the box, I haven’t been able to easily generate one development site that includes all draft (and unlabeled status) posts and another “officially” published site that omits draft posts. The development site being handled by pelican’s built-in HTTP server will provide a drafts folder, but I find it’s usage clunky.
However, there may be a workaround using pelican’s default
and some smart configuration:
- Have the
devserver-globaltargets in the
Makefilegenerate output into a distinct dev output dir, where dev content winds up getting served from
- Modify the
- Leave the
publishconf.pyas is, or make sure the default status is
- Maybe put all draft posts in a
draftpostssubdir so they get tagged in the dev server and are easier to find.
That should cleanly isolate the dev content from the published content, yet put all the draft material in one place during dev. It should at the same time prevent accidental publishing of draft material to the production site. I’m going to try an experiment using this approach for a few days and report back.
P. S. Combined with TailScale, mobile life and authoring on the go should become quite palatable. Hmmm 🤔, how well does self-hosted filesharing tech like NFS and SMB work over TailScale? Given my personal toolkit, worst comes to worst, I could also employ Emacs TRAMP over SSH.