[wp-trac] [WordPress Trac] #63676: Blocks without rendered content (including blocks via block visibility) still enqueue scripts and styles

WordPress Trac noreply at wordpress.org
Tue Oct 14 07:12:53 UTC 2025


#63676: Blocks without rendered content (including blocks via block visibility)
still enqueue scripts and styles
-------------------------------------+-------------------------------------
 Reporter:  westonruter              |       Owner:  westonruter
     Type:  defect (bug)             |      Status:  reopened
 Priority:  normal                   |   Milestone:  6.9
Component:  Editor                   |     Version:  5.9
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  javascript, css,
  dev-feedback has-unit-tests        |  performance
-------------------------------------+-------------------------------------
Changes (by dd32):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 @westonruter This has caused breakage on WordPress.org - #meta8104, and
 the `enqueue_empty_block_content_assets` filter doesn't seem to be related
 at all (It didn't even fire).

 I'm not 100% sure why this is happening, as it doesn't appear that it's
 directly related to this skipping logic, but rather that the queued data
 is being lost somehow - perhaps being overwritten with older data.[[BR]]
 So I'm thinking this could be related to nested blocks, where a
 script/style is registered from within one of those subblocks.

 For example, this plugin adds one of the styles that were missing:
 https://github.com/WordPress/wordpress.org/blob/trunk/wordpress.org/public_html
 /wp-content/plugins/wporg-bbp-code-blocks-expand-contract/wporg-bbp-code-
 blocks-expand-contract.php#L27-L46

 That's a fairly basic enqueue, but the only thing I can think of is it
 being fired from within a block wporg/global-header.
 https://github.com/WordPress/wporg-mu-plugins/tree/trunk/mu-plugins/blocks
 /global-header-footer

 Here's a diff of two WordPress.org sites before/after that changeset.

 Here's a diff of wordpress.org/support/forums/:
 https://gist.github.com/dd32/a9441db9a3fac0ce2a962625f7ca2aef

 Here's a diff of make.wordpress.org/updates/:
 https://gist.github.com/dd32/6a495ca9617384a33ebd73997859fe69

 I'm unable to figure out how to duplicate this on a stand alone site,
 https://github.com/wordpress/wporg-parent-2021 might reproduce it (but
 it's provisioning is broken for me right now)

 ----

 One thing I've noticed (But I don't believe isn't entirely unrelated) is
 that I believe `wp_script_is( 'admin-bar', 'enqueued' )` would now return
 false during the block render even if it was enqueued, but is not enqueued
 directly (or required by one of the currently enqueued scripts).

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


More information about the wp-trac mailing list