Grandchild themes? Really? Yes, they are possible but not popular with many lead developers arguing against this practice. Justin Tadlock, for example, writes an excellent post against the argument of creating grandchild themes, which PostStatus concurs with an apt statement: Grandchild themes solve "a problem to a bad architecture." While I am not sure that it is "a bad architecture" per se, but more a bad practice that creates a bad architecture.
Are grandchild themes possible? Yes. Are they maintainable? Yes with some great difficulty though not scalable. Is there ever an instance where it should be used? Possibly. The only scenario I can conceive is as part of an internal multi-site/sub-sub-site but besides this rare occasion, at the moment I cannot think of any that would justify the use of a grandchild theme over developing via branches.
So, let's look at these four: theme frameworks, parent themes, child themes, and grandchild themes a bit more closely.
Theme Frameworks
Justin Tadlock defines a theme framework as...
a set of conventions to use for developing WordPress [parent] themes.
Yet, I would differentiate between a a framework from a theme framework using the former in its more pure scope meaning "a reusable set of libraries, functions, classes for a system" or as Justin defines it "a set of conventions." A theme framework, on the other hand, is a parent theme that implements a framework. A framework displays nothing on the front-end or the back-end. In WordPress terms, a framework does not include or require to contain a functions.php or a style.css, as Hybrid Core. If I carry this to other themes or theme frameworks, I believe that "themes" like Genesis are theme frameworks as their primary purpose is to be extended and serve as a framework, yet there is a front-end and a back-end that is ready to be used and customized out-of-the box.
In other words, a theme framework is a parent theme or an advanced parent theme, as some call theme. Genesis, a theme framework, is an advanced parent theme.
Parent Themes
A theme is a completely new front-end layout of a WordPress site. While theme frameworks are always parent themes, not all parent themes are theme frameworks. Just like how all squares are rectangles ut not all rectangles are squares. Suares are a specific subset of rectangles.
Parent themes can be a fork of a theme framework as part of its core, and a parent theme can be a theme that sits on a framework within itself. Simply, parent themes use the WordPress installation and adds various forms of presentations and formats.
Child Themes
A Child Themes is:
a theme that inherits the functionality of another theme, called the parent theme. Child themes allow you to modify, or add to the functionality of that parent theme. A child theme is the safest and easiest way to modify an existing theme, whether you want to make a few tiny changes or extensive changes. Instead of modifying the theme files directly, you can create a child theme and override within.
As Justin later notes, child themes solve the problem of safe upgradability, which is imperative. For example, if you update and customize Twenty Eleven or Twenty Twelve, every time WordPress upgrades, you get in danger of losing all or some your theme customizations. However, if you use a child theme of those, then you can easily update without thinking twice. This is one reason why the upgrades of Genesis go so smoothly!
Child themes are typically done as a WordPress theme, and there are two plugins which assist you in making child themes:
- Child Themify (Downloads: [plugin_info slug="child-themify" data="downloaded"]): [plugin_info slug="child-themify" data="short_description"]
- Orbisius Child Theme Creator (Downloads: [plugin_info slug="child-themify" data="downloaded"]): [plugin_info slug="child-themify" data="short_description"]
Grandchild Themes
By default, WordPress cannot create a grandchild theme even though Smashing Magazine wrongly states this. However, Mark Barnes and AppThemes write a great tutorials on how to create a grandchild theme.
So why do some people believe they need to have grandchild themes? Theme shops like StudioPress focus on creating child themes that modify Genesis, the parent theme framework, with a few different functions, etc. Recently, Genesis has been updating some of these themes (e.g., Lifestyle, Outreach). However, in these updates, many have a new slug which forces people to properly upgrade a site manually. However, Lifestyle (among others), for example, did upgrade with the same folder slug. So having a site created based on this child theme that implemented a grandchild theme workflow would make maintenance, err upgrading, easier. However, in my opinion, this complicates the workflow, harms the client (who would just click upgrade without thinking through the ramifications and implications as would some novice developers), and is a lazy approach to keeping up code on a site. Furthermore, the upgrade in a Genesis child theme is never security as that is 100% addressed in the advanced parent theme. Instead, these upgrades are purely aesthetic.
In the comments of Mark Barnes's article, Eric Mann gives a great rationale and better workflow to editing a child theme than using grandchild themes stating:
If you are using a child theme for a system like Genesis, then you should fork it rather than try to hack your presentation into a plugin. Throw the current version of the child theme into Git or SVN, then create a dev branch to contain your customizations. If (and this is a big “if” since most won’t) the child theme is update, you can create a diff between the original and the new version using your VCS and apply the diff to your branch.
Is it more work? Yes. Is it an ugly hack using a plugin? No. Work with what you have, but don’t advocate a system like this that introduces a third level of moving parts into the theme’s presentation
Eric previously gives these reasons against Grandchild themes:
- Arbitrary limitation would need to be imposed on theming.
- A difficult, near impossible troubleshooting workflow
- Multiple developers, multiple development patterns
- Theme distribution of a grandchild theme is untenable
Conclusion
Personally, I don't believe grandchild themes will ever be implemented or supported in WordPress core, and rightly so. I believe that developers should seriously consider the relationships between their theme frameworks and child themes and possibily create a workflow that resembles a true framework, multiple advanced parent themes, allowing their customers to implement with child themes. However, with theme shops like Genesis or Thesis, this is more difficult as the advanced parent themes generate a lot of revenue. So, besides being a change within a development model, it would be a change in revenue and business models for them. And both models work well and address different user/client needs. I think StudioPress has created an excellent model which Nathan Rice, the lead developer behind Genesis, writes:
I was convinced that users would have a hard time with the Genesis concept, but to my surprise, we've evidently stumbled on something that users really love. My guess is that grandchild themes, or any attempt to synthesize that concept, would disturb the balance of an otherwise extremely popular methodology.
Have you ever used grandchild themes? Ever heard of them? Think they are a good idea? bad idea?
I enjoyed reading your writeup and take on this. I didn’t realize some folks were still talking about grandchild themes and thought the discussion had already settled.
I did want to make one correction though. Above, you wrote, “While theme frameworks are always parent themes, not all parent themes are theme frameworks.” That’s not exactly true. Theme frameworks are not always parent themes. In fact, several (such as my own) are not themes at all. I’d also argue that if you called any theme a “framework,” then all parent themes should be considered frameworks.
Thanks for your comment Justin! You’re right…my logic is incomplete. Here is what I meant, which I will include above.
I am differentiating a framework from a theme framework using the former in its more pure scope meaning “a reusable set of libraries, functions, classes for a system.” So, a theme framework is a parent theme that implements a framework. A framework on the other hand displays nothing on the front-end or the back-end. In WordPress terms, a framework does not include or require to contain a
functions.phpor astyle.css. I’ve read through Hybrid Core, and I believe it fits a framework idea perfectly, and your themes are parent themes. If I carry this to others, I believe that “themes” like Genesis are theme frameworks as their primary purpose is to be extended and serve as a framework, yet there is a front-end and a back-end that is ready to be used and customized out-of-the box.OK. I got you. You’re differentiating between a “framework” and a “theme framework”. The terminology is always confusing for some folks. On that note, we’ve mostly been calling frameworks like Hybrid Core “drop-in frameworks” to differentiate them a bit too.
My project uses multi-site to create a network of sites. The main site aggregates content from all of the sub-sites, which all generally have the same look-and-feel as the main site. The main site uses a parent theme and the sub-sites use a child theme.
I’ve developed a package containing the parent theme and child theme, along with some custom plugins so that this kind of network can be easily redeployed.
The challenge I’m facing now is that if users want to customize the themes… We can of course create a child theme to be used for customizing the main site. However, those customizations won’t be inherited by the child theme used by the sub-sites. This is where I can imagine a grandchild theme would make sense.
However, I’m interested to know if you have another suggestion for how this might work. Or, if you could elaborate on what you mean by “developing via branches”.
Thanks for this post! I am in the process of trying to get a grandchild theme working, and I am beating my head against the wall. Based on everything you have here, I will backup the files and just modify the functions, header/footer/stylesheet directly and look for differences down the road if the child theme is updated. Thanks much!
Here’s where I would like to use a grandchild theme, so maybe you could fill me in on a better way.
Let’s say I build a theme and someone installs it and starts using it. Then they customize the theme with a child theme.
Then later, I decide to set up some way for all of the people using my theme to do something like add a snowflake image background to a certain part of their sites during the Christmas holiday.
It might be cool to set this up as a grandchild theme that could be downloaded from my site, then just uploaded and activated from the WordPress dashboard.
When the holiday is over, and they don’t want that background anymore, all they would need to do is re-activate their own child theme, and the image would be gone, and their site would be back to normal.
Hi Travis
I just came across your article. To establish the playing field, I’m a huge Genesis advocate. I genuinely love it,. So much so, that I developed two commercial themes that enable eCommerce for Genesis (Envy and Envy Pro) … and there is where the difficulties began …
No matter how much we’d like to believe that we can develop a stable child theme that is ‘robust’ enough to rely on its parent for updates, there are always exceptions. I update my themes about three or four times a year, primarily in response to WooCommerce changes, but most recently in response to the new Accessibility features introduced to Genesis.
So, out of frustration (and a little customer angst), I developed an alternative to the grandchild theme. It’s called a Clip, which (like a grandchild, but let’s call it a second cousin) is an update-safe directory of ancillary files which can be used to store customizations. It’s plugin-activated and very simple to use. And there are plenty of benefits which you can see here – http://wpclips.net
I’d love for you and anyone interested to take a look. Feedback very welcome given your article and this comments thread.
Best always
Jon