On WordPress themes and frameworks

framework

Let’s pull the bandaid off real quick, and it won’t hurt as bad: Theme Framework has turned into a marketing term.

I lean more every day to giving theme framework the premium treatment. Just because a product costs money doesn’t make it premium at all. Nevertheless, the marketing term came and it stuck, and almost everyone uses the term. Well, not me. I completely agree with this post that commercial products should be called such.

Similarly, the term theme framework has become completely loaded. From a technical software perspective, it is defined like this:

In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. A software framework is a universal, reusable software platform to develop applications, products and solutions.

Wikipedia

In the WordPress ecosystem, the term theme framework was introduced (I think) in early 2008, and was already relatively prevalent by 2009. I’m not sure who was first, but I’m going to give credit to Ian Stewart for officially coining the term. Even before then, Ian and other leaders in the theme sphere where thinking about the need for abstracted code, but the mechanisms weren’t yet in place to pull the concepts together.

What is a theme framework?

The challenge in answering this question is pretty much why I’ve come to just consider it a marketing term. If forced to break frameworks down into four groups, I’d do so like this:

Visual frameworks

There are a number of such frameworks. iThemes Builder, Headway, and Pagelines are a few you’ve likely heard of. These visually driven parent themes that are meant to offer a simple to use interface for mostly non-coders, but experienced WordPress users to customize their websites. They take the options provided from this interface and customize the output accordingly.

Of all types of theme frameworks I’m discussing, these visual frameworks tend to offer the most flexibility to end users, but the least flexibility to advanced users and developers.

Starter / forkable themes

The most notable starter framework theme today that lives to serve as a forkable codebase is Automattic’s _s theme. Automattic uses _s for pretty much all of their WordPress.com projects, and many other theme developers use it as a base as well. Themes such as Bones and Starkers have also received a tremendous amount of adoption.

These themes give complete control to a theme author to use the template structure, markup, and perhaps some core functionality, but typically these themes are very light and intended not to have everything the end-website will need built in.

Flexible parent themes

Some of the most popular theme frameworks are designed to be very hook-heavy, flexible parent themes. Genesis is probably the most notable example today. Thematic, listed at the beginning of this article, is also a parent theme framework. Genesis has created an enormous ecosystem of developers and users that advocate this theme development method. WooThemes’ Canvas theme, more options heavy versus hook heavy, is another example. These flexible parent theme frameworks have also come to dominate the accepted vernacular for theme frameworks in general.

Therefore, if a keen WordPress user is looking for a “theme framework”, they are probably referencing an advanced parent theme that they intend to make custom child themes with. The parent theme is off limits from forking, as that’s where a huge majority of updates will occur.

Themes like these are very powerful. However, since the parent theme cannot be altered by the end user, the parent theme must maintain considerable flexibility, and users rely only on child themes and plugins to alter or change the defaults. Therefore, this creates a very tricky situation if a user decides to use a child theme they didn’t develop themselves, and then wants to make a change. There is no such thing as grandchild themes in WordPress, and can cause challenges if the user hacks the child theme and the child theme is later updated.

This requires a delicate balance from theme developers to prevent putting very much functionality in child themes, so that significant updates can be avoided.

Drop-in frameworks

Drop-in frameworks are probably the least known and worst marketed theme frameworks available today. A drop-in framework is probably the truest sense of a web framework in WordPress themes. Hybrid Core, Gantry and Carrington are popular drop-in frameworks.

If you were to think of drop-in WordPress theme frameworks in a general web sense, it’s probably easiest to do so in relation to something like Twitter Bootstrap or Zurb’s Foundation. These are meant to be complete folders of functionality within a web project, where the web project can easily utilize the complex functionality contained within the framework.

From a WordPress perspective, a drop-in framework gives a parent theme author a base set of functionality that is available, but all markup and items are free to adapt to your needs. In fact, a drop-in framework could tag-team with one of the forkable themes listed above to make it’s very own fancy parent theme. In full disclosure, that’s about what I did with Hybrid Core and _s for my own base theme.

So what isn’t a theme framework?

Exactly!

My beef with the term theme framework is that it’s pretty simple to twist any parent theme and call it a framework. Hell, I can even justify calling a plugin a theme framework.

In fact, if it were my way, the best theme framework may in fact be a plugin. If themes could easily declare dependency with core WordPress code (and of course if it became standard practice), then themes could simply require a plugin framework to enable certain theme functionality.

Therefore, isn’t all this theme framework nomenclature a bit ridiculous? Not to mention, we’ve created some real issues in the system itself of parent and child themes due to the popularity of complex theme frameworks.

Before I go further, I don’t want anyone to misunderstand. I think these varying ways of enabling users and developers to create wonderful WordPress websites is great. I’m simply trying to clear up much of the ambiguity I’ve seen over the years around the term itself, while also attempting to see if I can highlight some pain points maybe we haven’t seen before.

Let’s not forget traditional parent themes

With all of this framework talk, I’ve hardly mentioned the tried and true parent theme scenario. A traditional parent theme, developed to modern WordPress standards, is broken into many template parts, structured according to the template hierarchy, and generally relatively easy to understand and override certain functionality in child themes.

Well, in theory. Good parent themes will behave this way. When I picture a solid parent theme, I think of a theme that’s flexible, but also unique and well defined. I think that the default WordPress themes are great examples. The Theme Foundry (disclosure: this site’s partner) and Graph Paper Press are two more good examples. Of course they can be customized with complex child themes. But for the most part, if you’re using Twenty Twelve, you want to stick a few layers of paint on it and move on.

And this is how the system of parent / child themes in WordPress wants to work. The child theme isn’t meant to be a distributed product. It’s meant to be something users create so they can maintain their slight customizations and also receive parent theme updates.

The child theme problem

With complex frameworks, especially those that do not allow the parent theme to be altered, I believe child themes have a tendency to be more complex. Because the parent theme is advertised as a I-can-do-anything theme, people tend to do just about anything to child themes.

Highly custom child themes can be fine for custom builds. But I think it’s a bit dangerous for complex distributed child themes. And this is what causes users to want grandchild themes.

I think this can be solved if either a) more “parent theme” frameworks became drop-in frameworks. Or b) we re-analyze where the framework rests entirely and start putting them in dependent plugins. Under these two scenarios, we can get back to using the child theme for what it’s meant for.

Users should not be able to activate parent themes

I also believe that users should not be allowed to activate parent themes. The concept of parent and child themes is complicated for users. Ask any theme developer, and they will confirm. It takes consistent education and good resources to educate users why the need to activate their themes as child themes.

I would like to see WordPress require the Template: parameter in the style.css file to ensure that a child theme is being activated. And in order to prevent too much user friction, I’d also love to see some method to help users generate child themes quickly and easily, even if it’s just something similar to _s’s generation tool. And WordPress.org could just require both a parent and a child theme be uploaded, so that child themes can be automatically installed when a user chooses a new theme.

Further reading

What’s your experience?

I know that I’m speaking strictly from my experience and from the things I’ve read. I’d love to hear others’ experiences, and some good arguments as to why we should allow parent themes to be activated.

*image credit