Block Editor: Include the theme.json infrastructure code and support

[youknowriad]

Now that Gutenberg has been updated with the final format for theme.json that is supposed to land in WordPress 5.8, we can start back porting the php changes and infrastructure code needed to support theme.json features in Core.

Also, doing this will allow us to do three things that were postponed during the precent package update in Core due to the lack of theme.json support.

• Fully backport the layout block support.
• Add a conditional check about the "classic.css" dependency in the style loader (only load it for themes without theme.json file).
• Add the supportsLayout editor setting.

This ticket might potentially be blocked by the update to the Gutenberg 10.6 packages.

[youknowriad]

In 50958:

General: Add _wp_array_set function.

This adds the _wp_array_set function, which is the counterpart of the existing _wp_array_get.
This utility is to be used by the Global Settings work.

Props nosolosw, jorgefilipecosta.
See #53175.

[youknowriad]

In 50959:

Block Editor: Add Global Settings support using theme.json file.

This is the first piece of landing the theme.json processing in WordPress core.
It allows themes to configure the different editor settings, allow cusomizations and define presets in theme.json file.

Props jorgefilipecosta, nosolosw.
See #53175.

Part of https://core.trac.wordpress.org/ticket/53175

This PR ports the first piece of landing the theme.json processing in WordPress core. It deals with merging the new settings (__experimentalFeatures) for all editors to access. The second piece would be to land the stylesheet engine.

## What this PR does

• Adds a new setting __experimentalFeatures to the block editor settings. This data comes from theme.json (core and theme). ​See for the whole rationale about the theme.json file.
• Adds a theme-i18n.json file to WordPress core, to be used by core, the plugin, and wp-cli for translations.
• Adds the necessary code to make this work (namely the WP_Theme_JSON and WP_Theme_JSON_Resolver classes. These are used to pull settings from theme.json (core and theme). If you compare these with the ones that come with Gutenberg you'll note that this PR only includes the necessary bits for settings to work. Subsequent PRs will deal with adding styles, etc.

## How this can be extended

There are a few ways:

• For major changes (change how core and theme data is merged, changes to the shape of theme.json file, etc): because we're adding new data under settings.__experimentalFeatures this can be filtered by the existing block editor filters.
• To add more settings and its default values: two new filters are introduced.
  • theme_json_allowed_schema: to modify the schema used in sanitize the theme.json data.
  • theme_json_core_data: to set defaults for core data, including new settings added via the previous filter.

## Related work

Dependant PRs:

• Add _wp_array_set function and extract it from this PR ​https://github.com/WordPress/wordpress-develop/pull/1263 (to land first)
• Adapt Gutenberg for this changes ​https://github.com/WordPress/gutenberg/pull/32059

Follow-ups:

• Prepare a similar PR to add the styles engine.
• Port the changes to the merge algorithm introduced at ​https://github.com/WordPress/gutenberg/pull/31669 when the Gutenberg 10.7 packages are ported to core.

## How to test

A theme without theme.json:

• Activate the TwentyTwentyOne theme (doesn't have a theme.json).
• Go to the editor and make sure that there's a new key __experimentalFeatures available under settings in the core/block-editor store and that it contains the ALLOWED_SETTINGS (​see)
• A good litmus test is that the color palette is shown properly in the UI controls. Verify it's the same defined by the theme.

A theme with theme.json support (but doesn't provide specific color palette):

• Install and activate the emptytheme.
• Go to the editor and make sure that there's a new key __experimentalFeatures available under settings in the core/block-editor store and that it contains the ALLOWED_SETTINGS (​see)
• Check that the color palette shown is the one by core.

A theme with theme.json support (but does provide a color palette):

• Install and activate the TT1-blocks theme.
• Go to the editor and make sure that there's a new key __experimentalFeatures available under settings in the core/block-editor store and that it contains the ALLOWED_SETTINGS (​see)
• Check that the color palette shown is the one by the theme.

With the Gutenberg plugin active:

• Use this branch ​https://github.com/WordPress/gutenberg/pull/32059
• Go to the editor and make sure that there's a new key __experimentalFeatures available under settings in the core/block-editor store and that it contains the allowed settings passed from the plugin (see gutenberg_global_styles_theme_json_allowed_settings method).

Part of https://core.trac.wordpress.org/ticket/53175

This pull request adds the _wp_array_get function, which is the counterpart of the existing _wp_array_set. This is to be used by ​https://github.com/WordPress/wordpress-develop/pull/1262

[gziolo]

In 50962:

Editor: Rename the unit test file for _wp_array_set function

Follow-up [50958].
See #53175.

Part of https://core.trac.wordpress.org/ticket/53175
Follow-up to ​https://github.com/WordPress/wordpress-develop/pull/1262

## To do

• port tests
• prepare corresponding Gutenberg PR

## How to test

A theme without theme.json (use the TwentyTwentyOne theme):

• Load the front. Look for a global-styles-inline-css embedded stylesheet. The expected result is that none should be found.
• Load the post editor. Search for --wp--preset--color. The expected result is that none should be found.

A theme with theme.json support:

• Instructions TBD.

Need to update the unit tests and prepare the corresponding Gutenberg PR, but the code is ready for review.

[SergeyBiryukov]

In 50965:

General: Some documentation and test improvements for the _wp_array_set():

• Update the function DocBlock per the documentation standards.
• Move the unit tests to a more appropriate place.
• Rename and reorder the tests for consistency with _wp_array_get() tests.

Follow-up to [50958], [50962], [50964].

See #53175, #52625.

[SergeyBiryukov]

In 50966:

Tests: Correct description for the Tests_Functions_wpArraySet class.

Follow-up to [50958], [50962], [50964], [50965].

See #53175, #52625.

[SergeyBiryukov]

In 50967:

Docs: Some documentation and test improvements for WP_Theme_JSON and WP_Theme_JSON_Resolver classes:

• Add missing @since tags.
• Update some DocBlocks per the documentation standards.
• Rename test files and classes per the naming conventions.
• Fix some code alignment issues reported by WPCS.

Follow-up to [50959], [50960].

See #52991, #53175.

As per the follow-ups on this PR:

• Prepare a similar PR to add the styles engine. ​https://github.com/WordPress/wordpress-develop/pull/1287
• Port the changes to the merge algorithm introduced at WordPress/gutenberg#31669 when the Gutenberg 10.7 packages are ported to WordPress core. ​https://github.com/WordPress/wordpress-develop/pull/1289 (necessary since the packages were published this morning).

Part of https://core.trac.wordpress.org/ticket/53175

Follow up to ​https://github.com/WordPress/wordpress-develop/pull/1262 which landed in ​https://github.com/WordPress/wordpress-develop/commit/ef3da3363a94a85b664c1ac945eb7e920c541c17

The issue happens because the npm packages ​in use were published a few hours ago, which include some changes to how we manage colors. This PR adds the corresponding PHP changes.

## How to test

This fixes ​this issue.

• Use the latest wordpress-develop
• Update and install the Gutenberg plugin from ​this branch.
• Install and activate tt1 blocks from the theme install screen (installs from the theme's repo, not GitHub).
• Observe the color palette contains only the theme palette.

cc @jorgefilipecosta @youknowriad @ntsekouras

[jorgefilipecosta]

In 50973:

Block Editor: Add Global Styles support using theme.json file.

This is the second piece of landing the theme.json processing in WordPress core.
It includes the mechanism that outputs the CSS styles of a theme.json file.

Props nosolosw, youknowriad.
See #53175.

Committed in ​https://github.com/WordPress/wordpress-develop/commit/3d3aa3cd0950f3a44ce87ec8589a40c4460708f4 this PR can be closed.

Part of https://core.trac.wordpress.org/ticket/53175
See ​https://github.com/WordPress/gutenberg/issues/31322

This is looking good.

[jorgefilipecosta]

In 50977:

Block Editor: Update color merging algorithm.

The npm packages in use were published a few hours ago, which include some changes to how we manage colors. This commit adds the corresponding PHP changes.

Props nosolosw.
See #53175.

Committed in ​https://github.com/WordPress/wordpress-develop/commit/73bf1dab6b36b5634672b4b5e6e439f4c1b6e998 this PR should be closed.

Part of https://core.trac.wordpress.org/ticket/53175

This PR adds support for the layout hook. Blocks can declare via supports.__experimentalLayout and themes can use the theme.json to provide the values for contentSize and wideSize.

[youknowriad]

In 50991:

Block Editor: Add the layout block support.

The layout block allows containers to define the size of their inner blocks
and the allowed allignments.
It's only enabled for themes with theme.json files.

Props nosolosw.
See #53175.

[youknowriad]

In 50992:

Block Editor: Load the classic layout stylesheet conditionallty.

Historically, the block editor has been opinionated about the size of the canvas and the alignments.
Themes with theme.json will have to define a "layout" in their settings and the classic stylesheet won't be loaded anymore for this.

Props nosolosw.
See #53175.

committed

committed

[youknowriad]

This is now backported fully I think.

[noisysocks]

Hey @youknowriad, [50992] breaks style concatenation. You can see this by navigating to /wp-admin/load-styles.php?load=wp-components. This should show the CSS for @wordpress/components but instead results in an empty page with status 500.

The reason is because the file which defines WP_Theme_JSON_Resolver won't be imported by load-styles.php (and load-scripts.php) which bypasses the usual WordPress initialisation steps (wp-settings.php).

You'll need to wrap the call to WP_Theme_JSON_Resolver with a class_exists or import class-wp-theme-json-resolver.php in load-styles.php and load-scripts.php.

This is what is causing the failures in ​https://github.com/WordPress/gutenberg/pull/32176/checks?check_run_id=2663937068.

Fixes https://core.trac.wordpress.org/ticket/53175#comment:28

[youknowriad]

In 51001:

Block Editor: Load theme resolver class in script loader.

script-loader.php is sometimes called directly and in these situations, the Theme_JSON_Resolver class was not defined.

Props nosolosw, noisysocks.
Fixes #53175.

Commited in ​https://github.com/WordPress/wordpress-develop/commit/d66ccc00611baf7e9609e02e36469c4dd1bb10ef

[desrosj]

In 51007:

Coding Standards: Apply some minor coding standards adjustments.

Follow up to [50977], [50987], and [50995].

See #41683, #53156, #53175.

[SergeyBiryukov]

In 51013:

Block Editor: Only load the WP_Theme_JSON_Resolver class once.

Since the class is now loaded via wp-includes/script-loader.php, which is required earlier in wp-settings.php, loading it again in wp-settings.php is redundant.

Follow-up to [50992], [51001].

See #53175.

[SergeyBiryukov]

Replying to noisysocks:

[50992] breaks style concatenation. You can see this by navigating to /wp-admin/load-styles.php?load=wp-components. This should show the CSS for @wordpress/components but instead results in an empty page with status 500.

[51001] seems to work on PHP 7.4, but I still get a fatal error on PHP 8.0. While the get_stylesheet_directory() function is now available, it also calls get_theme_root(), which uses the WP_CONTENT_DIR constant, not defined at that point.

In PHP 7.4 it just silently works, causing a PHP warning hidden by error_reporting( 0 ) early in load-styles.php:

Warning: Use of undefined constant WP_CONTENT_DIR - assumed 'WP_CONTENT_DIR' (this will throw an Error in a future version of PHP)

In PHP 8.0 it is now a fatal error:

Fatal error: Uncaught Error: Undefined constant "WP_CONTENT_DIR"

See ​Backward Incompatible Changes in PHP 8.0:

Attempting to access unqualified constants which are undefined. Previously, unqualified constant accesses resulted in a warning and were interpreted as strings.

[TimothyBlynJacobs]

I'm not sure loading these files manually is the right fix. The site won't be properly loaded during script-loader.php, even if include those theme API functions. So the output would be incorrect. I think we should try the class_exists check @noisysocks suggested.

[jorgefilipecosta]

In 51031:

Block Editor: Fix logic to enable custom colors, gradients, and font sizes.

The logic to enable or disabled colors, gradients, and font sizes missed a negative operator, so when things should be enabled they weren't and they should be disabled they were enabled. This commit fixes the logic.

Props ntsekouras.
See #53175.

[SergeyBiryukov]

#53304 was marked as a duplicate.

Fixes https://core.trac.wordpress.org/ticket/53175#comment:34
Alternative to ​https://github.com/WordPress/wordpress-develop/pull/1324

Steps to reproduce:

• Use a WordPress environment with PHP 8.
• Activate the debug logs.
• Set error_reporting( -1 ); at the head of load-styles.php.
• Visit /wp-admin/load-styles.php?load=wp-components

The expected result is that the styles load and that there's no message in the log.

Previous to this change, the styles won't load and you'll see this error in the log Fatal error: Uncaught Error: Undefined constant "WP_CONTENT_DIR".

[oandregal]

I've prepared a fix for https://core.trac.wordpress.org/ticket/53175#comment:34 at ​https://github.com/WordPress/wordpress-develop/pull/1324

I've also prepared an alternative PR at ​https://github.com/WordPress/wordpress-develop/pull/1325 that moves the dependencies to the specific files that need them (wp-settings, load-styles) instead of loading them via script-loader.

Part of https://core.trac.wordpress.org/ticket/53175

Global settings are filterable by hooking into the block_editor_settings filter. Global styles in the front end are filterable as well by getting the global-styles style handle (​see). However, there's no mechanism to filter the global styles that come with the editor.

This PR allows third-party to identify the styles that are going to be sent to the editor, so they can filter them.

## How to test

• Using WordPress 5.8, activate a theme with theme.json support.
  • Alternatively, using the TwentyTwentyOne theme, create a file named theme.json in the top-level folder of the theme and paste the following contents {"version": 1}.
• Load the post editor. Open the devtools and in the inspector search for --wp--preset--color.
• The expected result is that there are two occurrences: the wp-edit-post-js-after script and within a <style> tag in the body of the document, just before the editor-styles-wrapper node.

Now, install and activate the Gutenberg plugin from the plugin repository and do the same. What happens is that there will be three occurrences, the wp-edit-post-js-after embedded script and two identical <style> tags.

## Changes introduced

It adds a __experimentalGlobalStyles key to the styles so they can be inspected by others.

## Alternatives I've considered

I haven't seen many options to do something like this. A similar approach could be to add some sort of metadata in the first lines of the stylesheet instead. While feasible it seems more error-prone than this.

[SergeyBiryukov]

Replying to nosolosw:

I've also prepared an alternative PR at ​https://github.com/WordPress/wordpress-develop/pull/1325 that moves the dependencies to the specific files that need them (wp-settings, load-styles) instead of loading them via script-loader.

Thanks! That seems like a much better option to me than keeping adding things to wp-includes/script-loader.php that don't quite belong there :)

[SergeyBiryukov]

In 51056:

Block Editor: Load the WP_Theme_JSON_Resolver class in wp-admin/load-styles.php.

This ensures correct load order when style concatenation is used, e.g. when SCRIPT_DEBUG is off.

Additionally, make sure the WP_CONTENT_DIR constant is defined for use in get_theme_root() via get_stylesheet_directory().

Follow-up to [50992], [51001], [51013].

Props nosolosw.
See #53175.

Thanks for the PR! Closing in favor of #1325, which seems like a better option :)

Thanks for the PR! Merged in https://core.trac.wordpress.org/changeset/51056.

Pushed a change to make this general and use a __unstableType that is added to styles that come from core (__unstableType = core), the theme (__unstableType = theme), or global styles (__unstableType = globalStyles).

[youknowriad]

In 51090:

Block Editor: Add a type property to allow Core to identify the source of the editor styles.

Gutenberg plugin need to override the editor styles provided by core selectively,
this added property allows it to do so without committing to a public API.

Props nosolosw, jorgefilipecosta.
See #53175.

Committed

[hellofromTonya]

As 5.8 Beta 1 is today and it looks like all work is done on this ticket, closing it. If more work or followup is needed, please reopen.

[youknowriad]

In https://core.trac.wordpress.org/changeset/51240 we backported the removal of the default font family from themes with theme.json file. (the ticket reference was missing from the commit)

Part of https://core.trac.wordpress.org/ticket/53175

In one of the ports to WordPress core from the plugin we inadvertently landed support for experimental-link-color, which has been plugin only so far and should remain so. See ​https://github.com/WordPress/gutenberg/pull/33162#discussion_r662851026 for context.

[oandregal]

Prepared ​https://github.com/WordPress/wordpress-develop/pull/1458 to remove support for experimental link color via the old legacy support, which is something that has been plugin-only and should stay that way.

[desrosj]

Reopening to consider the latest PR.

[desrosj]

In 51306:

Editor: Remove the experimental experimental-link-color feature.

This has been plugin only so far and should remain so.

Follow up to [50959].

Props nosolosw.
Fixes #53175.

[desrosj]

Reopening to backport [51306].

Thanks! Merged into Core in https://core.trac.wordpress.org/changeset/51306.

Part of https://core.trac.wordpress.org/ticket/53175

This ports this PR ​https://github.com/WordPress/gutenberg/pull/33280 The JS changes in that PR will be ported in the next package release and both are independent (they fix two related but separate things).

### How to test

• Add these contents to a file named theme.json in the TwentyTwentyOne theme (or add the same contents to any theme with theme.json support):

{
  "settings": {
    "color": {
      "duotone": []
    },
    "spacing": {
      "units": []
    }
  }
}

• Open the poste editor and add an image block. Open the duotone control from the block toolbar. The expected result is that it doesn't show any duotone colors. Before this change, it'll still show all colors.

• Add a cover block. Go to the inspector and verify that the cover height control and the padding control only show px units. Before this change, it'll show all units.

[oandregal]

It was reported that the color.duotone and the spacing.units couldn't be set to empty. This is fixed by this PR in Gutenberg ​https://github.com/WordPress/gutenberg/pull/33280

I've prepared ​https://github.com/WordPress/wordpress-develop/pull/1489 to port the PHP changes to WordPress.

The JS changes in the Gutenberg PR still need to be ported in the next package release and both are independent (they fix two related but separate things).

cc @desrosj @youknowriad @jorgefilipecosta in case you can help land this and port it to the WordPress 5.8 branch.

[jorgefilipecosta]

In 51383:

Block Editor: Fix for theme.json: color.duotone and spacing.units should allow empty sets.

This commit fixes an issue with the color.duotone & spacing.units in which empty values didn't override previous origins, resulting in that a theme couldn't provide an empty set for this via its theme.json.

Props nosolosw, youknowriad, aristath.
See #53175.

Committed on ​https://github.com/WordPress/wordpress-develop/commit/6bd5962c7d234b3dd59cb271877d9db36c4f27eb this PR can be closed :)

[desrosj]

Marking [51383] for backport after a second committer has dev-reviewed.

[desrosj]

[51383] looks good for backport.

[desrosj]

In 51386:

Block Editor: Fix for theme.json: color.duotone and spacing.units should allow empty sets.

This commit fixes an issue with the color.duotone & spacing.units in which empty values didn't override previous origins, resulting in that a theme couldn't provide an empty set for this via its theme.json.

Props nosolosw, youknowriad, aristath, jorgefilipecosta.
Merges [51383] to the 5.8 branch.
Fixes #53175.

Ticket: https://core.trac.wordpress.org/ticket/53175

Props to @dd32

Global styles are used in a few different contexts (front, editor, customizer, the theme directory). In the last two contexts, it's important that switching themes immediately refreshes the global stylesheet, to avoid situations in which the styles of the previous theme load with the new one. This was brought up at ​https://github.com/WordPress/gutenberg/issues/34531 (customizer) and at ​https://meta.trac.wordpress.org/ticket/5818 (theme directory).

This PR makes sure the stylesheet is regenerated upon switching themes.

I don't think I have the permissions to commit this myself to the SVN. Can someone help with that?

Note that I'd like to give props to dd32 (it's in the issue description).

I added committing this PR to core to my todo list will do it soon.

[jorgefilipecosta]

In 51819:

Block editor: Cache global stylesheet by theme key.

Global styles are used in a few different contexts (front, editor, customizer, the theme directory). In the last two contexts, it's important that switching themes immediately refreshes the global stylesheet, to avoid situations in which the styles of the previous theme load with the new one. This was brought up at WordPress/gutenberg#34531 (customizer) and at meta.trac.wordpress.org/ticket/5818 (theme directory).
This commit makes sure the stylesheet is regenerated upon switching themes.

Props oandregal, dd32.
See #53175.

Committed here ​https://github.com/WordPress/wordpress-develop/commit/57ad9f16dff35a879e856566489266472589ea04.