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.
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
- The WordPress Codex page on frameworks
- Ian Stewart on A revolution in theming: theme frameworks
- Justin Tadlock on frameworks, parent themes, child themes, and grandchild themes
- Ryan Imel on the beauty of simpler themes
- Nathan Rice, In defense of theme frameworks
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.
Still reading through this, but I noticed the link to my post under “further reading” seems to link to Nathan’s post 🙂
Derp. Fixed!
Great article.
I think it depends on the project you are working (small/large), your client (techy/non-techy), and on your needs. I use Genesis, Canvas, Builder, _s or just a parent theme depending on the project and the customer.
Anyway, I agree 100% users should not be able to activate parent themes. And love the idea of core plugin dependency.
There’s lots of good thoughts here. If I’m going to use a framework at all, I favor the approach of drop-in frameworks. I’ve used the dependable Hybrid Core in one project. I would like to take advantage of the extra features of Genesis, but I’m hesitant because of the problem of updating commercial child themes that have been modified.
There are…
Two thoughts:
1) #4 is the only actual “framework”. The first three mis-use the term.
Clarity on this issue is important to me, because I would eventually like to be able to vet *actual* frameworks (i.e. drop-in code libraries) in the official Theme directory, to facilitate their use and update in directory-hosted Themes. I don’t know if that’s a pipe dream or not, but it would seem that consistent nomenclature would, at the very least, be a prerequisite.
2) Requiring only the activation of Child Themes would be insurmountably difficult for end users, even if the monumental infrastructural requirements (Theme directory integration in the WordPress admin) could be overcome. It’s a nice thought, but I don’t see it being feasible any time soon.
Right now, users can go into their admin, peruse available Themes, and install, customize, and activate in one fairly easy process. To make that process work consistently in a Child-Theme-Required scenario, the Theme SVN would then have to host not only every stand-alone Theme, but also a generic Child Theme for each stand-alone Theme. Do we have that child Theme generated on-the-fly? Do we require Theme developers to bundle it with their Theme ZIP file on upload?
And even then, requiring Child Themes still wouldn’t fix any but the most basic of issues (i.e. style-only changes). Users who need/want to modify template or functional files will still need to get their hands dirty with the parent Theme.
And also: *requiring* the use of Child Themes would not be consistent with the spirit of free software philosophy that WordPress espouses. End users should be able to do whatever they want with the Themes they install, and WordPress should not actively interfere.
What if WP would check if some theme X is using theme Y as parent and then the activation link in admin panel would be removed just for the theme Y?
In this case problem would be solved locally and no need to make child theme for every parent theme.
Actually this functionality that I just thought of, most likely could be made as a plugin.
Chip,
I totally agree that only #4 is a “framework” in the truest sense. I was talking in terms of how they are viewed. That was much of the point of this article 🙂
As to this point, I don’t really understand or agree. I think packaging a default child theme with the parent, or generating one on the fly would be fine.
Basically, my goal would be that when a user clicks “Install theme” WordPress determines if it’s a parent or child theme, and installs both but activates the child. I’m sure it has its challenges, but it seems possible to me, without burdening users. Consider the current burden for users of creating their own folder structure, stylesheet comment blogs, zipping folders, and uploading or FTPing. My alternative seems much simpler.
I think there is much more about child themes than styles. You can of course override any template of a parent theme in your child theme, not just CSS. It’s a key part of child theming workflow. I’d assume you’re very familiar w/ this workflow, so maybe I misunderstand your statement.
I don’t think the infrastructural challenge would be as simple to resolve as you imply. Post Formats UI was child’s play compared to what would be required to make Child-Theme enforcement a seamless part of core.
(Side issue: the Theme directory hosts Child Themes. What happens if a user installs a hosted Child Theme?)
You’re absolutely correct that there’s much more to Child Themes than style changes. My point is that it has been a tough row to hoe just getting mainstream usage of Child Themes for *any* change to an installed Theme.
But if you force users to use Child Themes, that forced Child Theme will consist of one file: a style.css. (You could include an empty functions.php, but an empty functions.php can potentially cause problems, and should probably be added by the end user only if needed.)
So, two things:
1) If the user wants to make changes *other* than mere CSS, the user is still going to have to use FTP to get into the installed Theme, copy files to be modified, etc. And any users capable/comfortable doing that will be capable/comfortable with creating the initial Child Theme themselves.
2) If the user wants to make *only* CSS-related changes, I would recommend *not* using a Child Theme, and using a Custom CSS Plugin instead.
Maybe, instead of trying to force users to use a Child Theme, it would be more beneficial for core to provide a way – in core – for users to input custom CSS and custom functions – essentially core Plugins for Custom CSS and Site Functionality.
Generating child theme on the fly could be difficult. Some themes needs to have @import rule in child theme style.css. Some themes load parent theme style.css automatically and there is no need for @import rule in child theme style.css.
So packaging a default child theme with the parent theme could work better. At first it might be strange for the end user when they try to modify theme.
“Wait, there is a parent theme, where? What, there is actually two themes installed?”
At least all theme builders should provide base child theme in their theme page.
I don’t have any problems with the term “framework” at all. It’s just a helper term – as well as “ecosystem” – to explain something somewhat more complex a bit better. Also, I don’t care if this term may come in four different “tastes” like you summarized above. I really don’t see the problem(s) some may have with (theme) frameworks. In my opinion, just like Nathan Rice pointed out in his great post, the benefits outweigh the flaws by far.
A few more notes to your post here:
I consider Genesis also a framework in the “truest sense” (stupid term, really), as it has one of the highest levels of abstraction, and has become a real “ecosystem”. Not to forget, they dropped quite some features in the last versions, to move them into plugins or whatever. One of the few themes/frameworks/whatever going in this direction, really interesting point! Also, they (StudioPress/Copyblogger) don’t seem to use the term “theme framework” often (if at all?), they use “design framework” for quite some time (I guess over a year or longer?).
What is also really interesting, that only “Gantry” is a plugin of those listed above. All other you mentioned above have to be activated via /themes.php being it a parent or child theme. A really interesting point!
This is a point that I see rarely these days: when a user wants to customize the theme, I would suggest via a plugin! REASON: A lot of these customizations aren’t theme-dependent so would have to be made with every future theme – so that is really plugin terrain! Sooner or later users have to be educated with the hooks/filter concept to make their custom stuff. Plugins are best for that, anyways!
Regarding child themes, in my opinion there were made a lot mistakes when indrocing them some years ago. I mean not technically but in sense of “promoting”/ “marketing” them to the end user. They are quite “unvisible” in the backend, beside a few notes, often only in light gray font…
This could be done much better beginning with the overall wording, in backend, on .org, Codex, wherever! I agree, that the default Twenty-something themes should come with a child theme by default and that should be the one that gets activated if I activate one of those default themes. Or, there should be an on-the-fly-generation of a child theme at least consisting of the style.css (and maybe a functions.php).
This step makes only sense, of couse, if wordpress.org/Automattic/etc./etc. would start really promoting this and educating users.
I have seen too many users tweaking their (default Twenty…) theme and lost all on updates. A child theme would have been a life saver to them.
Hey David,
Thanks for your reply.
I actually like the concept of abstracted code. Who wouldn’t? As you bring up, it’s some of the parts of how it’s done in the parent/child setup WordPress utilizes that worries me a bit more.
I think products like Genesis are great. I think it really enables quality developers to develop faster and more reliably. And I think some end users will find the methods for customizing a theme that way easier than alternative routes.
However, that doesn’t make it for anyone. I think each style of framework listed above, and each has their flaws. For instance, indeed updating a drop-in framework can be challenging. But I like that I have control over all markup for drop-ins, and can simply manage the includes folder for updates. However, it would make more sense as a plugin to me, just the way I feel for Genesis’ and other parent theme frameworks’ functionality.
Regarding child themes, I think we are on the same page!
That is, what I highly suggest to do! And I note, you said “Plugins” which is what’s the best solution for this!
Using theme frameworks have opened up a whole new possible world to me in building websites. I’ve been building most of my websites on the Genesis framework lately and I love how easy it is not only to build it, but to pass it off to my clients and allow them to update their homepage areas and feature different content.
I have always asked this question for the longest time! I still don’t understand why authors refer to them as frameworks and funny enough people believe them and pass the terms to their peers.