I’m a sucker for clean, well-designed code. I like modular, extensible architectures. I like change.
As a consequence, I struggle periodically with the theme of my website. Not that I am a designer and it is certainly not the most productive use of my time, but what can I say. The point is, I was never really happy with the infrastructure I had at my disposal (I am never happy with the designs that I come up with, so thats another story). Until now.
One of the main barriers in designing a custom theme is that you don’t want to scratch. It is just too much work, and why do it when so many others have already done all the hard work for you? It pays to be lazy! So I have always looked around for good starting points to build up custom themes on.
I started out with Sandbox, a semantically rich theme that allowed extensive customization just using CSS. However, styling via CSS can only get you so far. Sometimes you really do want to make changes to the underlying PHP, for instance.
My next setup involved a base copy of Sandbox on which I layered my changes. In order to accommodate changes to the underlying Sandbox code, I used Mercurial with patch queues (the mq extension). This was much nicer, since it was easy to keep up with changes to the core Sandbox and leverage the work that was being done by others. But it was still cumbersome, since once in a while I would run into conflicts that I would have to merge manually. And it was still not a clean setup.
My ideal setup would have been to keep my changes completely distinct and isolated from the underlying theme. A setup that would allow the underlying theme to evolve independently, while my changes continue to work without any additional work.
Thanks to improved support for child themes in WordPress 2.7, and some fantastic work done by these fine folk, I have realized this ideal setup.
You see, I recently started working on a new website for my wife (it is not live yet, but will be soon). In the process of building her website, I was exploring the so-called WordPress Theme Frameworks. After some playing around, I settled on using Thematic. I started out by cloning the Thematic repository. Locally, I was using git-svn to manage the code changes. Thanks to git-rebase, it was not that hard to keep my changes up-to-date relative to a rapidly evolving Thematic code base.
But soon enough, Thematic had enough hooks, filters and features that I could do all the modifications without modifying a single line of Thematic itself. Now, all my changes are contained entirely within a child theme. How it is possible? Well, Thematic happens to be pretty much the most child-theme friendly framework that I could find. It is really easy to customize. Several child themes are already available for immediate use, and it is trivial to develop your own child theme.
This blog is going to run on a Thematic child theme. Changes are going to be incremental, but I don’t need to worry about keeping them in sync with Thematic, and I get to leverage the improvements being done in the core them for free! You can also take a sneak peak at how we are using Thematic for my wife’s new website