Why I created a WordPress theme framework
First, I should give a shout-out to Ian Stewart for pointing the concept of theme frameworks out to me. If it wasn’t for him, I’m not exactly sure what I’d be doing in terms of WordPress right now.
Although The Sandbox was probably the first real use of this idea (at least that I know of), it was Thematic that really pushed the limits. I liked Thematic and would’ve designed child themes for it, but I like my own coding style a bit more than Ian’s.
Following his lead, I created the Hybrid theme framework. In this post, I’ll try to explain my reasoning behind this and address a few questions that have come up. This will not serve as a complete guide on theme frameworks; it’s just a few thoughts.
What is a theme framework?
I'm going to answer this in terms of my own framework, which may differ slightly from others' views.
A framework is a solidly coded theme that should serve as a base for other projects.
Some can be extended through the use of child themes. A child theme hooks into its parent (the framework) and uses all of its template files and functions. The child can change both the way the parent theme looks and functions.
I honestly could’ve written Hybrid as a set of plugins instead of a theme, but I prefer to work within the framework of theme development rather than plugin development.
Here’s a list of the things that should be the focus of a theme framework. Some of these things should be standard in any theme though.
- The number one focus should be on the theme user's content.
- Bullet-proof CSS with multiple variations.
- Valid XHTML with semantically-named classes and IDs.
- Dynamic classes that allow users to style individual elements according to the page the visitor is on and/or other factors.
- Should be flexible enough to make nearly any layout through CSS alone.
- Make extensive use of action and filter hooks to allow for overriding functions in child themes.
- SEO ready.
- Support multiple popular plugins that need to be added within template files.
- Provide solutions to common problems with WordPress.
- Compatibility with multiple versions of WordPress.
- Follow accessibility guidelines.
- Make the best use of microformats possible.
- Build on top of what others have done to make WordPress much cooler.
That’s the short list, but it covers the major bulletpoints of my list of things that should go in a framework.
WordPress is flawed
I don’t mean this in a negative way. I enjoy working with WordPress because it’s a very simple system that was made to be extended through themes and plugins. As a theme developer, it’s my job to overcome what I think might be flaws with the system, to provide solutions, a better user experience.
Sometimes WordPress spits out invalid XHTML (a rarity), but it happens. WordPress isn’t always the most accessible system on its own, which is something that should be addressed within themes. It’s probably one of the most beneficial platforms in terms of SEO, but theme developers should make this better. There are also things that I think should work in a different way, so I try to work those ideas into the theme.
When I say WordPress is flawed, I don’t mean that the system is bad. I mean this opens opportunities for theme and plugin developers to shape the sytem into something better than what it already is.
Why I really created a theme framework
I’m going to be brutally honest here and tell you that I didn’t create Hybrid for you all, at least not at first. I created it to have an easy way to manage my own blog.
I’ve never used a theme on my blog that I’ve publicly released before. Prior to Hybrid, I hardcoded just about everything around here. At a certain point, that becomes frustrating. So, when I started working on it, my goal was to make a theme for me, Justin Tadlock. I needed a theme that I could easily use out of the box, something that would cover all my needs.
I needed something that I wouldn’t have to hack up to make it work how I wanted.
Believe me, themes I’ve used here on my blog have been massively more complex than anything I’ve ever released into the wild. Recoding a theme from scratch every time I wanted a different look was not an ideal solution.
Once the theme was at a standard that was good enough for my own site, I started thinking about how to make it good enough for your sites. That’s when the theme framework was born. That’s why the first publicly released version was 0.3.
The second most important reason for creating a theme framework
I also wanted something that was flexible enough to use over and over in any number of projects. Reusing code is a foundation of good development practice. Whenever my coding skills advanced and I found a better way to do something, I’d have to recode each theme individually. With a framework, I only have to recode one theme.
Imagine if you had 10 themes to recode. Or even 20. Or 50.
Building the framework on top of semantically marked up XHTML is important here because if the XHTML is good, you can do some magical things with the accompanying CSS. I’ve coded two child themes for public release and two child themes for personal use in one month on top of the Hybrid theme. I’d be lucky to knock out two standalone themes in one month.
One could argue that solidly coding a theme from the start, coding a theme the right way, would do away with this problem. That’s true, to a degree. However, all developers and designers become better at their trade over time. I will not be as knoweldgeable today as tomorrow. Good practice this year might not be good practice next year.
This argument is trivial at best. If all software, themes, plugins, or even WordPress was coded the right way from the start, there’d be no need for new versions aside from enhancements. (This is to address your remark the other day, Ptah).
Are theme frameworks only good for developers?
Jeff Chandler posted this on Twitter:
basically, it came to a point where end users don’t benefit from theme frameworks , only theme devs do.
That may be an accurate comment in some regards. It’s also a question I feel that needs to be addressed in a longer, more thought-out post than this one. So, the question is ultimately whether end users benefit from theme frameworks. If they don’t, then we’re all wasting our time building them for anything outside of client work.
Here’s a list of things that directly benefit the end user:
- Rock-solid code for their site that is continually being updated and refined.
- Developers can churn out child themes more quickly, so the end user gets more choices.
- Easily skin your site with seasonal looks.
- You don't have to worry about adjusting to a new theme developer's coding style when changing themes.
- No need to transfer custom functions and features from one theme to the next.
- Building a community around one framework offers more ideas and neat things for the end user to work with.
I’m sure there are other developers that can add to this list.
Even with those benefits, there is another level of complexity. The idea of a parent/child theme relationship just confuses some people. I’ve had a lot of support behind the Hybrid theme and frameworks in general from my users at Theme Hybrid. Many of them have hopped on the child-theme bandwagon and haven’t looked back. But, there are still some users where the idea simply doesn’t register with them.
The biggest issue is understanding the concept because it is still a relatively new idea in the WordPress world, even if it has been around for some time. The best way to compensate for this is writing in-depth, quality tutorials for users that want to customize their theme.
I try to make some look at the framework as if it were a required plugin. Basically, it’s like saying that this is required for your child theme to work.
What this theme framework is all about
To break this entire post down for you, here’s the list of what I want to accomplish with my theme framework:
- Have a theme that's good enough for my own site.
- Ability to reuse code for child themes to release back to the WordPress community.
- Have a theme that would allow quicker turnaround on client projects.
- Make it easier for end users to directly benefit from theme updates without breaking their customizations.
Other resources and theme frameworks
Here are some useful resources on theme frameworks and child themes:
- How to make a "child theme" for WordPress This is the only guide you'll ever need. It also has links to loads of other references that I need not rehash here.
- Frameworks, Child Themes, Filters, and Hooks? A good writeup by Dan Philibin of WP Candy on the concept.
- Theme Shaper Ian usually has something to say on the subject, so just subscribe to his feed.
Theme frameworks you can try out:
- Hybrid (my theme, of course!)
- Thematic
- WP Framework
- The Sandbox
If you’ve created a theme framework, let me know, and I’ll add it to the list.
Final thoughts
If you’ve made it this far into the post, I’m happy that you’ve managed to make it through it all. I couldn’t possibly put down all of my thoughts and ideas into one post, so I tried to keep it as brief as possible. I’ve hardly scratched the surface of theme frameworks in this post though.
I would recommend trying out any of the frameworks mentioned within the post if you haven’t before. Also, post any and all questions you have regarding theme frameworks, parent themes, child themes, or anything at all dealing with this concept in the comments. I’ll try to address them either in the comments or a followup post.
Oh, and merry Christmas! I hope everyone has a great holiday season.