Global Styles: Lift restrictions on global styles for classic themes

[youknowriad]

In WordPress 7.0, we're introducing a font library page and we want to allow access to this page for classic themes too.

The Font Library behavior relies on the global styles to save active fonts and generating the styles in the frontend.

This means that we need to lift the restrictions we have right now in place when it comes to global styles and classic themes.

Opening the UI or not is going to be a separate discussion though. This is more about the infrastructure.

This trac ticket is going to be the "backport" ticket for the following Gutenberg PR ​https://github.com/WordPress/gutenberg/pull/73971

Backports changes from ​https://github.com/WordPress/gutenberg/pull/73971 to lift Global Styles restrictions in classic themes. For more details check the upstream PR.

[wildworks]

Note that if we can move this ticket forward, #64402 will automatically be resolved as well.

[youknowriad]

In 61473:

Global Styles: Lift classic block restrictions.

Enable Global Styles functionality in classic WordPress themes, allowing features like the Font Library to work without requiring a theme.json file.

This change:

• Removes restrictions that prevented classic themes from accessing Global Styles features.
• Enables font functionality in classic themes through the Font Library.
• Fixes Fonts menu not appearing in classic themes by changing its submenu index to avoid collision with Widgets.

Props youknowriad, isabel_brison, ramonopoly.
Fixes #64408.

[westonruter]

In testing with Twenty Twenty-One, this change broke live preview in the Customizer. This was recently fixed in #63589.

I'm also concerned about how this change moves the Customizer's Additional CSS into the global styles, as opposed to being printed separately as a style#wp-custom-css at the end of the HEAD. This introduces a change to the CSS cascade, which will likely cause unexpected styling issues. We were bit by this in 6.9 with ​loading block styles on demand in classic themes (#64099, #64150). The change intended to make block styles load for classic themes in the same way they load for block themes, but the reality is that classic themes have been built in a way that a different CSS cascade is expected. This caused regressions: #64354. The workaround for sites in 6.9 is simply to opt-out of loading separate block styles, e.g. via the ​Load Combined Core Block Assets plugin. The ​pending PR for 6.9.1 will hopefully eliminate the need for this by preserving the original CSS cascade in classic themes.

However, no such workaround plugin would help sites that break due to a difference in the cascade for Additional CSS.

[westonruter]

To see the regression in the CSS cascade, activate the the TT1 theme and add this to the Additional CSS in the Customizer: body {background-color:lime;}.

In [61472]:

1. The lime color applies instantly in the preview.
2. Saving and viewing the frontend shows the lime color.

However, in [61473]:

1. The lime color does not apply instantly in the preview.
2. Saving and viewing the frontend shows the original color. No style change is visible.

[westonruter]

CSS cascade before r61473 with the background color applied as expected

[westonruter]

CSS cascade at r61473 with the background color NOT applied as expected

This commit breaks a couple things:

1. Live Preview in the Customizer
2. The CSS cascade.

See Trac comment and repro steps.

[youknowriad]

@westonruter Do you think the way the cascade works for the "additional CSS" in block themes should also work like classic themes?

My understanding from checking the result here is that the priority issue is that the classic theme's style.css file is considered to have more priority than the customizer's additional CSS, which causes the issue.

The reason for that is that the "additional CSS" in block themes is considered as part of the "theme styles" (so same level as style.css provided by a theme).

But it seems the same issue can exist in block themes as well, but since most block theme styles use theme.json instead of style.css we didn't see it.

I guess what I'm saying is that this is a not a new issue and that we should be thinking about the best path long term for this priority issue between "style.css" files and global styles regardless of theme.

But to reduce the impact of the change here, I'm wondering if we should just make both block and classic themes load the "additional css" from the customizer with a higher priority or if we should just keep the fix for classic themes. (restore previous behavior). WDYT?

Restores the $is_block_theme check that was inadvertently removed in [61473]. This ensures that for classic themes, the Customizer's Additional CSS continues to be printed separately via wp_custom_css_cb() at priority 101 in wp_head, preserving its position at the end of the <head> for highest CSS specificity.

For block themes, the Customizer CSS is merged into the global styles stylesheet before the global styles custom CSS, maintaining the intended cascade order.

This fixes two issues introduced by the Global Styles lift for classic themes:

1. Live preview in the Customizer not working for Additional CSS changes.
2. Additional CSS losing its cascade advantage due to being buried in the global styles stylesheet.

Props westonruter.

[westonruter]

@youknowriad I worry about changing the position of either the Additional CSS coming from block themes or the Customizer. Sites have been developed with styles written in the context of a certain CSS cascade.

That said, I'd feel less concerned if the Additional CSS in block themes were moved to be inserted at the very end of the cascade (as the Customizer was outputting at wp_head priority 101), with styles emitted at wp_footer notwithstanding. Since an author has written the Additional CSS in the Site Editor, presumably they would want it to override anything being emitted by core/themes/plugins. So it would seem safer to change the behavior in that direction. Either that, or just restore the previous behavior where the Additional CSS is located in different parts of the CSS cascade for block themes and classic themes.

[youknowriad]

Yes, since it's not crucial for the original issue here, for now I'm going to just revert the behavior for "Additional CSS".

Diff with 470fcfe8d5371684eaaab87b4bc76af7811d6b74, the commit prior to fd2693d97125ab763f159770eb897adec3037906 in which the changes were introduced:

git diff 470fcfe8d5371684eaaab87b4bc76af7811d6b74... -- src/wp-includes/script-loader.php

src/wp-includes/script-loader.php

@@ -2514 +2514 @@
 
         $stylesheet = wp_get_global_stylesheet();
 
+        /*
+         * For block themes, merge Customizer's custom CSS into the global styles stylesheet
+         * before the global styles custom CSS, ensuring proper cascade order.
+         * For classic themes, let the Customizer CSS print separately via wp_custom_css_cb()
+         * at priority 101 in wp_head, preserving its position at the end of the <head>.
+         */
         if ( $is_block_theme ) {
                 /*
                  * Dequeue the Customizer's custom CSS
@@ -3001 +3007 @@
                 usort(
                         $styles,
                         static function ( $a, $b ) {
-                                return ( $a['size'] <= $b['size'] ) ? -1 : 1;
+                                return $a['size'] <=> $b['size'];
                         }
                 );

[youknowriad]

In 61479:

Customize: Preserve CSS cascade for Additional CSS in classic themes.

Restores the $is_block_theme check that was inadvertently removed in [61473]. This ensures that for classic themes, the Customizer's Additional CSS continues to be printed separately via wp_custom_css_cb() at priority 101 in wp_head, preserving its position at the end of the <head> for highest CSS specificity.

Follow-up to [61473].

Props westonruter.
Fixes #64408.