[wp-trac] [WordPress Trac] #64592: WP 6.9.1still have issue with load block styles on demand in classic themes

[WordPress Trac]

#64592: WP 6.9.1still have issue with load block styles on demand in classic themes
-------------------------------+------------------------
 Reporter:  philip3524576      |       Owner:  (none)
     Type:  defect (bug)       |      Status:  closed
 Priority:  normal             |   Milestone:
Component:  Script Loader      |     Version:  6.9.1
 Severity:  normal             |  Resolution:  duplicate
 Keywords:  reporter-feedback  |     Focuses:  css
-------------------------------+------------------------

Comment (by 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 ===
 {{{#!php
 add_filter( 'should_load_separate_core_block_assets', '__return_false',
 100 );
 }}}

 FYI @westonruter

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64592#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform