Data Portability and My Own Stupidity

I made a bit of a mess of things when it comes to the data on this blog and thought I’d share my misstep to hopefully help you from creating one of your own.

As I’ve shared before, all of the writing I do for this site, I do in Markdown. This means that everything is in a highly portable format so that it can be easily converted into HTML. As I continued to write for this site, I had an idea… wouldn’t it be great if I could just write the site entirely in Markdown? This way, when creating posts, I wouldn’t have to take the four seconds needed to convert my post into HTML. There’d also be the added bonus of being able to go in and edit or add formatting in WordPress after I went live with a post in Markdown as well. I did some digging and found what I thought was a decent enough looking plugin in Markdown for WordPress and bbPress.

I also decided (well actually my wife decided) that my overuse of parenthetical needed to stop (she had a point). Rather than write like a big boy and eliminate all of my errant thoughts, I decided that footnotes would be the way to go. Now while I love Markdown, I’m not a lover of the MultiMarkdown execution of Footnotes. Since I’m lazy, I tend to avoid doing just about anything in the reference style. Since this was before Brett Terpstra offered a service for writing MultiMarkdown footnotes inline, I ended up adding the WP-Footnotes plugin to the site. It’s actually a very slick: wrap text in double parenthesis and like magic, it shows up as a properly formatted footnote. You can even add custom CSS directly into the plugin to style your notes.

All of this worked flawlessly. Well, it worked flawlessly until I recently started considering a move away from WordPress. Turns out, both these wonderfully convenient plugins made WordPress ideal to use, but my data within it impossible to use elsewhere. The markdown isn’t readable by many blog importers and the footnotes won’t work anywhere else. While not catastrophic (I can always stay on WordPress or go through the hundreds of posts and clean things up), it’s a pain, but it’s been a good lesson in the importance of keeping your data clean and portable.

Just like my problem, the moral to this little tale is two-fold… First, clean data should always trump convenience. If there is a remote possibility that you won’t be able to use whatever it is you’re doing now, don’t do it. Keep your data portable. And more importantly, there’s a big difference between efficient and lazy. I didn’t really know what I was doing at the time I added these two plugins (which was probably the first sign that I shouldn’t have been doing it) and rather than learn the best possible way to 1) post in Markdown and 2) easily create footnotes, I chose the fastest way to do both. All of that precious time saved and more will likely be lost to whatever solution is required to fix my mess.

It’s always worth trying to find a better way to do things, but you always need to think through the possible ramifications of whichever option you choose. Short-term gains are only valuable if they don’t lead to long-term losses. And that holds true for far more than just the way you go about storing the data on your blog.

Note: For those still looking for a way to use Markdown inside of WordPress, Markdown on Save seems to be a far better choice, especially if you tend to post from directly within WordPress. You can also remove the plugin at any time with no issue.