I think it’s fair to say I completely underestimated the response I would get to the WordPress 1.5 Theme Competition.

Last year’s Styles Competition produced 39 submissions – which really seemed like a lot at the time because there were few if any before then. I thought doubling the number of last year’s entries would be pretty awesome – but I’d have been happy with 70… turns out we doubled that!

Having such a huge response was a bit of a double edged sword – what my old boss would call a success disaster . While I’m thrilled that so many wonderful themes were created and submitted, it ended up taking much more of my time than I had projected.

A “theme” is much more complex than a “style”. A style is just a .CSS file – the worst it can do is not display the page’s content properly. A theme is a collection of .PHP files, .CSS files, .JS files and images in various formats. The code in a theme is much more powerful, but also much more dangerous. I decided that, as part of the service of hosting the Theme Competition, I also needed do the following:

• Check each theme to make sure it didn’t include malicous code (say code to publish your database password – I was happy to see that none did this).
• Check each theme to make sure it didn’t call plugins that weren’t included and activated by the theme itself.
• Check each theme for missing images/CSS references/broken PHP includes.
• Check each theme to make sure the way images were referenced would be portable (using <?php bloginfo('template_directory'); ?>, etc.).
• Check each theme to make sure that code that was commented out in a way that wouldn’t add to script execution time.
• Check each theme to make sure conditional code (like adding in the Theme Switcher) was done properly – often I’d have to change this so that the word ‘Themes’ wouldn’t appear on its own when the list of themes wasn’t present.

While I’m sure I missed things here and there, I’d guess I fixed about 3-5 things per theme. All of this took quite a bit of time, compounded by the fact that I’d have to do it again when a theme was updated.

Several people have asked why I didn’t just reject themes that didn’t meet these requirements and/or ask the theme author to fix them and resubmit. The short answer is that I wanted more than 20 themes in the competition. I did try this in a few cases, but I found that the theme authors needed guidance via e-mail on how to fix the problems and it was taking even more time.

The great response also necessitated the creation of the Theme Browser to enable people to better browse through all the themes – a nice problem to have to solve.

Not only did I underestimate the overall number of submissions the competition would receive (2x), I also underestimated how much time I’d need to spend processing each submission (3x)¹. The end result was a competition that took about 6x more time for me to run than I expected – something that was both annoying and quite satisfying. 😎

Now I can sit back and wait to tally up the scores from all the theme competition judges.

1. Estimating the time spend on each theme at 15 minutes (which is conservative), I spent 35 hours just processing themes. Add a few hours for the initial set-up of the blog, posting the rules, creating the theme browser, e-mailing the judges, tallying up their reponses, posting the results, notifying and sending prizes to the winners, etc. – I’d like those that suggested the theme competition be extended, or run every month, to keep this all in mind. 😉 [back]