Source control strategy for WordPress sites

My background is more in software and web application development, not website development. So when I started doing a few websites on the side, I wanted to translate some of the tools and processes that I use everyday as a developer to this new role. As I compared the different CMS options, WordPress was the winner in my eyes with a good balance of usability, maintainability, and customizability.

Having chosen WordPress, my attention shifted to finding a version control mechanism for the works in progress. The look and feel for WordPress sites are managed by themes. WordPress allows your to create a child theme based on an existing theme by assigning the ‘template’ property in the header for style.css (the only required file in a child theme). You can read more about creating a child theme here:

The content is maintained in the WordPress database (MySQL) and WordPress has a good mechanism for managing historical versions. The parent theme (in my case the new Twenty Eleven theme that came with WordPress 3.2) can be downloaded at any time, there’s no point in adding it to version control. Developing the child themes, I now have my handful of modified files under source control along with a simple FTP upload that serves as my deployment. Branching also works because I can deploy the branch to a 2nd theme folder (lets say ‘twentyeleven_custom_branch’) and preview the site with the new theme without actually activating the updated theme.

Google Finance Web Service Fail

Google Finance AJAX Fail
I'm assuming this was due to a timeout

A couple weeks ago, I was checking out Google Finance and noticed something scary. One of two things had just occurred; either the whole world just went broke or (slightly more likely) the web service call to retrieve the data had failed or timeout.

While the scenario was quickly fixed by refreshing the page, these are the usability points that are commonly overlooked when designing for UX. What should happen in case of failure? In this case, the default value that’s used is a 0 (zero). When dealing with numeric values, I prefer to show “N/A” or “NaN” if the audience is mathematically inclined.

Migrating Multiple WordPress Sites to a single Multisite

Until recently, I have been using WordPress solely for more this blog. With the release of version 3.0, I decided to read through the release notes and noticed some great features. With the addition of custom post types introduced in version 2.9, WordPress makes a dandy content management system.

Discussing this with Morton (@mor10) at MIX 2011 only further solidified my decision to use WordPress as a CMS for production websites.

With all of the sites that I am building using WordPress, managing the different sites (each is installed as a standalone site) has become a hassle. Before I start on other sites, I am taking this opportunity to migrate all of my sites that I am hosting into a single Multisite implementation. WordPress has some documentation on how to do this; I will document any hiccups I come across and their resolution.

Further Reading

Production Sites

Here are a couple sites I’ve implemented using WordPress 3.1