Nathan Rice

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 we work together!

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.

Soon after, Brian approached me and it turned out that we had similar goals, so I came to work for StudioPress.

Turns out, building themes on a framework isn’t such a bad idea. Hundreds of thousands millions of sites have used Genesis since its introduction. I think that speaks for itself.

Other Benefits

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.

2. Updates

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).

3. Community

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 header.php and 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.

The Users

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.

Conclusion

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.

If you haven’t heard, Genesis 2.0 is coming soon (you can run Genesis beta by using this plugin). And with it comes the ability to make your site output HTML5 markup and Schema.org microdata, which put a new emphasis on semantics in the way we mark up out content.

With this in mind, it became clear to us that our old loop hooks just didn’t pass the smell test. “post” simply does not accurately describe the types of content you can manage with WordPress. For instance, pages. Or worse, the infinite possible content types you can create and manage with Custom Post Types.

Using the genesis_before_post_content hook to insert something before the page content makes very little sense.

So we decided to update the Genesis loop function to reference the “entry” instead. We also updated our tag classes to follow this same pattern: entry, entry-header, entry-title, entry-meta, entry-content, entry-footer … you get the idea.

Note: if you’re using Genesis without HTML5 activated, all the old hooks and markup work as before. Genesis 2.0 is 100% backward compatible.

If HTML5 is not active, it uses the legacy loop (with all the old hooks and markup).

So, if you want to insert something after a post, page, or custom post type, you need to use the genesis_after_entry hook.

Pretty simple.

But the same goes for the things that you would want to unhook.

If you want to remove something from executing, you need to remove it from the new hook, rather than the old one. Here’s a list of the default entry element actions:

	add_action( 'genesis_entry_header', 'genesis_do_post_format_image', 4 );
	add_action( 'genesis_entry_header', 'genesis_entry_header_markup_open', 5 );
	add_action( 'genesis_entry_header', 'genesis_entry_header_markup_close', 15 );
	add_action( 'genesis_entry_header', 'genesis_do_post_title' );
	add_action( 'genesis_entry_header', 'genesis_post_info', 12 );

	add_action( 'genesis_entry_content', 'genesis_do_post_image', 8 );
	add_action( 'genesis_entry_content', 'genesis_do_post_content' );
	add_action( 'genesis_entry_content', 'genesis_do_post_content_nav', 12 );
	add_action( 'genesis_entry_content', 'genesis_do_post_permalink', 14 );

	add_action( 'genesis_entry_footer', 'genesis_entry_footer_markup_open', 5 );
	add_action( 'genesis_entry_footer', 'genesis_entry_footer_markup_close', 15 );
	add_action( 'genesis_entry_footer', 'genesis_post_meta' );

	add_action( 'genesis_after_entry', 'genesis_do_author_box_single', 8 );
	add_action( 'genesis_after_entry', 'genesis_adjacent_entry_nav' );
	add_action( 'genesis_after_entry', 'genesis_get_comments_template' );

So there you go! New semantic HTML5 hooks in Genesis 2.0. Enjoy!