Gutenberg: Is it possible to disable default block styles?

[dashkevych]

Some blocks come with multiple styles. For example, a default Quote block offers two styles: Regular and Large. I am wondering, if it's possible to disable a specific style. add_theme_support() maybe?

[ocean90]

Yes, with #10654 you can use wp.blocks.unregisterBlockStyle(). The function be part of the next version.

Example to disable the large style:

const unregisterBlockStyle = wp.blocks.unregisterBlockStyle;
unregisterBlockStyle( 'core/quote', 'large' );

[nickcernis]

wp.blocks.unregisterBlockStyle has no effect on core blocks for me (WP 5.0 Beta 4/Gutenberg 4.3), at least when enqueued in a theme via 'init' or 'enqueue_block_editor_assets' like this:

add_action( 'enqueue_block_editor_assets', 'theme_name_block_editor_styles' );
/**
 * Enqueues Gutenberg admin editor scripts.
 *
 * @since 2.7.0
 */
function theme_name_block_editor_styles() {

    wp_enqueue_script(
        'theme-name-editor',
        get_stylesheet_directory_uri() . '/lib/gutenberg/js/editor.js',
        array( 'wp-blocks' ),
        '1.0.0'
    );

}

I had to use a filter in /lib/gutenberg/js/editor.js to filter block styles like this instead:

var yourTheme = (function () {
    'use strict';

    function adjustBlockStyles(settings, name) {
        switch (name) {
            case 'core/quote':
                return removeStyles(settings, ['large']);
            case 'core/button':
                setDefaultLabel(settings, 'Squared');
                return removeStyles(settings, ['outline', 'squared']);
            case 'core/pullquote':
                return removeStyles(settings, ['solid-color']);
            case 'core/separator':
                return removeStyles(settings, ['wide', 'dots']);
            case 'core/table':
                return removeStyles(settings, ['stripes']);
            default:
                return settings;
        }
    }

    function setDefaultLabel(settings, newLabel) {
        settings['styles'] = settings['styles'].map(function (style) {
            if (style.isDefault) style.label = newLabel;
            return style;
        });
    }

    function removeStyles(settings, styles) {
        settings['styles'] = settings['styles'].filter(function (style) {
            return styles.indexOf(style.name) === -1;
        });
        return settings;
    }

    return {
        adjustBlockStyles: adjustBlockStyles
    };

}());

wp.hooks.addFilter(
    'blocks.registerBlockType',
    'yourtheme/editor',
    yourTheme.adjustBlockStyles
);

You can add console.log(name, settings.styles); at the top of adjustBlockStyles before the switch statement to see a list of all active blocks and their available style names prior to being filtered.

[mukeshpanchal27]

@nickcernis filter working fine and it remove styles.

As per Gutenberg handbook doc - https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#modifying-blocks to remove any predefined block style add below code but that code not working means style is not removed when we add that code.

wp.blocks.unregisterBlockStyle( 'core/quote', 'large' );

Above function use REMOVE_BLOCK_STYLES type but it not working

case 'REMOVE_BLOCK_STYLES':
  return Object(_babel_runtime_helpers_esm_objectSpread__WEBPACK_IMPORTED_MODULE_2__["default"])({}, state, Object(_babel_runtime_helpers_esm_defineProperty__WEBPACK_IMPORTED_MODULE_0__["default"])({}, action.blockName, Object(lodash__WEBPACK_IMPORTED_MODULE_3__["filter"])( state, [action.blockName], []), function (style) {
    return action.styleNames.indexOf(style.name) === -1;
  }));

[mario-neuhold]

Via Chrome Dev Console the function is working fine.
wp.blocks.unregisterBlockStyle( 'core/button', 'squared' ); makes that style in the button block inspector disappear as expected.

So I suspect it's connected to the timing issues from #11532 - but that should be included since 4.3 if I understand it right?

[florianbrinkmann]

I’m having the same issue. I can register a new style for core blocks via wp.blocks.registerBlockStyle without problems, but trying to unregister a style of a core block in the same place has no effect.

[dgwyer]

@mario-neuhold Exactly the same behavior here. Removal via console is OK but from a plugin it's ignored even when enqueuing my JS to load in the editor after wp-blocks, wp-i18n, wp-element.

[ocean90]

Removing works fine for me with the following example:

wp.domReady( () => {
    wp.blocks.unregisterBlockStyle( 'core/quote', 'default' );
    wp.blocks.unregisterBlockStyle( 'core/quote', 'large' );

    wp.blocks.unregisterBlockStyle( 'core/button', 'default' );
    wp.blocks.unregisterBlockStyle( 'core/button', 'outline' );
    wp.blocks.unregisterBlockStyle( 'core/button', 'squared' );
} );

This script is enqueued via wp_enqueue_script( 'gutenberg-testing', plugins_url( 'editor.js', __FILE__ ), array( 'wp-blocks', 'wp-dom' ), time(), true );

Can you provide an example plugin where it's not working?

[nickcernis]

@ocean90 That's now working for me as of 5.0 RC1. (I tried the same before in a theme and it had no effect.)

[florianbrinkmann]

Didn’t know about that wp.domReady, with that it works for me too, thanks @ocean90! :)

[erikjoling]

I got it to work as well.

Two things to notice:

• It doesn't work without wp.domReady. Documentation needs to be updated
• The script needs to be added to the footer, otherwise wp.domReady is not available (even with wp-dom added as a dependancy).

[swissspidy]

Apparently it should work without wp.domReady since #11532, but yeah doesn't look like it.

@youknowriad Can you confirm that this shouldn't be necessary?

---

The script needs to be added to the footer,

All wp-* scripts are set to be enqueued in the footer by default. So if you add them as a dependency, your script should be enqueued in the footer as well. You don't need to explicitly set it.

Make sure to test with WordPress 5.0 RC 1

[youknowriad]

11532 doesn't remove the need for wp.domReady because the regular block styles are added only when the block is ready, so if you want to remove them, they should present, otherwise, they will just get re-added later.

[ocean90]

Closing since this was fixed with #10654 (and #11532). #11392 is still open for improving docs.