Unable to live preview changes to Additional CSS in the Customizer when using a Block Theme

[westonruter]

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 the STYLE#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.

This issue was introduced in ​Gutenberg#58991 and core commits [55192] and [58703].

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

This is a backport of ​https://github.com/WordPress/gutenberg/pull/70428

[zunaid321]

This ticket was brought up in a recent bug scrub.

Here’s the feedback received:

1.⁠ ⁠It was requested that the fix should go live as quickly as possible.
2.⁠ ⁠⁠As Customizer CSS is widely used, BlockThemes are becoming increasingly popular for some folks.

Props to: @rafiq91

[rollybueno]

Reproduction Report

Description

This report confirms whether the issue outlined here, where live previews of Additional CSS fail to render in the Customizer when using a block theme, can be consistently reproduced under a specific environment.

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 137.0.0.0
• OS: Linux
• Theme: Twenty Twenty-Five 1.2 (Block Theme)
• MU Plugins: None
• Plugins:
  • Query Monitor 3.18.0
  • Test Reports 1.2.0

Steps to Reproduce

1. Activate a block-based theme (e.g. Twenty Twenty-Five).
2. Enable the Customizer manually if it's not available: Visit: /wp-admin/customize.php
3. In the Customizer, go to the Additional CSS section.
4. Add a CSS rule, such as: p { color: red; }
5. Observe the preview panel.

Actual Results

✅ Error condition occurs: The CSS rule is not reflected in the live preview.

The change only appears on the frontend after clicking Publish and page refresh.

Additional Notes

• The Customizer is not enabled by default in block themes, but can still be accessed directly or re-enabled programmatically for testing purposes.

Supplemental Artifacts

Customiser state after adding basic CSS p { color:red; }, before clicking on Publish

After clicking Publish - the button turns diabled but the text color still not updated.

After page refresh - only after doing this, the text color from Additional CSS applied.

[rollybueno]

Test Report

Description

This report validates whether the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/9000

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 137.0.0.0
• OS: Linux
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Query Monitor 3.18.0
  • Test Reports 1.2.0

Steps to Reproduce

1. Activate the Twenty Twenty-Five theme.
2. Navigate directly to the Customizer:/wp-admin/customize.php
3. Go to the Additional CSS section.
4. Add a CSS:p { color: red; }
5. Observe the preview panel.

Steps to Apply Patch

1. Fetch the patch:

   git fetch upstream pull/9000/head:pr-9000
   git checkout pr-9000
   

2. Build the environment:

   npm install
   npm run build
   

3. Repeat the reproduction steps above.

Actual Results

• ✅ Live preview of Additional CSS works correctly.
• ✅ Changes reflect immediately in the preview pane.
• ✅ Issue is no longer reproducible with the patch applied.

Additional Notes

• Issue was specific to block themes.
• Patch tested successfully with multiple block themes.
• No regressions observed in the Customizer.
• ℹ️ Check the video link below for a better view of the live preview behavior.

Supplemental Artifacts

Applying the CSS live without hitting the Publish to page refresh

👋👇📹 Video screencast – This is a better way to check and confirm that it works, as you can clearly see the CSS being applied in the preview without needing to publish.

​https://www.awesomescreenshot.com/video/41470898?key=c06faa5ddb791e636699a42f36f458a5

[rollybueno]

👀 Hey @westonruter - I saw your PR suggestion a bit late, but I’ve tested the current codebase and it’s working as expected. Just let me know if there are any updates so I can retest and confirm again.

[westonruter]

@rollybueno thanks for testing. The PR suggestion wouldn't have changed anything since it would related to a deprecated function that isn't used anymore. So your test results will remain relevant even with the suggestion applied.

[wildworks]

If applying this patch, I believe custom CSS added via the global styles will no longer be applied to the Customizer preview.

Steps to Reproduce

• Activate Twenty Twenty-Five theme
• Go to Appearance > Editor > Click the canvas > Click the "Styles" button > Click the "More" elipsis button > Click the "Additional CSS" menu item
• Add the following CSS: body { color: red; }
• Click the save button
• Check the front end. The text color is red
• Open the Customizer: ​http://localhost:8889/wp-admin/customize.php
• The text color is black

I feel like maybe special handling is needed only for block themes and customizer previews.

[SirLouen]

Reproduction and Test Report

Description

❌ This report can't validate that the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/9000.diff

Environment

• WordPress: 6.9-alpha-60273
• PHP: 8.0.30-dev
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 5.5 / Client: 3.40.1)
• Browser: Chrome 138.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Testing Instructions

1. Used the reproduction instructions provided by @wildworks
2. ❌ Styles from Gutenberg CSS editor are not being applied
3. Tested without the patch
4. ❌ Regression: conflict between styles introduced in Gutenberg editor and customizer

Actual Results

1. ❌ A new issue is introduced with this patch

Additional Notes

Replying to westonruter:

The PR suggestion wouldn't have changed anything since it would related to a deprecated function that isn't used anymore. So your test results will remain relevant even with the suggestion applied.

It doesn't seem to be used at all by anyone ​except for being explicitly removed.

[audrasjb]

As per today's bug scrub: this ticket is moved to milestone 6.9 as 6.8.2 RC1 is tomorrow and it still needs more work.

[wildworks]

As I understand it, the current issue is that in block themes, all custom CSS is integrated into the inline global styles:

<style id='global-styles-inline-css'>
/* CSS variables */
:root {
  --wp--preset--aspect-ratio--square: 1;
  // ...
}
/* Layout and site styles */
:where(body) {
        // ...
}
/* Customizer Custom CSS here */
body {
  color: blue
};
/* Global Styles Custom CSS here */
body {
  color: red;
}
/* Global Styles Block Custom CSS here*/
:root :where(p) {
  color: yellow;
}
</style>

There is probably a reason for this, but I expect that in order to be able to dynamically change only the Customizer custom CSS (wp-custom-css) in the Customizer preview, it will be necessary to split the styles while maintaining the order of this CSS. For example, something like this:

<style id='global-styles-inline-css'>
/* CSS variables */
:root {
  --wp--preset--aspect-ratio--square: 1;
  // ...
}
/* Layout and site styles */
:where(body) {
        // ...
}
</style>

<style id='wp-custom-css'>
/* Customizer Custom CSS here */
body {
  color: blue
};
</style>

<style id='global-styles-custom-css'>
/* Global Styles Custom CSS here */
body {
  color: red;
}
/* Global Styles Block Custom CSS here*/
:root :where(p) {
  color: yellow;
}
</style>

@isabel_brison, @aaronrobertshaw, and @andrewserong may know a better approach.

[westonruter]

@wildworks Thanks for catching this. I was able to reproduce the issue.

I've updated the PR with a fix, to ensure the global styles are always printed even in the Customizer, and to print Customizer's Custom CSS separately before the global styles so that the can be updated with live preview and so that the cascade is preserved, where Custom CSS in global styles are intended to override Customizer's Custom CSS.

Note: Originally the Customizer's Custom CSS was intended to override all other styles, so it was printed at wp_head with a priority of 101, which is far after wp_print_styles() runs at priority 8. This allowed the Customizer's Custom CSS to easily override CSS from themes and plugins, without having to resort to increased selector specificity or !important properties. However, in block themes the Custom CSS in global styles is now intended to take precedence (apparently), so this is why the order is changed in a block theme.

I've also updated the Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/70428

[wildworks]

@westonruter Thanks for the update.

It may be difficult to solve everything, but I discovered another inconsistency while testing the latest patch.

Steps to Reproduce

• Activate Twenty Twenty-Five theme
• Go to Appearance > Editor > Click the canvas > Click the "Styles" button > Click the "Colors" button > Click the "Text" button in the Elements section
• Change the color to #ff0000
• Click the save button
• Open the Customizer: ​http://localhost:8889/wp-admin/customize.php
• Click the "Additional CSS" button
• Add the following CSS: body{color:green;}

Frontend

The text color is green.

<style id='global-styles-inline-css'>
body {
    color: #ff0000; // Defined in the Global Styles UI
}
body {
    color: green; // Defined in the Customizer additional CSS
}
</style>

Customizer

The text color is red.

<style id="wp-custom-css">
body{
        color:green; // Defined in the Customizer additional CSS
}
</style>

<style id='global-styles-inline-css'>
body {
    color: #ff0000; // Defined in the Global Styles UI
}
</style>

Another thing I noticed is that the post editor or site editor doesn't seem to enqueue the additional CSS defined in the Customizer in the first place.

This means that if you follow the testing steps above, the text color should be a different red from the green on the frontend.

This appears to be happening in at least 6.7 as well.