Creating Wordpress Themes with Blueprint and Sandbox

This post is an expanded version of a comment I made here, plus some new information I’ve since discovered.

I had in my mind that it should be possible to update WordPress themes in the same way as one can update plugins and WordPress itself, that is using Subversion (SVN). When creating a new site, I usually cut and paste a list of essential plugins into the svn:externals file and this ensures that every plugin has the most recent version – or at least as recent as I remember to ssh into my server and type ’svn up’, which as it happens is pretty often, although I’d actually like to automate this for all my sites at some point. (The problem with doing it automatically on lots of sites simultaneously is that if something breaks during the update then you won’t know about it).

WordPress plugins are usually available on svn.wp-plugins.org or on Google code and thus updates are available directly from there via SVN- if a plugin author doesn’t host on an SVN server I put them on my own SVN server which is hosted with Assembla and then manually update them myself if necessary. This means that although it’s a hassle to do that, I only have to update one server which can then service various sites via SVN.

Unfortunately WordPress themes are not usually hosted on SVN servers, apparently something similar to the plugins repo was tried but either proved unpopular with the more designer-y theme developers (as opposed to the more coder-y plugin authors) or ran into other problems, anyway afaik it was pulled last year with only a few themes hosted on it.

I really wanted to have my themes updated via SVN so I did some research and found out that several of the more framework-type themes are indeed hosted on SVN repositories- the excellent Tarski which I am currently using for this site, Sandbox and also Thematic.

The problem is that once one starts changing the CSS of the theme around to suit one’s taste and/or clients’ requirements, the next SVN update will wipe out those changes (in fact there is a way around this which I’ll come to later), but anyway for me, a more elegant solution for having a custom style sheet is to create a child theme of Sandbox (or Tarski or Thematic, or whatever theme you choose), as outlined here:

http://themeshaper.com/how-to-protect-your-wordpress-theme-against-upgrades/

This keeps the main theme totally separate from your CSS modifications and means you can have several child themes of a parent theme which is updated to the latest version via SVN without any worries about it affecting your child themes. Kudos must go to the WP developers for designing this efficient and elegant solution – ‘Code is Poetry’ indeed.

Adding the Blueprint CSS framework adds another dimension to Sandbox and in fact a ‘bare’ theme consisting of just Sandbox and Blueprint is actually quite a usable theme, given the nice resets and typography that Blueprint introduces to the (to my mind) overly stark Sandbox in its native state.

So the basic steps would be to follow the method outlined by Michael Wender here and then create a child theme of Sandbox and then select this as the active theme. Once I’ve created the child theme (let’s call it ’sample’), I put the Blueprint directory inside the folder with my child theme and then link to it like this:

@import url(’../sample/blueprint/screen.css’);

That way Sandbox can be easily updated to the latest version using SVN and the child theme(s) and Blueprint code are not affected by the upgrades.

The only fly in the ointment is that adding Blueprint means you have to change the header.php file as shown in Michael’s tutorial, so you have to tell SVN not to update the header.php file – otherwise you’d have to keep making the modifications listed in the tutorial after every SVN update – this is done by adding header.php to the svn:ignore file.

svn propedit svn:externals .

In the file that opens, put header.css and the names of any other files you don’t want to be updated by SVN (don’t forget the dot on the end!).

I have since discovered that it’s possible to create a functions.php file within the child theme, presumably within which the functions which should be put into header.php can be placed, thus meaning that you don’t have to use svn:ignore. At the moment I haven’t tried this, not really understanding all the functions and hooks as yet (I’m more of a designer-y and CSS person at this point)- anyway there’s more information on this here by Scott Wallick, the developer of Sandbox.