As you probably already know, WordPress has announced it’s third release candidate for version 3.2, while the actual release is being delayed for a few days. You might be familiar with some of the new features coming up in 3.2, but we have a dedicated blog post for that lined up. This post is about the new default theme in WordPress 3.2 — Twenty Eleven.
This is the second year in a row that WordPress is changing their default theme, which is a good trend and we’re obviously hoping to see Twenty Twelve next year 😉 In this post I’ll give you a short intro to the Twenty Eleven theme and the functionality it provides. We’ll talk a little bit about post formats, layouts, color schemes and the theme options. We’ll then dive into the code of Twenty Eleven and see how the theme development guidelines have changed since last year’s Twenty Ten.
A Brief History: Duster & Twenty Eleven
Twenty Eleven wasn’t always named “Twenty Eleven”, before becoming the default WordPress theme it’s name was Duster. Duster was developed by the Automattic team, which is why it’s so exciting to WordPress developers.
Duster was first introduced to the WordPress.org directory for approval in mid-February this year, that’s around 4 months ago. There was a total of six versions of Duster, most of which implemented small fixes to quite crucial (although recommended, not required) elements to get past the theme reviewers team. Now this is interesting, unless we have missed something — it seems that Automattic is not taking any short cuts here either, they’re running their works through the review process just like everybody else is.
The final version of Duster (1.0.5) was approved in April, which is when it moved directly into the WordPress.org themes repository. Soon after that, Matt Mullenweg had imported the Duster theme to the WordPress core project as a candidate for Twenty Eleven, along with a few suggestions on how the theme could be better. That’s when Duster became “Twenty Eleven” and when the rest of the WordPress.org team started contributing.
Duster is still available in the free themes directory as well as for WordPress.com hosted web sites. Of course we can expect further improvement of that, or perhaps a merge after the 3.2 release.
A Quick Overview of Twenty Eleven
Sticky featured posts, lovely large images and typography at it’s best! And what’s more exciting is that the Automattic team has shown us the correct way of doing that, which we’ll dig into very soon.
Like many good themes, Twenty Eleven is ready for translation with right-to-left languages support. It’s got a great support for the visual editor CSS which makes content editing even more comfortable. It’s got support for background colors and images, and a very neat support for header images, which in my opinion, really took Twenty Ten forward.
The navigation menu and the widgets are there of course, nicely laid out with five different sidebar areas. So, quick question — isn’t it time to get rid of the word “sidebar”? Especially since the new default theme has three widgetized footer areas, it stops making sense these days doesn’t it? 😉
Now the most exciting admin feature is of course the Theme Options page. I think Automattic really nailed it this time, and would probably convince theme developers as well as companies to stop making fuzzy theme options screens, since everything can be so nicely done in the generic way, which is much more user friendly. Twenty Eleven’s Theme Options page lets you customize the default page layout, color scheme (dark or light) and the color of your links — fantastic!
Twenty Eleven comes with a couple of pre-made page templates, but don’t forget that you can always create your own child theme to override the different aspects of Twenty Eleven. And that would be a piece of cake, since the theme’s code is so nice and clean, really! And now, speaking about code, get your brains ready to dive into that.
Diving into Twenty Eleven
If you’re a theme developer and had your own best practices, frameworks and ideas of how things should be done with WordPress, I want you to forget them for a moment. Twenty Eleven really does show you the best coding practices of creating neat and shiny, child-compatible, awesome to read themes that use WordPress at it’s max.
The functions.php File
You probably already know what the functions.php file does. Twenty Eleven ships with an awesome, easy to follow functions file. It utilizes the after_theme_setup action to do the rest of the theme setup, which you should probably note down. It’s a bad idea loading that much stuff during init.
Localization, editor styles, the right way to include additional source code in your functions file, navigation menus, post formats, backgrounds, header images, thumbnails and more. It’s all in there, except for the sidebars registration. Sidebars are registered in a different action called widgets_init— which certainly is the right choice.
Read throughout the file very carefully and I’m sure you’ll learn a bunch of stuff. function_exists calls allow you to override functions in your child themes, i.e. using the same function names in your child theme will prevent Twenty Eleven from declaring (or re-declaring) the same functions. This is one of the many ways child themes can benefit from Twenty Eleven’s coding style.
Watch how Twenty Eleven escapes strings using esc_url, esc_html and esc_attr — you should probably follow that convention. Also note how the theme uses printf with placeholders to maintain very good readability of the theme’s code, as well as provide more flexibility to theme translators.
The content.php and content-*.php Files
You might be wondering what those files are doing there, right? We’re used to using the WordPress loop (aka The Loop) in our main template files across the template hierarchy (index.php, single.php, etc). This approach is not new to WordPress and it’s mainly implemented for child themes to take advantage of your theme.
This means that The Loop is replaced with calls to get_template_part, like so, in Twenty Eleven’s index.php:
// Inside the loop
get_template_part( 'content', get_post_format() );
The second argument of the get_template_part function will return the current post’s “post format” — gallery, image, video or audio (introduced earlier in WordPress). The first argument is always the fallback for all. This means that it’s a safe way to run different files whether they exist or not, falling back to content.php. Let me explain… in code:
// Will include the content.php file from the template directory
get_template_part( 'content' );
// Will attempt to include content-something.php from the
// template directory, and will include content.php if the
// former does not exist
get_template_part( 'content', 'something' );
So the method illustrated in Twenty Eleven’s index.php will attempt to include content-post-format.php where post-format could be gallery, image, audio, status, video and more. If for some reason such a file is not found, it will always fall back to including content.php. That’s why you’re seeing a bunch of content-*.php files in the theme folder, but not all.
With this approach, child themes can override the behavior by simply providing a content-post-format.php file, and as you might know, WordPress will try to use the child theme’s file first, and then fall back to the parent if the child theme does not have one. You can even override the fallback content.php with your own.
The approach might be familiar from the loop.php method used in Twenty Ten, which is very similar, but called differently. I know people are now used to calling them the loop files, and some have even written books using that terminology. The truth is that get_template_part will accept any string for the file name, unless of course they’re reserved by the hierarchy.
Header & Footer Files
The header.php file has an awesome HTML5 browser support snippet which is ready to copy-paste to your own themes if needed. The rest is pretty simple and straightforward. Just note thatget_template_stylesheet_directory is not used any more, this again is because of the great support for child themes. Also note how the wp_nav_menu together with the theme’s stylesheet have a good fallback for the wp_page_menu for when navigation menus are not used in the admin.
The footer.php is even simpler — show the footer widgets and then the footer itself. What’s interesting here is that there’s an action there called twentyeleven_credits, meaning that with a simpleadd_action call we can sort of inject stuff into that section, right before the WordPress credits are output.
That could be done in child themes or even plugins, without having to modify any piece of the Twenty Eleven code, and without even having to override the footer.php file in your child theme. Beautiful, isn’t it?
Stylesheets and the Rest
Not the best stylesheet in the world, especially with the lack of comments. Not a problem at all, since with today’s debugging tools for Firefox and Chrome, it’s quite easy to change stuff in your stylesheet, although that might create some redundant code, and maybe some minor browser compatibility issues depending on what you’re trying to change or override.
Don’t forget that child themes carry their own stylesheet and the parent’s stylesheet is not included unless you explicitly ask for it with the CSS @import directive. That only applies to themes that provide child theme supports. Older themes like to link to the stylesheet directly in their header.php file.
The rest.. Well one more thing worth mentioning here is how the whole theme files are structured. Very nicely bundled, folders with descriptive names, languages and images, colors and javascripts. A separate inc directory for the theme options code, layout and javascript, which is a bright idea as well.
What Did We Learn from Twenty Eleven
We at Theme.fm have learned quite a lot of things there. In fact, Twenty Eleven has even changed our mindsets a little bit, about code structuring, and child themes support. The main point though, remains the Theme Options layout — keep it dead simple, don’t offer too many options and use the WordPress approach, so that people wouldn’t have to learn new ways to interact with WordPress themes whenever they install a new one. This applies both to free and premium themes, in and out the WordPress.org repository. Here’s an example of a custom theme options page:
So no more fancy buttons, fancy tabs, custom tables and typography in the admin panel? Well it’ll be difficult to get rid of those, especially for companies like WooThemes, who have crafted their frameworks with the admin extensions built in. I don’t think that WooThemes will step away from that, but my personal opinion is that they should.
What About You?
Tell us how you see the Twenty Eleven theme and the WordPress development trends these days. What do you think about providing Theme Options in a WordPress or custom way (a good post by Ryan on WPCandy about this), and how do you see the parent-child model now that it’s becoming more and more popular?
Use the comments section below to share your thoughts, and don’t forget to stay tuned to Theme.fm via our RSS feed. Cheers, and happy Twenty Eleven! 😉
