At the risk of sounding dismissive, I have to admit that I roll my eyes most of the time I see people pronounce the inferiority of WordPress theme frameworks. I’ve been hearing this argument since before Genesis was even a conversation, much less an actual product.
But if I’m honest, I can see why some people don’t care for them, or denounce them by proxy for a particular segment of the WordPress community — “the users” — as being more, not less, difficult to use than a traditional theme.
I remember the first time I used a WordPress theme. This was before the days of documentation abundance. You couldn’t really just do a search for a question and expect there to be 100 answers available.
I was lost. I gave up. It took a year for me to try again.
Believe it or not, WordPress theming didn’t “click” with me until I cracked open one of Brian Gardner’s themes and looked at the code. Now he’s my boss!
I know better than most how incredibly intuitive a WordPress theme’s structure is. Header stuff in
header.php. Footer stuff in
footer.php. The stuff in between was in template files, named logically.
It all made sense. The PHP didn’t seem overwhelming because it blended with the HTML. It was natural, intentionally simple.
FWIW, even traditional themes have moved beyond this simple HTML + PHP structure. Even the default themes use filters, custom functions, etc. So, making the case against frameworks by referencing modern themes seems like a reach. But I digress …
So, Why Build a Framework?
If I loved traditional themes so much, what made me decide to build a framework?
At the time, I was building themes full time. Every new theme felt tedious, like I was doing the same work over and over.
I tried building a “starter theme”, but I would inevitably find things that could be improved, and though the starter theme (and future themes built from it) would get the benefit of the improvements, all previous themes will live in perpetuity with flaws.
That bothered me. I figured a good framework, appropriately abstracted, could reduce development time, resulting in more themes for users, and standardize an optimized markup structure. So I started building.
Turns out, building themes on a framework isn’t such a bad idea.
Hundreds of thousands millions of people now use Genesis. I think that speaks for itself.
After building, and continuing to build a framework for over 3 years, we realized that the benefits started to add up.
1. Change the look, not the code
Users are able to change the look of their site, while leaving their code in place. Their markup doesn’t change. Switching between one Genesis child themes is almost entirely CSS and images. This eliminates a good bit of the up front effort associated with switching themes. Also, search engines like the consistency.
And because theme settings remain the same between themes built on a framework, you don’t have to configure things more than once. That’s a time saver.
Also, because framework customizations exist separate from the framework itself, we (the developers of the framework) can push updates to users and fix bugs, add features, and improve their site with a simple upgrade process … something we made even better with the 1-click upgrade system in Genesis (the first commercial theme to offer this functionality).
But perhaps the biggest benefit of using a framework like Genesis is the amazing developer community that a consistent and actively managed project cultivates. I’ll come back to this in a second.
But Frameworks Suck, because …
There are some valid complaints about using frameworks. And in a vacuum, comparing a framework to a traditional theme, frameworks do seem more complicated.
HTML doesn’t live directly in the template files. Output is abstracted and hooked. I don’t know what a function is, and a filter is something I use to make coffee. THIS DOESN’T MAKE SENSE!
I think we’ve done a good job at mitigating these effects, though.
For starters, we’ve tried to bring some of that discoverability into our framework. For instance, we have a folder in Genesis called
/structure/. In this folder, we have files like
footer.php that contain the code that outputs HTML to those locations. I’ve had numerous people tell me how much that helps when transitioning from traditional themes to Genesis.
But remember when I mentioned that developer community above? The standardization and active development of a single codebase (the central concept of a theme framework) has a lovely side effect: people can figure things out, share them with others via blog posts, and the information is essentially valuable for ever.
And these tutorials accumulate and multiply.
So, while it may be a little harder to figure things out as a newbie DIY blogger just by looking at the theme code, there is a wealth of information and resources out there that will walk you through just about any question you have.
And that’s not even considering the OFFICIAL support you’ll receive if you purchase a reputable theme framework.
At the end of the day, it’s all about users. What do they like? What do they want? Obviously, developers can do it all, traditional themes or frameworks.
But beginners fall into two categories: the turn key blogger who just wants to get his theme installed, flip a couple of switches, and start blogging, and the person in the temporary state of needing to move past turn key but isn’t yet at the point where you can call them a developer.
For this person, it certainly seems like a traditional theme is more accessible.
But considering the starter choices they have in the abundance of child themes, the numerous resources from which they can find help and tutorials for common tasks, and the wealth of benefits offered by a framework, it seems like a small concession to give up the only real benefit a traditional theme offers.
So, who should use a framework? In my opinion, it’s the best choice for almost everyone. I know that’ll be a controversial statement, but I believe it.
At this point in time, rolling your own theme just doesn’t make a lot of sense. We’ve put literally thousands of hours into developing Genesis. Do you have time to give your self-rolled WordPress theme that kind of time?
And if you’re relying on a 3rd party for your theme, do they have the ability to deliver updates to your themes if they find a bug? Without a framework, this is nearly impossible to do.
In the end, I’m convinced the long term benefits significantly outweigh the temporary drawbacks of using a framework. My recommendation? I think you can figure that one out.