-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Fix ability to preview Additional CSS changes in the Customizer when using a Block Theme #70428
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
Conversation
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
617ca2d
to
259b5fc
Compare
…ix/custom-css-customize-preview
…ix/custom-css-customize-preview
Flaky tests detected in 37846e0. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/16613818055
|
…tomizer styles in cascade
…ix/custom-css-customize-preview
I've marked this as a draft now because the core PR now has a better approach, as described in https://core.trac.wordpress.org/ticket/63589#comment:23 |
Co-authored-by: Peter Wilson <peterwilsoncc@git.wordpress.org>
lib/script-loader.php
Outdated
* | ||
* Note: The logic in this function would be back-ported into customize-preview.js. | ||
*/ | ||
function gutenberg_add_customizer_block_theme_custom_css_preview_js() { |
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.
If WordPress/wordpress-develop#9000 will be shipped with WP 6.9, can we move this code into the lib/compat/wordpress-6.9
directory? Once the minimum supported version of WordPress for Gutenberg increases to 6.9, this code will no longer be necessary and can be removed.
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.
Good idea.
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.
How about 37846e0?
lib/script-loader.php
Outdated
sprintf( '( %s )( %s )', $js_function, wp_json_encode( $setting_id ) ) | ||
); | ||
} | ||
add_action( 'wp_enqueue_scripts', 'gutenberg_add_customizer_block_theme_custom_css_preview_js' ); |
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.
I haven't tested it to see if it works, but can we use the customize_preview_init
hook to avoid unnecessary function execution on the frontend? This hook seems to be widely used in default themes to enqueue scripts as well.
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.
So like this?
add_action( 'customize_preview_init', static function () {
add_action( 'wp_enqueue_scripts', 'gutenberg_add_customizer_block_theme_custom_css_preview_js' );
} );
This would then eliminate the need for the is_customize_preview()
check in the function.
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.
Actually, there's not really any need to use wp_enqueue_scripts
here. We're just adding an inline script to a script that already registered. So this can be:
add_action( 'wp_enqueue_scripts', 'gutenberg_add_customizer_block_theme_custom_css_preview_js' ); | |
add_action( 'customize_preview_init', 'gutenberg_add_customizer_block_theme_custom_css_preview_js' ); |
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.
See d9f7988
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
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 PR works correctly on both WordPress 6.7, which the Gutenberg plugin supports, and the latest core trunk.
|
||
if ( version_compare( get_bloginfo( 'version' ), '6.9.0', '<' ) ) { | ||
add_action( 'customize_preview_init', 'gutenberg_add_customizer_block_theme_custom_css_preview_js' ); | ||
} |
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 conditional statement will return true if WordPress is in Alpha or Beta, or RC, so the action hook will run even if the JS logic has already been merged into core.
Finally, I would suggest one of the following changes:
- Remove the conditional statement because there is a skip process here.
- Use
is_wp_version_compatible()
, which allows us to compare with he pure version number:
if ( is_wp_version_compatible( '6.9' ) ) {
add_action( 'customize_preview_init', 'gutenberg_add_customizer_block_theme_custom_css_preview_js' );
}
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.
@t-hamano I included both on purpose actually… I wanted to avoid adding that additional JS when in 6.9 stable. But for 6.9-alpha, I thought it was fine to include it for the sake of devs on different nightly versions.
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.
I see, if that's your intention, I think the code is fine as is 👍
…using a Block Theme (#70428) * Fix ability to preview Custom CSS changes in the Customizer * Add backport changelog WordPress/wordpress-develop#9000 WordPress/gutenberg#70428 * Undo unnecessary update to deprecated function * Ensure global styles are shown in Customizer preview and override Customizer styles in cascade * Add Customizer details to the comment * Update Customizer Custom CSS inside of global styles for live preview * Make sure saved milestone comments are removed from stored CSS when previewing * Add line breaks before/after Custom CSS for readability/debugging Co-authored-by: Peter Wilson <peterwilsoncc@git.wordpress.org> * Remove erroneous duplicated appending of global styles custom CSS * Simplify adding inline script to customize-preview Co-authored-by: t-hamano <wildworks@git.wordpress.org> * Improve JS formatting * Add commit reference * Move custom CSS preview logic to 6.9 compat include Co-authored-by: t-hamano <wildworks@git.wordpress.org> --------- Co-authored-by: westonruter <westonruter@git.wordpress.org> Co-authored-by: t-hamano <wildworks@git.wordpress.org> Co-authored-by: Peter Wilson <peterwilsoncc@git.wordpress.org> Source: WordPress/gutenberg@9b3d784
…using a Block Theme (WordPress#70428) * Fix ability to preview Custom CSS changes in the Customizer * Add backport changelog WordPress/wordpress-develop#9000 WordPress#70428 * Undo unnecessary update to deprecated function * Ensure global styles are shown in Customizer preview and override Customizer styles in cascade * Add Customizer details to the comment * Update Customizer Custom CSS inside of global styles for live preview * Make sure saved milestone comments are removed from stored CSS when previewing * Add line breaks before/after Custom CSS for readability/debugging Co-authored-by: Peter Wilson <peterwilsoncc@git.wordpress.org> * Remove erroneous duplicated appending of global styles custom CSS * Simplify adding inline script to customize-preview Co-authored-by: t-hamano <wildworks@git.wordpress.org> * Improve JS formatting * Add commit reference * Move custom CSS preview logic to 6.9 compat include Co-authored-by: t-hamano <wildworks@git.wordpress.org> --------- Co-authored-by: westonruter <westonruter@git.wordpress.org> Co-authored-by: t-hamano <wildworks@git.wordpress.org> Co-authored-by: Peter Wilson <peterwilsoncc@git.wordpress.org>
The implementation here is described in https://core.trac.wordpress.org/ticket/63589#comment:23
The new approach is now part of WordPress/wordpress-develop#9000
Obsolete Approach
Adding the Additional CSS from the Customizer to the global styles makes sense, except not in the Customizer preview. This is because
wp-includes/js/customize-preview.js
is supposed to dynamically update theSTYLE#wp-custom-css
element with the new stylesheet whenever it changes. So this PR prevents putting the Additional CSS into the global styles when in the Customizer preview context.In the Customizer preview, this PR prevents injecting the Customizer's CSS into the
global-styles
in between the global stylesheet and the Custom CSS. Instead, it prints the Customizer's Custom CSS before printing other styles. This ensures that the CSS cascade is preserved for global styles. However, normally the Customizer's CSS is printed atwp_head
priority 101, long after thewp_print_styles()
runs at priority 8. This was to ensure that the Customizer's Custom CSS would be able to override any and all styles added by the theme or plugins; however, in a block theme the Customizer's Custom CSS is already being deprioritized.See the diff for how
* { color: blue; }
in the Customizer and* { color: red; }
in global styles Custom CSS appear in the Customizer preview and outside in the normal view:This issue was introduced in #58991
Screencast
Before
Screen.Recording.2025-06-14.at.13.28.10.mov
After
Screen.Recording.2025-06-14.at.13.31.21.mov