Consolidate add_theme_support() features into a single array

[mor10]

Right now various Gutenberg features are enabled (and disabled) through individual add_theme_support() declarations (documentation):

add_theme_support( 'align-wide' );

add_theme_support( 'editor-color-palette', array(
    array(
        'name' => __( 'strong magenta', 'themeLangDomain' ),
        'slug' => 'strong-magenta',
        'color' => '#a156b4',
    ),
) );

add_theme_support( 'editor-font-sizes', array(
    array(
        'name' => __( 'small', 'themeLangDomain' ),
        'shortName' => __( 'S', 'themeLangDomain' ),
        'size' => 12,
        'slug' => 'small'
    ),
));

add_theme_support( 'disable-custom-colors' );

add_theme_support( 'wp-block-styles' );

This lends itself to fractured and confusing code and makes it hard for anyone reading the code to quickly identify what features are on or off. It also allows theme developers to declare support for different features in different locations throughout the template files making the supports hard to find.

Ideally these theme supports would all be declared in a single add_theme_supports() array with references to additional arrays. Something like this (though probably not like this - someone with a keener eye for PHP should propose an actual solution):

$theme_colors = array(
    array(
        'name' => __( 'strong magenta', 'themeLangDomain' ),
        'slug' => 'strong-magenta',
        'color' => '#a156b4',
    ),
);

$theme_font_sizes = array(
    array(
        'name' => __( 'small', 'themeLangDomain' ),
        'shortName' => __( 'S', 'themeLangDomain' ),
        'size' => 12,
        'slug' => 'small'
    ),
);

add_theme_support( 'block-features', array( 
    'align-wide',
    'editor-color-palette' => $theme_colors,
    'editor-font-sizes' => $theme_font_sizes,
    'disable-custom-colors',
    'wp-block-styles',
) );

Benefits

This approach clearly stipulates, in one location, what Gutenberg (block editor) features are enabled/disabled in the theme and makes control easy. It also establishes a framework for future theme support controls and makes it easy for developers to spot them if they are enabled. As a bonus, adding all the features in one location surfaces issues around naming conventions and feature descriptions. Most importantly, consolidating all these feature under one roof so to speak makes themes easier to build and maintain.

Challenges

There are some challenges which need to be addressed around this, one of which was brought up by @westonruter in #2021 around child themes and overrides.

[0aveRyan]

+1 for consolidating to a single configuration array.

I'd also add that it's cumbersome to hook theme supports from Plugins (intercepting the global $_wp_theme_features array), so I'd extend @mor10's request for unified array to be filterable.

add_theme_support( 'block_config', apply_filters( 'block_config', array(
    'align-wide',
    'editor-color-palette' => $theme_colors,
    'editor-font-sizes' => $theme_font_sizes,
    'disable-custom-colors',
    'wp-block-styles',
) ) );```

[chrisvanpatten]

Are there any other core features that consolidate their theme support options in this way?

[youknowriad]

Wa had a similar configuration array originally and we decided to switch to more granular options. One of the reasons was the "child themes" as highlighted in the issue's description.

Also block_config or block-features seems too abstract to me. It does feel similar to utils or things like that where it's just a random key holding a bunch of options just because we don't know how to organize them properly.

[mor10]

The actual name can be something else. As for the child themes issue, that seems solvable. I still think consoldation here is key, especially because new features will be added to Gutenberg in the future, and leaving them as separate theme support options will make theme development unnecessarily chaotic.

[0aveRyan]

@mor10 @youknowriad agree, actual string keys can be something else.

If there were a filter/filters for these that would also help mitigate the child theme concern, while also addressing current plugin pain.

[chrisvanpatten]

If we went to a full array-based approach, how does remove_theme_support work?

I'd also suggest that although it might seem tempting to bundle all these into a "gutenberg" or "block editor" array, a lot of concepts that Gutenberg introduces are likely to expand outward and impact other areas of core in the future. It seems shortsighted to bundle them all into a single area and psychologically reinforce the idea of the block editor and Gutenberg and all this JavaScriptiness being a self-contained entity—which it is now, but won't always be.

I feel like the problem, to a degree, is with add_theme_support itself; as far as I can tell, the implementation in Gutenberg is aligned with the way core expects it to be used (single properties). If that API is unnecessarily burdensome for theme developers—which is totally fair—perhaps that's an issue better raised in Core, rather than here.

(I am totally sympathetic to this not being the best approach from a DX perspective, to be clear. The idea of a register_theme function, with a supports array like register_post_type, could be really interesting in core; then you have filter access to modify the supported features. But changing the way developers register many theme support capabilities at once feels like a core API concern, not a Gutenberg concern. Gutenberg is making the problem more apparent, but isn't causing it or really the right place to fix it.)

[mtias]

I originally proposed a central point of configuration so I'm in favor of going in this direction. Enough time has passed that I think there's a bit more clarity around which pieces fall where, and there are more features that can be configured by the theme than before (colors, fonts, widths, etc).

All that said, I think it's crucial to imagine a world where most of the theme configurations are absorbed as block properties.

For example, the "width" support doesn't make a lot of sense as theme configuration, because it actually depends on more granular context. it only takes a theme that has some pages as single column and others as multiple columns with sidebar for the "full-width" option to stop making sense.

That to me indicated that "widths" are related to the block container in terms of layout. I could see InnerBlocks being able to define which width options should be available when it is used.

So if you have a site with a main content column and a sidebar, the InnerBlocks powering the main content would have a set of width / alignment options, and a layout that only has a main content column could have a different one.

Likewise with colors and fonts, I can see this being supplied to different layout regions, or being part of the root block for a full site building experience, determining which fonts should be used, based colors, etc.

All that said to consider a case where all theme configuration is actually absorbed in the block hierarchy. This might help us figure out what theme_support keys we should be using, as they could emulate the kind of blocks we'll have once phase 3 is completed.

[gziolo]

We now have the official proposal from @youknowriad https://make.wordpress.org/core/2020/01/23/controlling-the-block-editor/ and filed under #20588 that in my opinion perfectly aligns with the proposal shared here. @mor10, can you double-check it and share your feedback? I'd prefer to close this issue so we could keep the conversation going in one place. What do you think?

[youknowriad]

Let's close and consolidate on a single issue, it seems like it's generally the same idea. Let's continue discussing there and let us know if we missed anything.