Taking only the simple definition under consideration, WordPress users are likely to get the impression that, all things being equal, you should use a framework. After all, who wouldn’t want the added benefit and “flexibility” of being able to have “child” themes. Sounds cool.

But once you unpack a framework theme and start futzing with it, you quickly realize all is not perfect in the land of “frameworks”. So here’s my stab at a more useful definition. A WordPress Theme Framework is a theme that has additional code built into it making selected tasks easier for theme developers to manage. The emphasis on developers is mine and is very important.

Over the last several months I’ve built sites using several different frameworks and found that there is little advantage consistent across all frameworks, though each framework has specific advantages. The only consistency is that to really benefit from frameworks you need to have a deeper understanding of WordPress, its syntax, functions, plugins, etc.

If all you want to do is customize a theme, frameworks are likely to drive you crazy.

In Theory

In theory, frameworks are a very powerful thing. The idea is that you can take certain standard needs of theme developers and abstract them into new functions that allow the theme developer to execute customizations without messing with the theme core. With many theme frameworks, if you know what you’re doing, you can perform most theme modifications by editing only the style.css and the function.php files.

By way of an example, the Thematic Theme Framework has a hook called thematic_above_indexloop();. If I wanted to add a feature ad banner above the index loop of a regular theme, I would have to go into the the index.php, find the loop, and ad the code. But in the framework I simply have to go to the function.php file and add the following:

function feature_ad_banner() {
echo 'my feature ad banner';
}
add_action('thematic_above_indexloop','feature_ad_banner');

This code just tells the theme to pull in my custom function when it triggers this action. This gives me a ton of power as a developer because I can easily build an awesome site without worrying about building the “guts” of the theme. Or, to put it simply, I can focus on the cool stuff while ignoring the mundane details.

It’s all about the HOOKS

The drawback is that each theme framework has its own peculiarities and learning the appropriate hooks and filters can take time. If you’re a developer, this time is justified because it saves time on future projects. But if you just understand the basics of WordPress themes and are simply trying to customize one for your own use …especially if you aren’t all that comfortable with PHP … this extra level of abstraction can be a royal pain in your ass. If you’ve modified a loop before, you’ll find modifying a loop in a framework isn’t nearly as simple as you remembered. You have to create your own function and then track down the right hook to apply it to. A mod that used to take you 15 minutes, now takes you an hour.

Again, there are rewards to learning a framework, but make sure you understand the time investment required and how that squares with the benefits you expect to receive in return.

In short, WordPress Theme Frameworks are great for those serious about development. But hobbyist might want stick with an old fashioned WordPress Themes. In future articles I will look a few different frameworks and when you mind be inclined to use them.

For the wordHeavy user, that is the designer/developer building their content management system on the wordpress platform, there isn’t all that much to be excited about. The easy theme feature is likely to further centralize theme development within the grips of WordPress.org theming rules. Not that there’s anything inherently wrong with this, I just worry about those designers who charge for their creations loosing market share to “free” themes.

Perhaps WordPress will come up with a more inclusive gallery system? Or maybe an enterprising developer will develop a competing gallery that can be installed with a simple plugin.

The one development I’m looking forward to using is the widgets. As a freelancer, you have clients who need a specific sidebar widget. A special campaign logo for instance. The need is small enough that it isn’t worth the time developing a custom plugin for the widget (even though it really doesn’t take that long). Instead, I routinely use simple text widgets to paste in the small bits of code.

Trouble is you can’t save a text widget for later use. So the client one day feels a little adventurous, start playing with widgets … they are fun to play with … and accidentally delete your modified text widget. Doh! Not that big of a deal, but a real pain in the ass.

But starting with 2.8, widgets can be made “inactive,” which means they are saved in the system. Sweet!!! Now all those little widgets can be safe from unnecessary annihilation at the hands of the unsophisticated end user.

Actually, they are not entirely safe. For some reason the WordPress developers didn’t take the next logical step. When you have a widget in the sidebar and click the “remove” action, the widget doesn’t dump into the inactive bin, it is DELETED! I think it would make sense for the to go to the inactive bin first and to have widgets only deleted from the inactive bin. That’s what I get for not keeping up with the WordPress developers email list. Oh well, maybe 2.9 right?

The other improvement on widget management is that you no longer have to click which sidebar you want to show. Nor do you have to save the widget (clicking the “done” button) and then also save the sidebar (clicking “save changes”). Now all the options and functionality are on one page. That reduces the number of needed clicks to add a widget by half. Little stuff for most, but big stuff for heavy WordPress users.

I used to handle this with a mishmash of plugins for calendars, downloads, videos, etc. But the problem was each solution was discrete. For instance, it was difficult to associate a video with an event. This is because, for all its advantages, the WordPress core simply is not a CMS. It basically has two content types: post and page. Yes, the functionality of custom fields helps boost the performance of these two types. But custom fields are cumbersome and user un-friendly.

What WordPress needed was some sort of content construction plugin that would allows users to create their own types of content beyond the post and page.

A few months ago, I discovered a new plugin that does just that. It’s called Pods. Pods is a very efficient framework that sits on top of your WordPress installation. It allows you to easily create content types and then theme those types.

Over the next couple weeks I’m going to post a series of tutorials on different ways you can use pods. In the meantime, head over to their site and download the plugin.