Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix regression with theme.json settings.shadow.defaultPresets #6295

Conversation

ajlende
Copy link

@ajlende ajlende commented Mar 20, 2024

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

Description

  • Reverts core theme.json settings.shadow.defaultPresets to true to fix the regression. (Back to working the same as color/gradient preset configuration for block themes.)
  • Adds editor-shadow-presets and default-shadow-presets for classic themes to configure shadows. (Works the same way as color/gradient preset configuration in classic themes.)

Backport to Gutenberg: WordPress/gutenberg#60000
Gutenberg issue: WordPress/gutenberg#59989
Trac ticket: https://core.trac.wordpress.org/ticket/60815

Testing

Here is an example theme.json for testing that would override the default natural shadow with a red shadow to make the difference obvious.

// theme.json
{
	"$schema": "https://schemas.wp.org/wp/6.4/theme.json",
	"version": 2,
	"settings": {
		"shadow": {
			"presets": [
				{
					"name": "Natural",
					"slug": "natural",
					"shadow": "6px 6px 9px #F00"
				}
			]
		},
		"layout": {
			"contentSize": "840px",
			"wideSize": "1100px"
		}
	},
	"styles": {
		"blocks": {
			"core/button": {
				"shadow": "var(--wp--preset--shadow--natural)"
			}
		}
	}
}
  1. Use the above theme.json as an example theme.
  2. Insert a button in a post.
  3. Preview the post in wp/6.4
  4. Preview the post in trunk
  5. Preview the post in this PR
  6. See that wp/6.4 and this PR match.

Regression screenshots

WP 6.4 Current 6.5 This PR
Screen Shot 2024-03-19 at 12 56 11 Screen Shot 2024-03-19 at 12 55 36 Screen Shot 2024-03-19 at 12 55 24

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.

Copy link

github-actions bot commented Mar 20, 2024

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, andrewserong, madhudollu, get_dave, swissspidy.

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

Copy link

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.

