FSE: support for child themes

[oandregal]

The next default theme TwentyTwentyOne (TT1) will explore FSE editing support, including Global Styles. It's also thought of as a teaching tool for other people to create child themes.

Ideally, child themes would also be able to override parts of its parent theme.json without having to write a new one.

[aristath]

Just a note here: It's not just parent-themes and child-themes... It's also possible to have grandchild-themes, so this will probably need to be recursive and go up the themes-inheritance tree.

[ZebulanStanphill]

@aristath While I can't find any definitive source, I thought WordPress never officially supported "grandchild" themes.

[aristath]

Officially yes... But unofficially they do work fine provided the grand-child has minor changes and they are not that rare. With FSE themes it will be even easier (and in some cases even desirable) to have grandchild themes

[oandregal]

Going to pause #27305 for now. I've seen there's rapid movement in the FSE/templates area and I believe when that's more settle I can resume this work.

[MaggieCabrera]

Just a heads up, we are currently exploring block-based child themes and we found out an interaction that is a bit of an edge case but is relevant to this discussion. Having a parent theme that has a template/index.html defined and a child theme that doesn't, but instead uses an index.php file, we encounter two things:

• FSE is not active, which is what we expected to happen
• The index template that's being used is the html one from the parent, instead of the php file from the child. We expected the php file to have prevalence over the parent's html.

[annezazu]

Wanted to pass along feedback from the eighth call for testing for the FSE Outreach Program as it relates to exploring child themes within a block theme world:

It appears WordPress 5.8 doesn’t support Block-Based Parent Themes, as theme.json files are only loaded from the active theme using get_stylesheet_directory(). I see this open issue, but having WP_Theme_JSON_Resolver only merge the active theme’s theme.json without merging the parent feels like a large omission (that’s also not a huge lift to address… as the JSONs are already merging with a Core copy). I realize there’s a brave new world with FSE where block-templates and block-template-parts start to chip away at the classic use for Child Themes… but especially for the theme.json, it seems particularly helpful in the scenario of a WordPress Multisite with one parent theme and each site extending/overriding Colors, Typography, etc without needing to entirely nuke/copy-pasta the parent’s theme.json file. In fact, I see one of the best benefits of the theme.json is providing a “preset” for another Theme that doesn’t require overriding templates (block or classic) but the child theme is a one-file override via theme.json.

If this needs to be reported in a new issue, let me know!

[bobbingwide]

I have a comment on child themes, partly in response to part of @annezazu's reply in the Outreach program comments,
but also related to my experiences attempting to develop a child theme.

In the future, child themes as a concept likely won’t make a ton of sense as there likely won’t be much shared code between the two once theme.json is even more robust with what it supports

On the contrary, I believe child themes make a lot of sense.

1. To add functionality
2. To restrict functionality

Child theme to add functionality

I've already implemented a child theme - Wizzie is a child theme of Fizzie.

• Wizzie is implemented at woocommerce.wp-a2z.org
• Fizzie is implemented at blocks.wp-a2z.org
• Fizzie implements the templates and template parts needed for both subdomains
• Wizzie implements the custom WooCommerce templates for Cart, Checkout, My Account, Shop and Single Product.
• For information see https://woocommerce.wp-a2z.org/oik-themes/

In my solution:

• Wizzie enqueues the template theme's stylesheet
• Wizzie implements its own theme.json, completely replacing the parent theme's file.

Re merging theme.json files

It would have been nice to have been able to have multiple theme.json files merged automatically.
But I imagine that, with the current specification, this process could produce unexpected/unwanted results.

The only differences between Wizzie and Fizzie's theme.json files are:

1. Added two new colours to the palette

        { "name": "Woo Purple",
        "slug":  "woo-purple",
        "color":  "#a46497"
        },
        { "name": "Woo Deep Purple",
          "slug":  "woo-deep-purple",
          "color":  "#96588a"
        }

2. A different default font-family

 "typography": {
      "fontFamily": "var(--wp--preset--font-family--geneva-verdana)"

3. A different default link color

"elements": {
      "link": {
        "color": {
          "text": "var( --woocommerce )"

4. A different border color for tables

 "core/table": {
        "border": {
          "color": "var( --woocommerce )",

It would be nice if the child theme's json file only contained the differences.
But there's no way of indicating the intention.
How do you indicate the removal of something?

I can see how easy it would be for new colors to be added to the palette,
and perhaps how a color can be overridden, by matching slug,
but not how to disable particular colors.

Child theme to restrict functionality

I hear many agencies complain about how hard it is to restrict their customer's ability to style content.
They want to prevent users from choosing Drop caps, setting a custom font size, or defining weird background gradients.

theme.json provides many options that can be enabled/disabled.

I imagine that many theme developers will want to enable all the options
and that agencies will want to turn them off again.

Providing a child theme seems the most logical solution, with the child theme's theme.json file overriding the parent theme's settings.

But it may also be necessary to disable certain custom templates. How will that be achieved?

[overclokk]

I just found this issue, I think child themes will have theire own space in future of the FSE, also a grand-chil approach would be great in core. #33512

I've not tested it but thinking that just to restrict functionality to parent from child should be done by adding false to a value in json, like this:

// child theme.json
{
    "version": 1,
    "settings": {
        "color": {
            "palette": [
                {
                    "slug": "black",
                    "color": false // remove value from parent
                },
                {
                    "name": "White",
                    "slug": "white",
                    "color": "#ffffff"
                }
            ]
        }
    }
}

Just thinking.

[aristath]

Just a quick update: A few days ago I started working on a proof-of-concept PR to fix some child-themes issues (#33445). It's still at an early draft stage, but there will be updates coming there in the next few days.

[overclokk]

Hi @aristath
just a pseudocode for your implementation on #33445 implementation https://3v4l.org/feiXa (it is a bit ugly but it does its job)
The idea is to have a way to add in future also a grandchild theme (maybe).

[Mamaduka]

Created PR to add basic support for child themes - #34354.

I think merging global styles can be done as a separate PR.

[Mamaduka]

I merged basic support for child themes this morning, and it should be available in Gutenberg 11.6.

Next step

Allow child themes to override parts (or entirely) of the parent's theme.json settings.

[scruffian]

We had a go at this here: #35459

[Mamaduka]

👋 Parent/child theme.json merging PR is ready for testing. I would appreciate more eyes on this one 🙇

[Mamaduka]

Now that parent/child theme merging has landed in trunk; we can close the general issue.

@oandregal, what do you think?

[oandregal]

Hey, absolutely. If this is working, we should close it. Just left a comment for clarifying one use case #35459 (comment)

[Mamaduka]

Sounds good, @oandregal.

Let's track the theme supports issue separately.