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?
Carlo Manfredi introduced a pull request to the Gutenberg repository that essentially creates a multi-theme system. Or, rather, it created 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.
Manfredi 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 Manfredi in the ticket. “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 Manfredi’s 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.
