Custom style handle attached to a custom block style is never load even if the block is in the page.

[alexandrebuffet]

Description

I have a custom block based theme running on WP 5.9 that declares custom styles for certain blocks via the register_block_style function, but when I specify a style_handle the style is never enqueue even though the block is present in the page content (and core block assets are only loaded when they are rendered).

This issue ref to ticket #54457 https://core.trac.wordpress.org/ticket/54457

Step-by-step reproduction instructions

1. Create a theme
2. Register a custom "Display" block style for the "Heading" block via register_block_style with "my-theme-block-style-css" style_handle
3. Register a "my-theme-block-style-css" style via wp_register_style
4. Add "Heading" block in page content with our "Display" style
5. Check CSS, "my-theme-block-style-css" is not loaded

The relevant code

It seems that the render_block filter callback in enqueue_block_styles_assets from script-loader.php never fire.

script-loader.php
​https://github.com/WordPress/wordpress-develop/blob/master/src/wp-includes/script-loader.php#L2463-L2477

https://core.trac.wordpress.org/changeset/52262

[alexandrebuffet]

Block style registration code

[daymobrew]

I encountered the same issue (I called wp_register_style in the 'init' hook).
​https://gist.github.com/damiencarbery/49cbd76c30b5116fecb7a30d0439142a#file-dcwd-custom-block-styles-php

The CSS is enqueued when a theme does not include 'wp-block-styles' support (hence my workaround to enqueue when it does support that).
Enqueuing works correctly when editing the page. The issue is only on the front end.

[daymobrew]

It is supposed to have been fixed by https://core.trac.wordpress.org/ticket/54457 but it isn't.

[Drivingralle]

I can confirm the problem persist in WP v6.0.1

Code to quickly test it:

add_action( 'init', function () {
	wp_register_style( 'my-fancy-quote', get_template_directory_uri() . '/my-fancy-quote-style.css' );
	register_block_style(
		'core/quote',
		array(
			'name'         => 'fancy-quote',
			'label'        => __( 'Fancy Quote', 'textdomain' ),
			'style' => 'my-fancy-quote',
		)
	);
} );

The handbook says the parmeter is called "style_handle":
​https://developer.wordpress.org/block-editor/reference-guides/block-api/block-styles/

The core says it's called "style" in some place:
​https://github.com/WordPress/WordPress/blob/master/wp-includes/blocks.php#L993
and "style_handle" in other places:
​https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-block-styles-registry.php#L41

Both of them are not working.

[pagelab]

I can also confirm the bug. AFAIK the issue is that the patch on #54457 uses the render_block() filter in the enqueue_block_styles_assets function to conditionally enqueue the registered block style, but this function runs on the enqueue_block_assets hook (see wp-includes\default-filters.php), which is too late for render_block().

[poena]

#60367 was marked as a duplicate.

Fix missing block style loaded with style_handle.

It's possible to register a block style with a handle instead of an inline style. In that case and when wp_should_load_separate_core_block_assets() is true, the current code will rely on the render_block filter to detect if the block is used on the page and the block style need to be enqueued.

This doesn't work as expected, since the function is called in enqueue_block_assets after the render_block filter has run.

This PR add a new function hooked to wp_loaded to fix the issue.

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

Is there any update on this?
I would love to see this fixed soon so I can start including my block style variations in their own stylesheets.

[jonsurrell]

Linking Gutenberg issue ​https://github.com/WordPress/gutenberg/issues/27244. I believe it's reporting the same issue.

There are merge conflicts that need to be resolved and tests that need to be added. I haven't dug into the code yet to evaluate the approach.

Hi there, I was testing this implementation and I think there's a small problem related to the fact that wp_loaded runs before wp_enqueue_scripts.

If I register a block style via the register_block_style I suppose I do that at init. For instance;

add_action('init', function () {
    register_block_style(
        'core/button',
        [
            'name' => $name,
            'label' => $label,
            'style_handle' => 'my-style-handle',
        ]
    );
});

The style handle imply I will take care of registering the style, which happen at wp_enqueue_scripts usually, but this action is performed after wp_loaded, hence, the following condition will always meet and the styles are not enqueued on the front end when

if ( 
    ! isset( $style_properties['style_handle'] ) || 
    ! isset( $wp_styles->registered[ $style_properties['style_handle'] ] ) 
) {
    continue;
}

A way to solve this problem is to register the style before wp_enqueue_scripts for instance at init but usually people would add those styles at the former, so it should be documented somewhere that, if you want to use a style handle you have to register its style at init.

Another option could be to register the style right away, if you want to pass an handle, you have to add a configuration permitting to call wp_register_style.

As an example, the style_handle could be of type string | array, we imply that if you pass a string you'll take care of registering the style at the right point in time, if you pass an array then, we know you want to let WordPress to register the style for you.

This approach will let consumers to integrate better with WordPress as the call to wp_register_style will check they are calling register_block_style at the right moment to register the style.

add_action('init', function () {
    register_block_style(
        'core/button',
        [
            'name' => $name,
            'label' => $label,
            'style_handle' => [
                'handle' => 'my-style-handle',
                // ... the other arguments for `wp_register_style`
            ]
        ]
    );
});

[westonruter]

Here's the PHP code extracted from block-styles.png​:

<?php
/**
 * Registers block styles stylesheets.
 *
 * @since My Theme 1.0.0
 *
 * @return void
 */
function my_theme_register_block_style_stylesheets() {

        wp_register_style(
                'my-theme-post-terms-style-labels',
                get_template_directory_uri() . '/assets/css/blocks/post-terms/style-labels.css',
                array(),
                MY_THEME_VERSION
        );

}

add_action( 'enqueue_block_assets', 'my_theme_register_block_style_stylesheets' );
add_action( 'admin_enqueue_scripts', 'my_theme_register_block_style_stylesheets' );

/**
 * Registers block styles.
 *
 * @since My Theme 1.0.0
 *
 * @return void
 */
function my_theme_register_block_styles() {

        register_block_style(
                'core/post-terms',
                array(
                        'name'         => 'labels',
                        'label'        => __( 'Labels', 'my-theme' ),
                        'is_default'   => true,
                        'style_handle' => 'my-theme-post-terms-style-labels',
                ),
        );

}

add_action( 'init', 'my_theme_register_block_styles', 9 );

This PR is almost 2-years stale now and there are merge conflicts. Either it should be closed in favor of a new PR, or the merge conflicts need to be resolved.

[westonruter]

Is this issue observed on both classic themes and block themes?