Only include theme.css if the theme declares support for wp-block-styles

[carolinan]

What?

Adds an additional condition to the check that loads the wp-block-library-theme as a dependency of the editor styles.
The dependency should only be added if the theme includes the wp-block-styles theme support.

(This file is already loading correctly on the front, this is only related to the editor styles)

Closes #44510

Why?

The theme.css was loaded in the editor even though themes did not declare support for it, which lead to the editor and front not matching.

How?

Adds an additional condition to the check that loads the wp-block-library-theme as a dependency of the editor styles.

Testing Instructions

1. Activate Twenty Twenty-Three.
2. In the block editor, add a quote block. Confirm that the quote block does not have a border.
3. Create a functions.php in the theme's root directory, that includes the theme support:

<?php
add_theme_support( 'wp-block-styles' );
?>

4. Next please reload the editor where you added the quote block, and confirm that the block has a left border.

Screenshots or screencast

[mikachan]

This PR works well for me for the issues we're seeing in TT3 👍

I'm hesitant to approve as I'm wondering if this check wasn't included for a specific reason. Looking at #29252, this is the logic that was used:

• For themes that opt into wp-block-styles, we always load the opinionated block styles (Independent Publisher 2)
• For themes that don't opt into wp-block-styles and don't provide editor styles, we always load the opinionated block styles (Kaura) - TT3 fits into this
• For themes that don't opt into wp-block-styles and provide editor styles we don't load the opinionated block styles (Libre 2)

It looks like the second point was to cover any cases where a theme doesn't provide any editor styles. Do we still need to handle this in some way? I agree that we shouldn't include the opinionated styles if the theme doesn't opt-in, but I'm wondering if there are some styles bundled here that should be split out, and included in the editor when there are no provided editor styles.

[scruffian]

I think this was an oversight on my part. Thanks for fixing. LGTM

[ndiego]

It looks like the second point was to cover any cases where a theme doesn't provide any editor styles. Do we still need to handle this in some way? I agree that we shouldn't include the opinionated styles if the theme doesn't opt-in, but I'm wondering if there are some styles bundled here that should be split out, and included in the editor when there are no provided editor styles.

@scruffian do you have any concerns regarding @mikachan's comments above? If you're comfortable with this PR, let's get it merged asap so we can backport ahead of RC1. Thanks!

[ockham]

It looks like the second point was to cover any cases where a theme doesn't provide any editor styles. Do we still need to handle this in some way? I agree that we shouldn't include the opinionated styles if the theme doesn't opt-in, but I'm wondering if there are some styles bundled here that should be split out, and included in the editor when there are no provided editor styles.

@scruffian do you have any concerns regarding @mikachan's comments above? If you're comfortable with this PR, let's get it merged asap so we can backport ahead of RC1. Thanks!

FWIW, I think that @scruffian's approval comment (#44640 (review)) refers to this:

I think this was an oversight on my part. Thanks for fixing. LGTM.

Based on this, I think I'll go ahead and merge this PR. (Note that in order to be included in Core, we'll need a separate PR against wordpress-develop anyway, since this is a change to non-block PHP code.)

[ockham]

I just cherry-picked this PR to the wp/6.1 branch to get it included in the next release: 55d9f55