Disable settings.shadow.defaultPresets for classic themes

[ajlende]

All discussion for this issue should be done in WordPress/gutenberg#59989

Alternative to #6295

Default shadow presets are never shown for classic themes, and classic themes have no options for adding custom ones.

Essentially, this is the existing behavior for classic themes in 6.4.

This allows us to defer decisions on whether or not to make them opt-in or opt-out for classic themes until 6.6.

Trac ticket: https://core.trac.wordpress.org/ticket/60815

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props ajlende, oandregal, madhudollu, swissspidy, get_dave.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[madhusudhand]

It completely blocks the shadow tools from the UI in classic themes (same as 6.4).

With respect to the newly introduced feature in block editor, tested a case where shadow applied in a block theme (in the post content) and then switched to classic theme.
It preserves the shadow in the post because the template has inline styles for shadow and core-preset css variables are still created.

LGTM!

[oandregal]

Left a longer comment in the issue WordPress/gutenberg#59989 (comment)

[getdave]

It might be helpful to assert specifically that the natural present has not been overriden by the Theme version from block-theme's theme.json.

The original bug related to the theme presets with the same slug overriding the core presets so it might be good to specifically assert to focus the test on this aspect.

[getdave]

Maybe also include a reference to the location of the related core preset?

wordpress-develop/src/wp-includes/theme.json

Lines 196 to 200 in f25ca58

	{
	"name": "Natural",
	"slug": "natural",
	"shadow": "6px 6px 9px rgba(0, 0, 0, 0.2)"
	},

[oandregal]

This value would never be overridden. What would happen instead is that theme array would have the natural preset. You may want to check by setting shadow.defaultPresets:false in core's theme.json and then execute npm run test:php -- --filter test_theme_shadow_presets_do_not_override_default_shadow_presets.

Note that I've also added a theme preset that is actually added (test) to make sure this is also working.

[oandregal]

Essentially, presets work this way:

1. Once the different theme.json sources (default, theme, user) are merged, all the values are available under the source key. For example:

array(
  'default' => array( /* come from core's theme.json */
    array( 'slug' => 'natural', /* ...*/ ),
    array( 'slug' => 'deep', /* ...*/ ),
  ),
  'theme'  => array( /* come from the theme's theme.json */
    array( 'slug' => 'natural', /* ...*/ ),
    array( 'slug' => 'test', /* ...*/ ),
  )
)

2. However, in certain situations, we don't want the theme presets to "override" default presets, so we remove any whose slug is the same as one of the default presets. This is what happens for shadows, resulting in the following:

array(
  'default' => array( /* come from core's theme.json */
    array( 'slug' => 'natural', /* ...*/ ),
    array( 'slug' => 'deep', /* ...*/ ),
  ),
  'theme'  => array( /* come from theme's theme.json, after removing those whose slug is the same as any of the default presets */
    array( 'slug' => 'test', /* ...*/ ),
),
)

This is the base behavior for all presets. From there, this data is used differently by the components:

• UI: some design tools may want list the presets from source (this is what colors do) but others display them all together (font families).
• CSS: in general, every preset item available in the default and theme array will be converted to --wp--preset--category--slug (e.g.: --wp--preset--shadow-natural). This was the issue Alex raised and that is fixed by this PR.

[getdave]

Thank you for the additional clarification. I was understanding correctly, but perhaps not communicating that understanding very well.

When I say "overridden" I mean that the bug was that the Theme preset would take precedence over the Core preset.

Now with this PR the Core preset takes precedence over the Theme preset.

The condition is that they must have a matching slug. This is why you've added a "Test" preset that only exists in the Theme to verify that this functionality still works.

[swissspidy]

Committed in https://core.trac.wordpress.org/changeset/57885