[faisalahammad]

https://core.trac.wordpress.org/ticket/55184

What and why

When block assets load on demand, a stylesheet passed as style_handle to register_block_style() is never loaded, even when the block is on the page. enqueue_block_styles_assets() adds a render_block filter to enqueue it, but it runs on enqueue_block_assets inside wp_head(), and block themes render the whole template before wp_head(). This PR moves the on-demand enqueue into WP_Block::render(), next to the block's own style handles, so it happens as each block renders.

Scope

• In scope: block style style_handle stylesheets when block assets load on demand. Handles registered after the block renders, for example on enqueue_block_assets, are still enqueued once registered.
• Unchanged: when block assets do not load on demand, enqueue_block_styles_assets() enqueues them as before. inline_style handling is not touched.
• This takes a different approach from Script Loader: Fix missing block style loaded with style_handle #6628, which enqueued on wp_loaded and missed handles registered later.

Testing

Unit tests:

npm run test:php -- --filter 'Tests_Blocks_wpBlock|Tests_Blocks_EnqueueBlockStylesAssets'

Manual:

1. npm run env:start, then activate Twenty Twenty-Five.
2. Add a mu-plugin:

   add_action( 'init', function () {
   	wp_register_style( 'my-fancy-heading', content_url( 'mu-plugins/fancy.css' ) );
   	register_block_style(
   		'core/heading',
   		array(
   			'name'         => 'fancy',
   			'label'        => 'Fancy',
   			'style_handle' => 'my-fancy-heading',
   		)
   	);
   } );

3. Create a post with a Heading block using the Fancy style and view it on the front end.
4. On trunk there is no <link id='my-fancy-heading-css'>. With this PR it is printed in <head>.
5. Switch to Twenty Twenty-One (classic theme) and check that the stylesheet still loads.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props faisalahammad, rejaulalomkhan.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[rejaulalomkhan]

Thanks for working on this, @faisalahammad! Moving the block style stylesheet enqueue into WP_Block::render() fixes the on-demand asset loading issue in block themes nicely. I tested the patch locally:

Patch Testing Report

Patch tested: #14461

Environment

• WordPress: 7.2-alpha-63166-src
• PHP: 8.3.35
• Server: nginx/alpine (Docker / local-env)
• Database: MariaDB 11.8.3
• Browser: N/A (unit tests)
• OS: Windows 11 (Docker container Linux)
• Theme: N/A
• MU Plugins: None activated
• Plugins: None activated

Steps taken

1. Reverted src/ to upstream/trunk to verify the new tests on unpatched code: Tests_Blocks_wpBlock::test_render_enqueues_block_style_handle and Tests_Blocks_wpBlock::test_render_enqueues_block_style_handle_registered_after_render both failed with Failed asserting that false is true, accurately reproducing the missing style enqueue.
2. Applied the patch from PR Script Loader: Load the style handle of a custom block style when the block is on the page #14461 and ran single-site tests: all 232 tests in Tests_Blocks_wpBlock and Tests_Blocks_EnqueueBlockStylesAssets passed (493 assertions).
3. Ran multisite tests (-c tests/phpunit/multisite.xml): all 232 tests passed cleanly.
4. Ran tests in random order (--order-by=random): all 232 tests passed with no test isolation issues.
5. Ran PHPCS on all 4 modified and added files (class-wp-block.php, script-loader.php, enqueueBlockStylesAssets.php, wpBlock.php): 0 errors, 0 warnings.
6. Ran the full blocks test group: all 735 tests passed (3,475 assertions).
7. ✅ Patch is solving the problem: stylesheets passed as style_handle to register_block_style() are enqueued during block render when block assets load on demand, including handles registered after initial render.

Expected result

• Block style stylesheets registered with a style_handle are enqueued when the block renders under should_load_block_assets_on_demand, while preserving the existing behavior when assets are not loaded on demand.

Additional Notes

• AI assistance: Antigravity was used to run the tests; results reviewed by me.