Slow Cooked Support
This is another follow-up to my presentation at WordCamp Chicago. I might write a few more posts about Slow Cooking WordPress because as I prepared my presentation, I found I had a lot more to share than what I could cover in the allotted time.
On Sunday, I worked a bit at what I like to call the “Happiness Bar.” (I’m not a genius, I just like to make people happy.) I helped out a few people there and it made me think about some of the different experiences people come from when they start using WordPress. Some are designers, with little development experience. Others are writers who might have some experience with editing HTML & CSS. Some are business people, who have little to no experience at all with building things for the web.
If you ever venture over to the WordPress support forums (or any theme shop’s forums for that matter) and read through some of the threads there you’ll see a wide variety of experience levels among the users there. Sometimes you can even find patterns, where people tend to get stuck on the same issue.
That was partly the motivation behind my session: Identifying common WordPress mistakes and how to avoid them. One of the main points was what to look for in a theme. I think a lot of this relates to support and maintainability. Support starts before a theme is released by the author and before it gets installed by the end user. If you’re building a site for a client and choosing a ready-made theme as part of this process, it’s good to know what you’re building on.
What Am I Building On?
Whether you’re a theme author and you’re preparing a theme for release, or you’re building a site with a ready-made theme, test the theme out. One tip I shared was to use the WordPress importer plugin with the Theme Unit test data to test drive a variety of content. When I was preparing the slides for this, it wasn’t hard to come up with a fitting example:
Theme unit test on the TwentyTen theme (grayed background for clarity)
Theme unit test on a commercial theme (grayed background for clarity)
I used Firebug to add a gray background for clarity, and you can really see the difference here. It’s clear that the commercial theme was never tested to handle images with captions that get floated to the right or left.
So that’s one way to offer great support, test things out. When you’re building a theme for a multitude of uses, things are bound to break.
Another tool that can be useful in checking out a theme is the Log Deprecated Notices plugin. Activate this and you’ll get a quick glimpse of whether or not the theme in question was coded using up to date practices. This plugin is helpful for both theme developers and consumers alike.
Is The Theme Creating Support Tickets (for third parties)?
One particularly egregious example I shared in my session addressed a certain purveyor of low quality themes that you might find through a Google Ad after searching for “WordPress Themes”. This site offers what seems to be an incredible deal: over 800 themes for under $60. Hard to beat right? Hate to be the buzzkill here, but these themes have a multitude of coding errors and contain flat-out bad practices. They seem to offer support, but for some reason, many of their customers find their way over to the support forums at wordpress.org looking for help.
Anyway, the example I related was a common problem that comes up with many of their themes, that makes this happen. Not cool.
What Will it Take to Customize This Theme?
Some themes are built with customization in mind. Some, not so much. The structure of the theme is a big part of the equation here. Structuring a theme that will be straightforward to customize requires some forward thinking on the theme author’s part. Even coding up something as simple as a custom header image can be done many different ways, as professional WordPress dev Michael Fields knows too well. One way might be easier for less experienced users to customize than another. The theme author’s decisions here will usually have a direct result in how much time will be spent supporting the theme.
An example: using hooks and filters can be a really cool way to customize themes, but it might require more effort to support this for the developer, and there might be a learning curve for the end user.
Will This Theme Work in X Years?
This was a recent lesson for me. A few of my first WordPress projects involved customizing a few commercial themes that used TimThumb for image resizing.* After the whole TimThumb security debacle last week, I have concerns that even though I knew I had a few minutes worth of updating to do on a few sites, I’m pretty sure many other sites using this script will not be updated. Many of these are older themes that are more or less abandon-ware. So, no notification from the vendor recommending the update. On the flip side of this, I’m impressed with how WooThemes handled this situation with transparency and guidance.
So, future upgrades and maintainability are two more factors to go into support that should not be ignored.
Where To Go From Here?
My advice here is to do your homework. If you’re buying themes, think about the long-term effects your choice will have. That $35 theme that does not include support or updates might cost you a lot more than the $70+ that does. If you’re building themes, the money you make from each sale can get eaten up quickly if support is taking you more time than it’s worth.
Footnote: This was before WordPress 2.9’s built-in image resizing. Either way, many themes still use this because TimThumb allows for some flexibility that the built-in resizing doesn’t have.