[[!meta Error: cannot parse date/time: November 2, 2015 at 07:55:55 PM EST]]

Do you write on your own site?

Are you involved in software development in any way? Are you already publishing your writing on a website you control? Me too. This post is based on my personal experience writing on this site (and administering it) since 1999. The word “blog” was apparently coined around the same time, but I hadn’t heard of it yet. I was calling this thing here an “online journal.” Quaint.

How’s that working for you?

When you’ve written a new piece, how do you publish it? Maybe by clicking a “Publish” button in the admin interface of the production instance of your CMS?

When you’ve written a final draft, how do you preview it? Do you have a non-production instance of your CMS? Probably not. Maybe you click “Publish” in a different mode that tries to avoid making the post visible, or maybe you edit in a WYSIWYG control that tries to render almost (but not exactly) the same as publishing would?

When you’ve written a first draft, how do you edit it? How do you see what you changed from one draft to the next? If you try some new wording, click “Save”, and decide it isn’t better, how do you go back? Can you go back?

When your network connection drops or your browser crashes, do you lose your writing in progress? Has either of these happened to you yet? How do you imagine you’ll feel when they do?

When your CMS frequently has security holes (such as WordPress has just had, again), how large is the attack surface? How easy is it apply the latest patch? How often is it necessary to patch the latest bug? Until you patch, how much of your work might you lose?

Even if your CMS doesn’t have security holes frequently, how recently have you made an offline backup? How recently have you test-restored from it? Are both steps easy to perform, or are they extracurricular activities you might skip?

”If you don’t test restores from your backups, you do not have backups.” —@garybernhardt

Do you feel safe about the continued existence of the words you’ve worked so hard to write? I ask because of how I felt when I was still running a traditional dynamic CMS.

Another approach

To have more satisfying answers to some of these questions, one idea is Maciej Cegłowski’s: run your CMS on a non-public address, crawl it to create a static cache, and publish the cache. But this is hacky. It complicates publishing, generates some broken internal links (at least on Maciej’s own site), and doesn’t solve versioning or backups — which is to say, restores.

Since static content is such a good idea, surely there must be CMSes designed to generate it? Two popular choices, Jekyll and its cousin Octopress, are topics of this weekend’s JekyllConf. Static site generators typically take away the heavyweight database and the entire dynamic-web-app attack surface, in exchange for which they give you the safety of writing offline, the power of revision control, and the ease of git push to publish. If you value those things, an SSG is a bargain. But in that bargain you’re also necessarily giving up a web admin interface, a searchable local index, and reader comments being stored somewhere you control.

That’s why I prefer a CMS that’s mostly a static site generator. Most of my sites don’t enable the web admin interface, but many of them are searchable, and this one allows comments. If you like any of the following neat shell tricks I can do now that I’ve switched schmonz.com to ikiwiki, feel free to comment. It’ll turn into a git commit, of course; next time I git pull I’ll have a local backup; and I’m sure I’ll make that backup, because I won’t be able to git push another post until I do. ;-)

Neat ikiwiki tricks

Naturally, these can be encapsulated in shell functions or small standalone scripts.

List drafts committed after the ‘textpattern’ tag

$ git diff --stat textpattern unpublished | awk '{print $1}' | grep '\.md'

Write a new post with my permalink style

$ _TODAY=$(date '+%Y/%m/%d') && mkdir -p ${_TODAY} && vi ${_TODAY}/post-name.md

Write a new comment offline, using $EDITOR

$ ikiwiki-comment ${_TODAY}/post-name.md

List the most recent 12 posts

$ find . -type f -name '*.md' | egrep '^\./[0-9]+\/' | sort -rn | head -12

List the most recent 12 comments on any posts

$ find . -type f -name '*._comment' | xargs stat -f '%Y%m%d %N' | sort -rn | head -12 | awk '{print $2}'

List all the comments on a given post

$ find ${_TODAY} -name '*._comment' | sort -rn

List all posts containing podcast-style enclosures

$ find . -type f | xargs grep -l 'meta enclosure=' | sort -rn

More possibilities

  • List posts which have been edited since being posted, and show the changes
  • Replace all occurrences in all files of XXX with YYY, review the changes, commit, be able to revert if needed (I’ve done a few of these)
  • Your ideas?