Last post, I described a new script which I’d written to automate the set-up for writing a new draft of something. I also described automatically creating the metadata that Scriptogram required to publish. In this post, I look briefly at what happens after a post has published in terms of my workflow process.
drafts folder is a busy place.
I have all sorts of folders in there, each with their own MarkDown files, containing ideas and draft posts waiting to be fleshed out and finished. (Mostly waiting until I’ve got this process set up in order that I can focus more fully on writing.)
Once I’ve actually completed a draft of a piece and have actually published it, I want it out of my way. Otherwise, the
drafts folder becomes a mixture of pieces I’ve finished and pieces I’m still working on.
So I move these finished folders to an archive.
Moving an entire folder of now finished “draft” material to an
archives folder is useful because it means I still have the Git repository – all the history of writing that draft – plus the metadata around that piece, all in one place. Moving it as it is, however, can lead to an area equally as cluttered and confusing. The clutter just ends up building in two places.
While I’m working on a draft, I don’t mind this clutter being in any particular order – it’s all stuff I’m working on and the disorganisation can actually be conducive to creativity.
But once I’ve “published” it in whatever form – “done with it”, essentially – I want to know when it was published. I want to file it away properly. And because I don’t have ready access to a folder or file creation date (unless I go into each Git repository and check individually), I need a quick way of sorting folders by when they were published.
So I rename each folder and its main file as I move them from
archives. I’ve been in the habit of prefixing the folder name and file name with the date and time it was published. The date and time are in ISO format so that I can easier sort the folders with manually trying to find a particular date.
The most recent folders in my
archives folder look like this:
This way I can easily see and sort by the publishing date, as it appears on the blog, as opposed to the “last modified” date, which may change if I decide to correct something after I’ve published.
In addition to my
drafts folder and
archives folder, I also have a folder called
posted. This contains a copy of just the published version of the MarkDown file for each post. No history and, at the moment, no metadata. This is so I have a plain-text copy of my blog which I can read should I ever lose access to the platform I’m using.
The names of each file are in exactly the same format as above: date, time, name. They’re named that way for the same reason. So I can see and sort by the date and time the posts were published, that is, deemed public.
I’ve written a Bash script for dealing with all the above. It’s very simple:
# Clean up file name. cleanfilename=$(echo $1 | tr '_ ' \-) newdirname=$(echo $(date '+%FT%H-%M')_$cleanfilename) ## Move whole folder from `drafts` to `archives`, with new name. mv ./drafts/$1 ./archives/$newdirname ## Rename main file via Git command. cd ./archives/$newdirname git mv $1.md $newdirname.md git commit -m "Renamed main file on publish." ## Make a copy of the post in `posted` folder. cp $newdirname.md ../../posted
The first part prepares the new file name. This is then used to rename the folder as it is moved from
archives. Then I rename the file within that folder, using the Git rename and committing the change so as to log it as part of the history. Finally, I copy the renamed file to my
I’ve added the above code as
archive.sh to my Git repository and pushed to GitHub as version 0.0.3.
My process for publishing my blog to Scriptogram and closing off a draft involes calling:
With this process more clearly mapped out, I can start to think about linking between posts, where having a consistent naming convention will be important.
I can also start tying it all together into one script.
Longer-term I’ll also want to think about tagging my commits in Git as it moves over, but to do that I will need to think more about the writing process itself.