Discuss api for disabling blocks after registration

[braders]

Quite a bit of discussion has taken place around how to register blocks, but I have not seen any mention of how these blocks could later be disabled (hidden, unregistereded). This might seem like a strange thing to want to do, but I think it could have a number of use cases:

• Disable core blocks - a number of core blocks might not be appropriate for every theme, especially where the theme is bespoke or private. For example, a parallax block has been discussed which may not work with some front-end designs. For older themes, some blocks will never have been considered, and may require significant work to fit the theme; in these cases simply disabling the problem blocks seems a good compromise.

• disable plugin blocks - plugins often try to do many things (often too much imho), and so you may wish to disable one or more blocks, whilst retaining the rest of the plugin's functionality.

• based on post type - It may be desirable to have a block available only for certain post types. (Potentially​ useful for both themes & plugins)

• based on dom &/or js events - for example enabling/ disabling blocks based on the page template value (or other fields and post meta).

[westonruter]

Yeah, certain blocks should also potentially need to be disabled for page templates, when those get implemented. A template could, for example, have a fixed set of block slots that only accept given block types. So non-supported block types should be blocked in that case.

[mtias]

There's already an initial API for this: https://github.com/WordPress/gutenberg/blob/master/blocks/api/registration.js#L58-L68

[aduth]

I don't know that an issue was ever created for it, but there was some previous discussion about the reverse for the same intent. In other words, it's not that you'd disable blocks, but rather no blocks are enabled by default and all blocks must be opted-in as relevant for the editor session.

Another cited example being blocks relevant to page building once we reach that point.

[BE-Webdesign]

Somewhat related, would be to create individual registries: #336

This idea could have many usecases, like registering core blocks, registering woocommerce blocks, and combining different sets to make the total available blocks for a particular instance of the editor.

[mrjarbenne]

As a K12 Educational institution, we would need to disable blocks like College Humor, and Funny or Die, just to avoid advertising that you can embed content from those sites on our network. Existence infers endorsement in these cases, and we would want parents thinking we had populated the Embed menu with a vetted list of sites.

[nylen]

It seems like all of this should be doable with our existing API functions. I expect you can unregister or otherwise manipulate blocks in the same place that you can register other ones, and the main thing to work out here is code loading order of plugins that interact with the editor.

Then we want to test this feature by writing a simple plugin that unregisters specific blocks, possibly depending on custom code like post type.

[kopepasah]

@nylen would you recommend creating a ticket on Gutenberg repo that someone may pickup to create an external plugin for testing? If the functionality for disabling blocks already exists, it seems like this issue can be closed.

[mtias]

Another issue we should open is a way to opt-in into specific blocks. Say for my post type I only want to allow "Image" and "Gallery" block", but I don't want to unregister every single block (and potentially every plugin added block).

[nylen]

@nylen would you recommend creating a ticket on Gutenberg repo that someone may pickup to create an external plugin for testing?

Yes, which depends on the method of injecting scripts and styles for other blocks (TBD, see #1420 for example). This testing will be really valuable, but at the moment there is a lot that we haven't figured out yet.

Say for my post type I only want to allow "Image" and "Gallery" block", but I don't want to unregister every single block

This is already possible with our existing APIs (loop over all blocks and unregister the ones you don't want). I don't think we should make it any easier than that.

[mtias]

This is already possible with our existing APIs (loop over all blocks and unregister the ones you don't want).

Not if I don't know which ones may exist that I don't want. Think of providing an array of supported blocks instead of unregistering the ones you don't want.

[nylen]

Yes, this is fine. The logic would look something like this:

getBlocks().forEach( block => {
    switch ( block.name ) {
        case 'core/text':
        case 'core/image':
            // Leave it alone
            break;
        default:
            unregisterBlock( block.name );
            break;
    }
} );

This seems like such an edge case that we shouldn't support it any further than that. It would effectively break any plugins that add blocks, for example.

[mrjarbenne]

That works for me. We do something similar for Shortcake: https://github.com/hwdsbcommons/curate-the-bakery/blob/master/curate_the_bakery.php

And Jetpack: https://github.com/hwdsbcommons/block-jetpack/blob/master/class-umw-multisite-jetpack-control.php