I’ve been on the soapbox over here at The Theme Foundry lately discouraging too much “process” while we’re designing and building a new WordPress theme. What do I mean by process? I’m defining process as the steps you take to get from point A to point B. In a traditional agency environment this might take the form of: client meeting, client pitch, wireframes, Photoshop mock-ups, site delivery.
Archive of posts with the From the workshop topic
Working on the new default WordPress theme, Twenty Twelve, has been a very special, exciting, and humbling experience. We got off to a slow start earlier this year, but the pace has picked up significantly since then, and we’re now preparing to move the codebase back into WordPress core.
We have a live demo of Twenty Twelve hosted over on WordPress.com!
Twenty Twelve isn’t finished yet, but all the major styling is complete. The goal was to design a clean, minimal, and responsive theme, with a focus on typography and readability. I think we met that goal and I’m really happy with where we are right now. Take it for a spin and let us know what you think.
As you may have read earlier, I’m currently working on the the new WordPress default theme, Twenty Twelve. One of the early Twenty Twelve discussions was about typography. I felt it was important we use a web font. Not only would a web font look great, it would also show WordPress is pushing forward to adopt new web development technologies. The font would obviously be open source, so we had 2 options:
Use the free open-source Google Web Fonts directory to load the font directly through Google’s external API.
Package it with the theme and use CSS to load the font. We would have to ensure a GPLv2 compatible license in this case (more on this later).
In the end, it was important to choose a great looking font with extensive language support. Whether we included it in the theme or not was a secondary concern.
As I was working on our latest theme, I came across a situation where I needed to filter out posts that had a specific meta key that either never was set (NULL) or was false. I started down the route of using the
meta_query argument to WP_Query.
At the end of last year Matt and Lance contacted me and asked if I’d be interested in designing Twenty Twelve, the default WordPress theme for this year. I was of course honored and excited, and after some discussion about expectations and details, we started the project in relative secrecy.
After a fast start, Twenty Twelve development slowed to a crawl in February (which was my fault) and in March we decided including it in WordPress 3.4 wasn’t a good idea. Since then we’ve re-focused, moved the Twenty Twelve repository to Github, and established a regular work schedule to ensure it’s ready for WordPress 3.5.
As a theme developer, there are situations when having some extra buttons on the content editor can come in handy. WordPress provides the
mce_buttons_3 hook, which allows you to add buttons to a third row on the visual editor.
However, by default this row will show no matter what, even when you toggle the “kitchen sink” on and off:
It seems more logical to toggle the third row on and off along with the rest of the advanced buttons. In fact, there is a core ticket dealing with this very situation.
At a small company, the “Jack of all trades” is often more valuable than the “Master of one”. Each team member must wear a number of hats at any given time. When I’m helping our awesome customers I wear my support cap, and when I’m working on themes I put on my coder helmet. Previously, my least favorite hat was the documentation ushanka – the “docushanka”. Bulky, uncomfortable, and when you wear it, you know you’re going somewhere unpleasant. But, that all changed when we rolled over to our new site.
I’d like to tell you a quick story. A story about a website, actually. You might even call it a “coming of age” tale.
But first, let’s review the story up to this point.
Here at The Theme Foundry we take the craft of WordPress theming seriously. We’re constantly scrutinizing everything: how we code the themes, what features we want to add, and ultimately what features we need to leave out. While developing our latest theme Duet, we had some passionate discussion about theme options.
There are some themes that are designed to serve nearly any purpose under the sun – and they contain a vast amount of configurable options on the backend to help you get your site “just like you want it”.
On the other hand, there are those who say themes should have zero (or as close to it as possible) options – the idea being that a theme should “just work”.
At The Theme Foundry, we tend to lean toward the “zero configuration” side. We think requiring extensive backend setup is a turn-off for the average user, so we gear our themes to work “out of the zip”.
With that in mind, I’d like to share a story with you about some lessons I learned while building Duet.