Recently, someone asked me if a given theme was compatible with another popular WordPress framework. The short answer is that no, it was not, but it did get me thinking: If there’s one word that’s becoming all too common in the WordPress space, it’s “framework.”

If you were to ask a handful of people to define “framework,” you would probably hear one of two things:

  1. Novice-to-experienced bloggers would say that it’s a theme with a variety of customization options
  2. Developers would say that it’s a way to more easily build a theme

I’m sure there are a few other responses but, generally speaking, this is what I hear and read the most.

Instead, I think that “framework” is way over used in the WordPress world and the lack of understanding has the potential to negatively affect both bloggers and younger developers.

What Does a WordPress Frameworks Look Like?

First, I think it’s important to understand how a framework is related to both WordPress and themes.

Check out the following the sketch:

WordPress without a framework

WordPress without a framework. Themes sit on top of WordPress.

Easy enough, right? WordPress is the core application and the theme is built on top of WordPress. This means two things:

  1. As a blogger, any customizations that are made are done so using CSS, child themes, or built-in options such as header images and backgrounds.
  2. A a developer, any functionality, such as the theme options, are (or should be) communicating directly with the WordPress API.

Given this model, if you were to change from one theme to another and the new theme supported core WordPress features like header images, then many of your customizations would be consistent. As a developer, all of your settings are saved in the proper location in the WordPress database.

If, on the other hand, you’re using a framework and theme on top of WordPress, then the setup looks something like this:

WordPress with a framework

WordPress without a framework. Themes sit on top of a framework that’s above WordPress.

Simply put, if you’re using a theme that is based on a framework, then all of your theme options are normally set within the context of the framework.

There are exceptions, of course, but the point still remains: a new layer has been introduced in between your theme and WordPress so the customizations that you make are more tightly married to the framework that WordPress itself.

  1. As a blogger, frameworks are exciting because they can make it much easier to customize your theme through many options like color pickers, font selectors, and so on.
  2. As a developer, frameworks usually introduce a new API for building themes such that your code is a hybrid between the WordPress API and the framework’s API.

Given this particular model, if you were to change from one theme to another, it’s uncertain that your customizations will persist – you’re at the mercy for the framework.

The Two Sides of WordPress Frameworks

On the upside, bloggers and developers both have the ability to take advantage of many of the new options that frameworks offer. This typically revolves around customization options, import and export of data, and the ability to create enhanced user experiences for clients.

They can provide extremely useful functionality, but more often than not I think many frameworks – though not all – turn WordPress into something that’s more like the wild west rather than introducing elegance into the core application.

Furthermore, I see the disadvantages of frameworks discussed far less than the advantages:

  • Frameworks create lock in. The longer that you use a framework, the harder it is to break away to try something new. If you’re an experienced developer, this may not be a problem, but if you’re a power user looking to switch themes, this is difficult especially if you’ve invested a significant amount of time in customizing your blog. You’re interested in swapping over to a new theme, but it’s not built with the same framework. At the very least, you have the potential to lose all customizations.
  • Developers are bound by framework versions. As a developer, making sure that your theme is compatible with the latest version of WordPress is one thing, but if your work is dependent on a framework, then you not only have to wait until the framework is compatible with the latest version of WordPress.
  • Frameworks create dependency. As with the illustrations above, frameworks sit between themes and WordPress. As a blogger, if a new version of WordPress comes out, you’re at risk to upgrade your installation until the framework is compatible. Simply put, you’re at the mercy of the framework developer. If it takes them two months to update the framework, you’re waiting two months to update your site.

That said, themes aren’t completely exempt from this. There are a wide array of themes that do not use WordPress best practices; however, most high quality themes will be properly using the WordPress API. This means that when a new version of WordPress is released, it’s unlikely that the theme will not be compatible.

Sure, WordPress deprecates functions just like any other software but they are vocal about it and they normally give developers several release cycles before completely removing functionality so it’s far unlikely that a high-quality theme is going to break on an upgrade.

What’s The Point?

Not all WordPress frameworks are bad. Some frameworks empower bloggers to do more with their blog without actually having to learn any code – some do this well, others do it poorly.

But the point remains: WordPress frameworks help bloggers do things that some themes do not and if a blogger is less concerned about WordPress upgrades or learning to write any code, then this works.

And for developers: WordPress frameworks introduce a level of abstraction for developers that prevent them from learning the core WordPress API. In some cases, I think that a level of abstraction is nice as it manages a lot of the fickle nuances that exist between an array of clients – think jQuery and JavaScript. This isn’t necessarily case with WordPress so I do question why so many developers opt to use a framework when the WordPress API is so powerful.

