A Multi-Theme System, the Decade-Long Wait for Grandchild Themes, and Themeless Templates

Around 2010, child theming had finally caught its stride. Bigger theme shops were starting to take note, and some were implementing advanced parent themes that were meant to serve as a “framework” for creating child themes. The theme development community hit a bit of a brick wall amid this explosion of child theming. Grandchild themes became a topic of debate.

One of the use cases for child themes was to protect customizations made by end-users. When the parent theme was updated, those changes remained intact within the child theme. Users could get bug fixes and enhancements without worry. It was an ingenious system.

However, another use case for child themes was to create vast customizations of the parent theme. Many of these child themes were marketed and sold to end-users. The problem? There was no way for users to protect their customizations if and when the developer updated the child theme. WordPress had no grandchild theme concept or any other sort of cascading theme system beyond the parent-child relationship.

So, the problem remained. Unsolved.

Some businesses such as StudioPress and its Genesis parent theme thrived over the years with this system. Others moved along. In reality, child theming became a niche feature that WordPress never expanded upon in any meaningful way. Theme authors were left to their own devices. With the arrival of the customizer and the expansion of page builders, code customizations almost disappeared. Most modifications were handled via an interface launched from the WordPress admin. The average user had little need to DIY their way through custom templates. Thus began child theming’s drizzle into near obscurity.

Gutenberg’s site editor, which will likely land in WordPress this year, had seemed to be the upcoming final blow to the child theming paradigm. Everyone from developers to end-users will be able to roll out custom templates directly from the WordPress admin.

However, should we be rethinking the role of a hierarchical theming system?

Full Site Editing is already introducing an extra level to the hierarchy. Traditionally, WordPress theming had a two-tier template hierarchy. In the future, it will add a tier for user-created templates. If that is possible, why not go ahead and throw in grandchild themes? Or, simply do away with such arbitrary limitations altogether?

A new pull request to the Gutenberg repository essentially creates a multi-theme system. Or, rather, it creates a multi-theme templating system. Aside from the style.css, functions.php, and theme.json files, block-based themes are essentially a collection of templates.

The patch is proposing that users should be able to opt into this multi-template system. They would have the option to keep templates from an old theme around when they switch to a new one. While not currently implemented in the pull request, he also proposes allowing users to clone templates from their old theme.

“In recent months, there have been whispers around the future possibility of multiple themes being active, templates being ‘themeless,’ etc.,” wrote the patch creator. “This branch is an implementation of that. The idea behind this implementation is there can only be one active theme at a time, but the wp_theme taxonomy can be used to link up individual templates / template parts with one or more themes at a time.”

It does not fulfill the dreams of a decade-old grandchild theme system. However, it could provide some precedent for exploring a full hierarchical theme system.

With the simplification and further standardization of how themes work, we should be dusting off old ideas and shoving them into a new light.

Full Site Editing will eventually solve the grandchild theme problem regardless of whether it had intended to. With the new tier of custom user templates, the upgradability problem created years ago will simply disappear. Users will be able to readily update their parent and child themes without fear of losing customizations. WordPress will safely store their custom templates in the database. It will even keep their design changes via the Global Styles system. Maybe, just maybe, child themes will begin to reach their initial height of popularity.

With the proposed system, users could mix and match templates from unrelated themes. If this happens, it begs the question of whether theme templates are even necessary.

Last year, Rich Tabor opened a discussion on the possibility of a single master theme for WordPress. In that system, WordPress would create a set of base templates. Theme authors could simply override the pieces that they wanted. They could even pare themes down to simple style.css and theme.json files.

That almost seems to be a recipe for bland and boring themes. However, if you couple it with a template directory on WordPress.org similar to what GutenbergHub has already introduced, users could pick and choose the templates they want. It could be both wondrous and disastrous, but I would not mind exploring the idea.

WordPress and its Gutenberg project have a lot of options on the table. Theme building could become interesting in the next year or two.

Update: some names have been removed from this post at the request of the people in question. While this is not standard procedure, they were removed because they were not integral to the story in this instance.

5

5 responses to “A Multi-Theme System, the Decade-Long Wait for Grandchild Themes, and Themeless Templates”

  1. Anh Tran says:

    That will be a great news for WordPress users and developers! The single relationship between parent theme and child theme is the bottle neck of the customization for years. This opens a lot of possibility to change the theme with less code.

    Report

  2. Thanks, a great read. I hopped on the WP bandwagon some five years back.

    I find the whole “theme” and “template” and “customization” environment to be a real digital wild west. Making educated decisions is tough.

    One interesting world would be one where “Theme” would be abolished from the WP dictionary/practice and instead there’d be two separate instances: “Skins” and “Templates”. Templates would offer output per conditions, Skins styling. No optional functionality allowed in Skins or Templates. That would be Plugin’s territory.

    Report

  3. Sven says:

    Currently for the (long) migration process from a pagebuilder using shortcodes to the Gutenberg-Editor it would be very helpful to be able to have two themes active in parallel and be able to decide on a page-per-page basis which one should handle this current page.
    (for speed reasons it is currently not “ok” to have the “bloated” theme in the background even when you built already a page with Gutenberg)
    Any chance to get this done on the shorthand?
    Thanks,
    Sven

    Report

  4. Lukasz says:

    I hate child themes from DEV perspective, now we may even have grandchild themes? Don’t like the extra bloat and fighting the parent theme, waste of server resources.

    It was never intuitive with child themes but that’s all there was to get critical updates and new features from the parent theme.

    Templates sounds way better!

    Report

  5. Thanks for the post, Justin. I appreciate the long view on WordPress that you present. It’s great to see the variety of new paths to theme development being explored. I might even get with a core parent theme if it’s rolled out as you’ve written.

    That said, child themes can continue to be helpful, at least for the near terms, to new (to WP) developers, theme houses and for quick builds. Developing child themes can be a great way to learn WordPress theming. I know I did that before I started developing custom themes.

    To my mind, the more options available, the better.

    Report

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: