Gutenberg: wp.blocks.unregisterBlockStyle() does not appear to be working

[mor10]

Describe the bug
When using wp.blocks.unregisterBlockStyle(), the specified block style variation is not unregistered.

To Reproduce
Steps to reproduce the behavior:

1. call wp.blocks.unregisterBlockStyle( 'core/quote', 'large' ); or similar.
2. Block style variation is still available in the editor.

Expected behavior
Specified block style should be removed.

WP 5.0.1

[mor10]

see https://wordpress.org/gutenberg/handbook/designers-developers/developers/filters/block-filters/

Also, the example in documentation doesn't work because the fancy-quote style doesn't exist. Should be updated.

[espenjanson]

You need to do this as well:

https://wordpress.org/gutenberg/handbook/designers-developers/developers/filters/block-filters/#hiding-blocks-from-the-inserter

Edit: Temporary solution until the issue is solved.

[espenjanson]

But docs are not clear, agreed!

[mor10]

"Not clear" is an understatement.

[espenjanson]

I think that goes for 98% of the docs

[mor10]

Wait, this doesn't make any sense. You use the enqueue_block_editor_assets hook to register / unregister blocks and variations (https://wordpress.org/gutenberg/handbook/designers-developers/developers/filters/block-filters/#using-a-blacklist), but to remove them from display, you have to use the allowed_block_types hook? What's the point of unregistering them then?

[reactforwordpress]

Guessing here but wouldn’t a simple hide from inserter mean that you could still use registered blocks in transforms, as children etc? It’s weird that they’re not hidden from the inserter on unregister though.

[swissspidy]

How are you calling wp.blocks.unregisterBlockStyle( 'core/quote', 'large' )? In the developer console or in a JS file added with wp_enqueue_script()?

[espenjanson]

@swissspidy Since the only way I (and mor10) can get it to work is the solution I suggested, I think the downvote is uncalled for. Unregistering blocks from the editor doesn't work using only js if one follows the documentation. And yes, I am enqueuing like you suggest one should.

whitelist.js:

var allowedBlocks = [
  "rfw-blocks/intro-section",
  "rfw-blocks/search-cta",
  "rfw-blocks/button",
  "core/heading"
];

wp.blocks.getBlockTypes().forEach(function(blockType) {
  if (allowedBlocks.indexOf(blockType.name) === -1) {
    wp.blocks.unregisterBlockType(blockType.name);
  }
});

PHP:

function rfw_blocks_whitelist_blocks() {
    wp_enqueue_script(
        'rfw-blocks-whitelist-blocks',
        plugins_url( '/assets/js/whitelist.js', dirname( __FILE__ ) ),
        array( 'wp-blocks' )
    );
}

add_action( 'enqueue_block_editor_assets', 'rfw_blocks_whitelist_blocks' );

Does not work.

Logging blockType shows that only my custom block types get returned by wp.blocks.getBlockTypes(), none of the core blocks.

[swissspidy]

@espenjanson Hiding blocks from the inserter is something different than removing block _styles_, isn't it?

I was asking about the enqueueing because there can be race conditions when not adding wp-edit-post as a dependency. See the discussion at https://github.com/WordPress/gutenberg/pull/12613#pullrequestreview-184781846 about this.

[espenjanson]

@swissspidy Well I think the ends justify the means here, I think we both understand what he was trying to achieve. Don't you? When a product has as many bugs as Gutenberg currently does, us developers rely on workarounds like mine until you fix those issues and update the documentation.

But sure, I should have added "I am experiencing this problem too, a temporary solution could be..."

[mor10]

@swissspidy I'm calling wp.blocks.unregisterBlockStyle( 'core/quote', 'large' ) from a JS file using wp_enqueue_script() hooked at enqueue_block_editor_assets. This has no effect on the editor and the block style remains in place.

[ocean90]

See https://github.com/WordPress/gutenberg/issues/11338#issuecomment-441451465 and #11392

[mor10]

Documentation definitely needed.