When I started work on the Wordpress theme for this blog I did so with thoughts of eventually releasing it into the wild but at the time releasing it was by no means the immediate goal. I wrote the theme myself because I wanted a reason to dive into some PHP as well as because I knew familiarity with (one of) the most popular blogging platforms could only be good for me. I started work on it around the time Wordpress 2.5 was released and github shows my first commit on 10 May 2008 though I know I started working on it prior to that because the first commit contains a pretty recognizable set of files.

After working on it for a while I it got to a point where I was more or less satisfied with the way it looked in my primary browsers of concern¹. I largely ignored IE(Internet Explorer) because to be honest I didn’t expect much traffic and what traffic I figured I get I didn’t believe would be using IE. As a result I was content with my theme and while I realize it’s not a pillar of web design or anything I think it serves it’s purpose and features the important part, the content, prominently.

This all brings me up to about a week ago² when I decided I could use some supplementary income and at the time I thought things looked ‘ok’ in IE and so it would be quick to polish things off, get it uploaded and wait to see if it got approved. However, once I read the information available on themeforest and realized what files where required and that there was an approval process I realized I had to take this a little more seriously. Not to mention that when I actually looked at the theme (and hence this site) in IE I realized how wrong I had been about the couple of quick fixes and then upload.

Knowing someone was going to be reviewing my work also made me a little more critical of it. I had included some MooTools in order to accomplish some pretty basic things. I did this mostly out of laziness and so upon looking at my work critically I knew this needed to come out because the 7 or so lines of JavaScript I had written using MooTools were certainly not enough to justify the library’s inclusion (as much as I do love me some Moo). So I took out MooTools and rolled my own native JavaScript to handle things like IE6’s lack of :hover support and IE’s general lack of :last-child support.

There were also some pretty nasty float bugs to clean up and in the process of all that I decided to take a sip the CSS3 Kool-Aid and smarten my suckerfish menus up for browsers supporting box-shadow. After the bugs were squashed and a little CSS3 was tossed in there I had to do something I never thought I’d have to do for a Wordpress theme; write documentation. After documentation it was just putting together zip files and taking some screenshots.

All in all I think developing this theme was a good experience³ and I’m actually looking forward to creating another theme as soon as I have a good idea for it.

After seeing a post on the github blog about David Baldwin using github as his blog I got to thinking about how much easier it would be to create my markdown posts offline and then commit them to some repository and have them show up as blog entries.

The comments for the github entry point out a number of people using various solutions to achieve an effect similar to what I want however I am somewhat loathe to give up on a web interface in general and Wordpress in particular. But this did get me thinking, what about a post-commit hook so after every commit a script examines the changed files and creates or edits posts as necessary. Google didn’t turn up much of anything in the way of making this happen and so I started thinking about how I would write my own solution.

As of right now I’m just in the planning stages but I did realize it would have to be a pre-commit hook on account of wanting to track the post id somewhere and the most logical place seems to be as some meta information at the top of the post. Currently I have the pre-commit hook reading the information I need to send about the post out of the file, the next step will be to figure out creating an XML object to send to the xmlrpc.php file of my Wordpress installation. In addition to dealing with hooks and xmlrpc¹ I’m writing the script using Perl in order to get some hands on experience with it.

I’ll admit I’m not 100% sure I can make the script do what I want it to do but I’m certainly going to give it a shot because looking at the solutions eluded to in the comments of the post on github there doesn’t look to be a solution to satisfy me yet.

My initial planning has the username, password and xmlrpc url being stored as config options via git config username|password|xmlrpc while post related information is stored in the actual post file. I think the most likely hang up will be modifying the file which is about to be committed (by adding the post id) because I believe I’d actually have to create the post via xmlrpc, write the response into the file, stop the commit, add the post file back to the index and re-commit. There may also be a problem with the way xmlrpc expects the categories.² Time will tell.

Recently I started using PHP Markdown Extra in order to format my posts. I decided to make the switch mostly because I find writing Markdown slightly more natural than writing HTML; more than that though I find reading and editing posts I’ve previously written using Markdown to be as easy as reading a regular word document or a book. Of course, the readability of Markdown text was sort of the point of the syntax so my observations seem a touch obvious. The crux of my point stems from my reasons for switching so it felt necessary to elucidate my position.

Through the course of learning the Markdown Extra Syntax I found it supported footnotes, for me this was exciting because I have a tendency when writing to have a lot of tangential thoughts. I usually¹ use parentheticals to capture these ancillary musings but I have noticed this tends to detract from the primary issue during reading. Clarity is something I strive for when writing² and so I figured it would be better to store my tangents away from the rest where they wouldn’t detract from the point I was trying to get across.³

I jumped into using footnotes with both feet and had soon written two posts⁴ making liberal use of footnotes. Upon inspection of the posts on the front page I noticed the references didn’t behave correctly. After some brief investigation I discovered the ids were the same for every set of footnotes which was frustrating for a couple reasons.

1. The footnotes aren’t much use if they don’t actually work
2. Duplicate ids means the document won’t validate, which makes me sad.

I immediately descended on the problem in an attempt to rectify the situation. To make a long⁵ story short I ended up creating a SHA1 hash of the footnote’s text and using it as an identifier for the references and ids. This works quite well for my purposes since it seems fairly unlikely I’ll be using the same footnote text over and over again⁶, however there are some pretty obvsious weaknesses to this strategy, which I’ll outline below. But first I wanted to provide a downloadable patch of the changes I made in order to make this footnote stuff work: you can get the Wordpress Friendly Markdown Footnotes patch and apply it in order to get this working for yourself. I created the patch using git, so if it proves difficult to apply let me know in the comments or via one of the contact methods on my about page and I’ll fix it up lickity split.

Now about those weaknesses; the major problem comes about if you want to use the same footnote text a couple of times. I could see this coming about more on a site publishing research papers than here but that isn’t the point. A better method would have been to use the Wordpress post id via <?php the_ID(); ?> because then the footnote references for the post are all constrained by a shared value. This was in fact my first idea but it seems core Wordpress loop functions are not available inside filters. This made me wonder if perhaps there wasn’t another way to get the post id, either from a filter argument or from some other magical place. Needless to say I couldn’t figure another way out or I would have used the post id method instead. Another issue, though I guess it’s not really a weakness, is the SHA1 makes the references a bit long and unsightly, not to mention meaningless. However, I was just happy to get the thing to work.

That is all for now, I’ll post updates if I make any improvments or changes.