On Breaking and Fixing WordPress Themes at WordCamp Singapore 2011

My coworkers at Automattic and I frequently discuss the speed with which we’re able to onboard new themes into the WordPress.com theme directory.

Our top priority as the Theme Team is to make sure that all of our users feel like they have a theme that fits them perfectly; in order to meet that goal we’re focused on bringing a variety of themes into WordPress.com through a few primary channels: the WordPress.org theme directory; premium theme shops; and Automattic (in-house) themes.

It’s often the case that each conversion—that is, making a theme’s code WordPress.com-safe and ready—will take us anywhere between one week and one month, depending on the complexity and quality of the code. In a perfect world, though, we’d be able to snap our fingers and have every single awesome-looking theme available on WP.com right now.

I flew to Singapore from November 19th to November 21st, 2011 to speak at the first ever WordCamp Singapore about breaking and fixing WordPress themes, which is the biggest part of our aforementioned WP.com onboarding process.

The talk was one of the more difficult presentations I’ve given due to a number of factors:

• I didn’t know whether the majority of WCSG attendees would be WordPress users or developers
• Among the developers who attended, I didn’t know who among them were beginner, intermediate, or advanced coders
• Among the developers who attended, I didn’t know who among them were primarily focused on plugin development versus theme development
• Freelance developers, small theme shops, and large theme shops approach their craft in different ways
• I had 25 minutes of presentation time (and of sleep the previous night); in hindsight, though, I could have shortened this talk to 15 minutes and been just fine

My ultimate goal moving forward is to create a series of talks entitled Best Practices: On Making, Breaking, and Fixing WordPress Themes, which will all be related to theme development. Each talk will either focus on the making of themes or on the breaking and fixing of them.

The trouble with this, of course, is that WordPress is a moving target. I imagine that in a year from now I’ll look back on this talk and be embarrassed by both my presentation style and content, and that will be a good thing, as it means that WordPress has evolved to the point where some of these checks don’t make sense anymore.

Making, breaking, and fixing are all part of the WordPress theme development process. As I mentioned in my talk, the making of themes is a bit easier to me than actually fixing and breaking them. I can’t count how many “What on Earth was I doing here?” moments I’ve had when checking over old code with unit tests.

Plugins mentioned in the presentation are as follows:

• Debug Bar: Adds a debug menu to the toolbar that shows query, cache, and other helpful debugging information.
• Debug Bar Console: Adds a PHP/MySQL console to the debug bar.
• Log Deprecated Notices: Logs the usage of deprecated files, functions, and function arguments, offers the alternative if available, and identifies where the deprecated functionality is being used.
• Regenerate Thumbnails: Allows you to regenerate all thumbnails after changing the thumbnail sizes.
• Reveal IDs: Show post, page, category, tag, and link IDs in the Dashboard.
• RTL Tester: Allows quick rtl.css testing by adding a switch to the toolbar.
• Theme-Check: Tests a WordPress theme against the latest WP standards.
• WordPress Importer: Bulk content migration from site to site.

Bonus (not mentioned in the talk but I’ve learned about them since spending more time at Automattic):

• Pig Latin: Makes it easier to see which strings are ready for translation and it does so in a really fun way.
• RTLer: Generates the RTL stylesheet for you from your theme’s ‘style.css’ or any other CSS file.

All other important links given during the presentation are embedded in its PDF file, which you can download here or view below: