WP 6.9.1still have issue with load block styles on demand in classic themes

[philip3524576]

Hi there,

We are running multiple websites on WordPress 6.9.1 using classic themes. Since WordPress 6.9.0, the Gravity Forms layout has been broken due to the change in “load block styles on demand” for classic themes introduced in 6.9.0.

As a workaround, we had to install the Load Combined Core Block Assets plugin to restore the Gravity Forms layout. We expected this issue to be resolved in WordPress 6.9.1, but after testing across multiple sites, the problem still persists.

Could you please confirm whether this is a known issue and if there is a planned fix?

Thanks in advance for your help.

[westonruter]

Hello. Thank you for the report.

The ticket for 6.9.1 which was intended to resolve the issue is #64354.

Nevertheless, there is also #64389 which I wasn't sure of whether it was a duplicate of that ticket or not. Since the issue persists in some cases, such as yours, it appears to not be a duplicate but that the issue is not fully fixed. However, it could also be that the Gravity Forms layout is assuming that all styles will always be printed on every page, which is not a safe assumption as it is not the case for block themes.

As requested in the other ticket, please provide specific steps for how the issue can be reproduced.

This may end up getting closed as a duplicate of #64389.

[philip3524576]

Hi,

I would like to add more details to this issue.

When we create a Gravity Form that includes a Name field or any Hidden field, the frontend layout loses its styling. This happens because the following stylesheet is not loaded:

/wp-content/plugins/gravityforms/assets/css/dist/basic.min.css?ver=2.9.26

This appears to be related to the following filter:

add_filter( 'should_load_separate_core_block_assets', 'return_false' );

Given this behavior, will WordPress Core ensure compatibility with plugins (such as Gravity Forms) when using Classic themes?
Specifically, is it possible for separate_core_block_assets to be enabled or handled differently by default so that required styles still load correctly in Classic themes?

Thanks

[westonruter]

@philip3524576 thanks providing a bit more detail on how this can be reproduced. Have you reached out to Gravity Forms support about this issue? Given that Gravity Forms is a commercial plugin it is difficult for me to investigate what is going on. I suggest that you get in touch with their development team to troubleshoot this. Make sure they see the relevant ​field guide section. If they can identify a problem in core that needs to be fixed as opposed to something in their plugin, I'd be happy to continue collaborating.

[westonruter]

Re-posting my comment from #64389:

I've just finished another pass at improving the preservation of classic theme CSS cascade when loading block styles on demand.

The PR description has been fleshed out with all the details, but in short:

1. Determining where to insert the styles hoisted from the footer has been made more robust by inserting placeholder inline styles. This simplifies the insertion logic since it doesn't have to hunt around for references for where styles should be inserted. It merely needs to replace the placeholders with the captured styles.
2. The CSS cascade is now improved for inline styles which had been added to wp-block-library. Now when loading separate block styles, any such inline styles get added after any of the separate core block styles.

Note: Do not have Gutenberg active when testing this, as the patch has not yet been applied to Gutenberg's forked version of wp_enqueue_global_styles().

Review and testing much appreciated: ​https://github.com/WordPress/wordpress-develop/pull/10875

I really hope to get this into the next beta.

[westonruter]

In [61945] I've committed significant improvements to the CSS cascade in classic themes which will be part of 7.0-beta5 due out tomorrow.

I do not know for sure whether this ticket is a duplicate of #64389 but as far as I know it is. So I'm closing this as a duplicate.

If it isn't, we can re-open.

[djboris88]

Reproduction found: Google Site Kit (authenticated user) triggers loss of all hoisted styles

We hit this in production and can now reproduce it deterministically. The missing variable that makes this bug appear "random" is Site Kit by Google — but only for users who have access to its data (admin bar stats / dashboard sharing). Anonymous visitors and logged-in users without Site Kit access get correct markup from the same URL, which is why this is so hard to reproduce.

Environment

• WordPress 6.9.1, classic theme (JNews + child theme), PHP 8.2
• Site Kit by Google 1.173.0, connected, admin bar stats enabled
• Reproduces on uncached, fresh renders (logged-in requests bypass all caching layers in our setup)

Steps to reproduce

1. Classic theme on WP 6.9.1 (on-demand block styles + hoisting active by default).
2. Install + connect Site Kit, enable "Display relevant page stats in the Admin bar".
3. As a user with Site Kit access, open a published post containing core blocks and/or a custom block registered via register_block_type( $dir, [ 'style' => $handle ] ).
4. View source: every style that travels through wp_hoist_late_printed_styles() is missing — no tag in HEAD, no tag in footer, no request, no console error.
5. Same URL as a user without Site Kit access (or anonymous): all styles present and correctly hoisted.

We A/B confirmed causation: granting Site Kit access to a previously unaffected account makes that account reproduce the bug; the bug follows Site Kit, not the user/browser/OS.

Evidence from captured HTML (broken vs good, same post)

Missing in the broken page only:

• all per-block core styles (wp-block-paragraph-inline-css, wp-block-heading-inline-css, …)
• core-block-supports-inline-css
• global-styles-inline-css
• third-party block styles (a <link> registered via register_block_type and an inlined -inline-css one)

Present in both pages:

• the anchors: wp-block-library-inline-css and classic-theme-styles-inline-css
• identical script order, admin bar, footer — pages are otherwise equivalent

Crucially, the wp_block_styles_on_demand_placeholder CSS comment is removed in the broken page too. So the output buffer started, the wp_template_enhancement_output_buffer filter ran and found its anchor — but all captured style variables were empty at insertion time. The styles were captured (marked done) and never delivered.

Possible mechanism

Note the capture closure in wp_hoist_late_printed_styles() is not idempotent: if wp_print_footer_scripts effectively fires a second time (or the closure runs again), wp_styles()->queue still contains the handles but they are already in done, so do_items() outputs nothing and the by-reference vars ($printed_core_block_styles, $printed_other_block_styles, $printed_global_styles, $printed_late_styles) are overwritten with empty strings. A did_action()-style guard / not overwriting non-empty captures would make this fail-safe regardless of what plugins do.

For authorized users, Site Kit's front-end payload is substantial: ~24 footer scripts, plus "before print" callbacks on wp_print_scripts/wp_print_styles (includes/Core/Assets/Assets.php) whose script-data callback executes ~15 inline REST requests via rest_preload_api_request() during printing. We have not yet isolated the exact call that disturbs the capture/finalize sequence — happy to debug further if useful, and we can share the two full HTML captures.

Workaround in production

add_filter( 'should_load_separate_core_block_assets', '__return_false', 100 );

FYI @westonruter