Nonetheless, whatever route you opt to take as a blogger or as a developer, it’s more important to understand what you’re working with when you introduce a WordPress framework into your work and the advantages and disadvantages you’re inheriting when doing so.

Category:
Articles
Tags:

Join the conversation! 11 Comments

  1. Really Good
    I liked this Part ‘The Two Sides of WordPress Frameworks’ the most.

  2. NIce article Tom. Have been trying to create a theme base for newer projects and was looking at Frameworks like Hybrid, but I guess best would be stick to the conventions of the default WordPress theme and built on it.

    • I’m not necessarily saying to completely avoid frameworks – if they fit the bill of your project, then that’s always great.

      My main concern is making sure you know what you’re getting into when you introduce a new layer into the stack of your project.

  3. I think it depends on the “framework”.

    Most of the “frameworks” are parent themes, wrapped up with a big bundle of functionality, hooks galore, and generally a lot of flexibility. That way someone can use either the theme api or WordPress system to alter the output of the theme.

    I would consider Genesis and Woothemes Canvas in this segment.

    The next type of “framework” you hear about is the wysiwyg kind. Drag and drop theme options, and the theme / framework spits it all out for you. Whether these are in the head to overwrite existing styles, or the options run certain hooks or whatnot to alter actual html output, the visual themes are kindof the same idea.

    I would but Pagelines and Headway themes in this circle of frameworks as an example.

    Then there are what I consider “real frameworks”. To me, a framework is a functionality suite that offers theme flexibility and functionality, and helps you not worry about certain repetitive tasks in WordPress. Justin Tadlock wrote a great post on the subject.

    Hybrid Core, WP Framework, and Carrington Build fit this mold of a “drop in” framework. They are closer to plugins than themes, they don’t run independently, but they do make it easier for a developer to do certain things. For example, registering sidebars, menus, handling entry title syntax, template management, etc. is made easier with the framework.

    Those are the three types of frameworks I think we most often hear about. Of course, like you say, the alternative is to roll your own parent theme independent of any framework. It’s definitely the most customizable route, and probably a really good decision if you have serious amounts of time to commit to the theme and you are comfortable building full scale WordPress themes. Like Standard : )

    Anywho, the conversation about frameworks always gets me going. My two ten cents!

    • My background is in software so when I think of ‘framework,’ I think more along the lines of what you’re describing in terms of Hybrid Core, Carrington, etc.

      They are true frameworks because they serve as a true layer of abstraction between WordPress and whatever code you’re writing and provide functionality that makes everything else a bit easier and offer additional, extensible functionality.

      As the various layers of web applications have become more advanced, we now have frameworks for the presentation layer (with Bootstrap), libraries for behavior (with jQuery), frameworks for middleware (like Rails), and for the data layer (like ActiveRecord) and I’m huge on separation of concerns.

      As such, I tend to be a bit of a stickler on defining what a framework is and what it isn’t … and I have to admit, I’m a bit of a purist so when I hear them used differently, I cringe *just* a little ;).

      Everything else boils down to exactly what you’ve said – parent themes and glorified options screens and that’s about it.

      Honestly, however people define framework in the context of their work is how it’s going to be used – if people refer to a huge parent theme as a framework, then others are going to follow suit.

      Regardless, the bigger issue at hand is for developers – especially newer developers – to understand the issues that you introduce into a project when you introduce a third layer in between your work and WordPress.

  4. I really like to keep things simple. I have my starter theme, which really is more just organization than anything. The only chunk of code that I use over and over again is a loop for a post type, but I’ll usually put that into a file and include it across the theme. I initially looked into using frameworks, but they’re usually so big! Not to mention, I wouldn’t be using many of the features it touts.

    I prefer to keep it simple and clean. Do it the WordPress way =]

    • Yeah – in my mind what you’re talking about is more of a boilerplate and I think those are excellent ways to begin projects.

      They provide a consistent base off of which to build each of your projects which really comes in handy the more work you end up doing.

  5. Sir, will you answer for my simple question ?

    Is using Genesis Framework is safe or it is also in the category of bad ones ??? Me want to learn from your experience and that’s why leaving at your skill set that should I go for it or not ? As I will be developing a lot of themes from now on … ???

    Waiting for any of your response … Thanks

    • Sir, will you answer for my simple question ?

      I’ll try!

      Is using Genesis Framework is safe or it is also in the category of bad ones ??? Me want to learn from your experience and that’s why leaving at your skill set that should I go for it or not ? As I will be developing a lot of themes from now on … ???

      Genesis is top-notch. Highly-recommended.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.