@ajlende ajlende changed the title opt-in to default shadow presets in classic themes Fix regression with theme.json settings.shadow.defaultPresets Mar 20, 2024
Comment on lines +322 to +325
if ( ! isset( $theme_support_data['settings']['shadow']['presets'] ) ) {
// If the theme does not have any shadows, we still want to show the core ones.
$default_shadows = true;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a quick comment, as I haven't looked at this change in detail, but this line stood out to me while passing by. Does this check mean that if the theme doesn't add current_theme_supports( 'default-shadow-presets' ) it'll still wind up getting the default shadow presets?

Copy link
Author

@ajlende ajlende Mar 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's correct.

I think from all of the discussions that I read, the desire was to go for consistency with other settings, so I copied the behavior from colors and gradients just above. However, I know that behavior is different from what you had talked about in WordPress/gutenberg#58908.

If we want to match the appearance-tools behavior that you were going for there, this can be moved just a few lines lower into the appearance-tools section.

Copy link
Contributor

@andrewserong andrewserong Mar 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't feel too strongly about it, but mostly trying to follow the general discussion from WordPress/gutenberg#58908. My impression was that shadows / effects are a bit of a special case, so guarding behind appearance-tools is likely a better fit so that we're not outputting anything for themes that don't explicitly opt-in either to the presets or to appearance-tools, but @carolinan might have more insight for the Classic themes use case than me here 🙂

Copy link
Author

@ajlende ajlende Mar 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And fair warning, I haven't really tested any of this add_theme_support code yet. I wanted to get something pushed up as a starting point that folks could look at. But it's all copied from colors/gradients configuration, so I'm relatively confident that it should be working.

Copy link
Author

@ajlende ajlende Mar 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so that we're not outputting anything for themes that don't explicitly opt-in either to the presets

This is often a point of confusion for global styles, but setting default* options to false does not prevent the styles from being output. It just allows for themes to override the default values. What I've been told is that the default styles always need to exist in order to support patterns between themes. The only preset that handles this differently is duotone.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, gotcha.

The only preset that handles this differently is duotone.

I suppose that's the question then: whether shadows are like colors or font sizes, or whether they're more like duotone in that respect. It might be worth getting more opinions on this? I don't feel strongly either way, my main hope is that whichever way it works feels natural and not unexpected to folks. Maybe @madhusudhand might have some thoughts, too?

Copy link
Author

@ajlende ajlende Mar 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose that's the question then: whether shadows are like colors or font sizes, or whether they're more like duotone in that respect.

The only reason duotone is different is because of the large SVGs that were also being generated WordPress/gutenberg#38299. Changing it was not an easy feat—we had to essentially rewrite duotone from scratch to do all the things that the global styles classes give you for free. And there are still unresolved issues from making that change WordPress/gutenberg#53662 and WordPress/gutenberg#49293.

For something small like a few lines of shadow presets, I promise it isn't worth it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to know, thanks!

Comment on lines +4223 to +4247
register_theme_feature(
'editor-shadow-presets',
array(
'type' => 'array',
'description' => __( 'Custom shadow presets if defined by the theme.' ),
'show_in_rest' => array(
'schema' => array(
'items' => array(
'type' => 'object',
'properties' => array(
'name' => array(
'type' => 'string',
),
'shadow' => array(
'type' => 'string',
),
'slug' => array(
'type' => 'string',
),
),
),
),
),
)
);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bonus support for custom shadows in classic themes to match other presets.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great 🌟
I think it is best to split this change into separate PR (as it would be a new feature), in case if it gets landed in 6.5 or in a patch version.

Copy link
Author

@ajlende ajlende Mar 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was required in order to support these lines and match the behavior of colors/gradients.

https://github.com/WordPress/wordpress-develop/pull/6295/files#diff-d6b86476eed058e7cf8b6e57fa52c4fd75b1f0907e1a9ccb0149528a24f7578bR322-R325

if ( ! isset( $theme_support_data['settings']['shadow']['presets'] ) ) {
	// If the theme does not have any shadows, we still want to show the core ones.
	$default_shadows = true;
}

If we decide to diverge from the colors/gradients behavior like we're discussing in https://github.com/WordPress/wordpress-develop/pull/6295/files#r1533015533 and in WordPress/gutenberg#59989 (comment), we could remove it from here and add it to a follow-up.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened an alternative PR (#6303) with shadows enabled by default in classic themes (like colors/gradients) but without the option to opt-out with add_theme_support( 'editor-shadow-presets', array() ).

Both PRs fix the regression that I'm concerned with.

Copy link
Member

@madhusudhand madhusudhand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ajlende for bring this alternate approach for discussion.
It feels right to me and also exposes shadows to classic themes without creating any impact.

I gave it a test in both block and classic themes. It tests well with addition of small code. Also it uncovers a small guternberg UI issue where the label is set as Shadow instead of Border & Shadow, which I guess not because of the current changes. I am going to make a separate fix.

image

src/wp-includes/block-editor.php Outdated Show resolved Hide resolved
Comment on lines +4223 to +4247
register_theme_feature(
'editor-shadow-presets',
array(
'type' => 'array',
'description' => __( 'Custom shadow presets if defined by the theme.' ),
'show_in_rest' => array(
'schema' => array(
'items' => array(
'type' => 'object',
'properties' => array(
'name' => array(
'type' => 'string',
),
'shadow' => array(
'type' => 'string',
),
'slug' => array(
'type' => 'string',
),
),
),
),
),
)
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great 🌟
I think it is best to split this change into separate PR (as it would be a new feature), in case if it gets landed in 6.5 or in a patch version.

@getdave
Copy link
Contributor

getdave commented Mar 25, 2024

Flagging this to @swissspidy and @dream-encode as a PR that may needing a commit prior to WP 6.5 release.

@swissspidy
Copy link
Member

@getdave see the discussion on the trac ticket. To me there's too much back and forth on this issue and expected behavior seems unclear at this point. That's why I suggested 6.5.1 for this change. But let's discuss on the ticket please.

@swissspidy
Copy link
Member

Looks like we're converging towards focusing on #6309, so closing this one.

@swissspidy swissspidy closed this Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants