-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Try: make logic for conditional editor_styles consistent #45351
Conversation
Open in CodeSandbox Web Editor | VS Code | VS Code Insiders |
I'm not sure if something changed in TT3 or in Gutenberg, but this isn't working for me, sorry :( |
# Conflicts: # lib/client-assets.php
This reverts commit 89c3d7d.
Thanks for testing this out. I checked this just after you left this comment, and I was seeing the same as you where the fix here didn't have any effect. I tried debugging different things but I didn't get anywhere, so I left it. Now however it does seem to be working again. I'm not sure what's different! But there were several hundred commits between this and trunk, so I've rebased 😅 I think I'm understanding the problem more now, as this seems very specific to TT3. TT3 doesn't have a functions.php, which means it doesn't provide any editor styles. I believe this means this logic,
Nevermind, I don't think this is working either. It's certainly related to the missing |
This reverts commit b3b368b.
I've narrowed this down to the logic for including the theme.css stylesheet not being consistent, namely in script-loader.php. I've updated the logic in this PR to what I think is correct. Also, I can confirm how to replicate this now. The theme should not support However, the only way I could successfully test this was to update the script-loader.php file in Core. I'd appreciate if anyone could confirm that this should be an update to Core rather than in Gutenberg. I think this update is important to allow themes to not include a functions.php file if it's not necessary (like in Twenty Twenty-Three). |
Flaky tests detected in 823dfcc. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4221169591
|
I am not sure what may have changed but I don't see the incorrect editor styles being loaded if I activate Gutenberg trunk. ? |
Thanks for taking a look, @carolinan. I'm still seeing the incorrect width on the separator block on trunk in the editor:
I have to apply the changes in this PR directly to Core (my local version of wordpress-develop) to make this work, rather than just Gutenberg. I'm guessing that's because I'm not sure how the compat files work! |
Hm.. I was adding a new separator in the block editor, there it looks fine. |
We need someone to do a zoom call with us and explain it :) |
if ( | ||
current_theme_supports( 'wp-block-styles' ) && | ||
( ! is_array( $editor_styles ) || count( $editor_styles ) === 0 ) | ||
) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be updated in Core in wp-includes/script-loader.php.
@@ -178,7 +178,7 @@ static function( $classes ) { | |||
wp_enqueue_media(); | |||
|
|||
if ( | |||
current_theme_supports( 'wp-block-styles' ) || | |||
current_theme_supports( 'wp-block-styles' ) && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be updated in Core in wp-admin/site-editor.php.
As a sanity check, this PR is working for me in the front-end, post editor, and template part editor! Unless you want to write some compatibility code to overwrite what assets are enqueued in the site editor, I do think the easiest fix is to patch this in core as you highlighted. My impression is that the compat files all work a little differently depending on the context, and the context is always changing... I would definitely join a call with an overview though of the major places where these compat files are necessary and how to approach making changes there. |
Thanks @jffng! For completeness (and hopefully to make things easier), I've opened a core patch as well: WordPress/wordpress-develop#3916 |
I do not know if this needs to be merged both into Gutenberg and core? If so it needs to be refreshed and moved to the 6.2 folder. I know that if we want it to be in 6.2 we need to add the backport label.. |
Me neither! @ndiego, is this something you could help with? To summarise, this PR is changing files in the lib/compat files, but there is also a PR open for core to make the same changes there. |
cc @Mamaduka @ntsekouras are you able to provide guidance on this? I am a little unsure myself. Thanks! 🙏 |
@mikachan my understanding is that if this is to go into 6.2 you would need to:
Sing out if it does get through to the backporting stage. I am happy to help out if you are not familiar with the process. |
In this case, I think it's okay to modify Why?
|
Thanks, both!
Do you mean directly in Core, like in WordPress/wordpress-develop#3916? |
Sorry for the late reply, @mikachan! Re |
Thanks, @Mamaduka! So is it OK to merge this PR as it is, or do I need to follow the backporting steps outlined above by @glendaviesnz? |
Closing this, as @hellofromtonya kindly tested and merged the Core patch at WordPress/wordpress-develop#3916. Thanks for everyone's help with this one! 🙇♂️ |
What?
In #44640, we added a check for
wp-block-styles
theme support before including thewp-block-library-theme
CSS in the editor.This seemed to work well in most cases, however, there are still some cases where this CSS is included. As seen in this issue for TT3 WordPress/twentytwentythree#295, the opinionated width of 100px for the separator is still being loaded from the theme.css file in the editor, but this isn't used on the front end.
Why?
The editor styles should match the front end.
How?
This PR is an attempt to never allow the
wp-block-library-theme
CSS to be loaded under the conditions we introduced in #44640.I've made the logic consistent between /template-parts-screen.php and /script-loader.php, so the condition to include the theme.css file is only if the active theme supports
wp-block-styles
AND there are noeditor_styles
set.Testing Instructions
wp-block-styles
AND doesn't includeadd_editor_style( 'style.css' );
Example separator markup for copy/pasting: