Blocks: Filterable allowed inserter block types

[aduth]

This pull request seeks to enable filtering of block types offered through the Inserter component. It does so both in the client and in the server.

On the server, a plugin author can filter allowed_block_types to return either true (all block types supported), false (no block types supported), or an array of block type names to allow. This may enable custom post types to limit the types of blocks allowed.

In the client, since the block types are passed through as a setting in EditorProvider, creating a new provider context with settings specifying block types is sufficient to limit permitted block types. This will become relevant for block nesting to allow a block to define allowed children types.

Implementation notes:

The behavior here required that an editor component gain access to editor context. The existing withEditorSettings higher-order component would have worked, but was implemented expecting to be used only in the context of the blocks module. With the changes here, I have moved withEditorSettings to a more generic withContext higher-order component in the components module, allowing a component to opt-in to receiving context of any name.

Testing instructions:

Ensure unit tests pass:

npm test

Verify that you can filter block types, e.g. adding filters to one of Gutenberg's PHP files:

Disable all block types (no inserter is shown):

add_filter( 'allowed_block_types', '__return_false' );

Restrict block types:

add_filter( 'allowed_block_types', function() {
	return [ 'core/paragraph' ];
} );

[codecov]

Codecov Report

Merging #3577 into master will increase coverage by 0.05%.
The diff coverage is 65.71%.

@@            Coverage Diff             @@
##           master    #3577      +/-   ##
==========================================
+ Coverage   35.29%   35.34%   +0.05%     
==========================================
  Files         267      267              
  Lines        6744     6762      +18     
  Branches     1221     1226       +5     
==========================================
+ Hits         2380     2390      +10     
- Misses       3687     3694       +7     
- Partials      677      678       +1

Impacted Files	Coverage Δ
blocks/library/image/block.js	1.85% <ø> (ø)	⬆️
blocks/color-palette/index.js	0% <ø> (ø)	⬆️
blocks/block-alignment-toolbar/index.js	33.33% <ø> (ø)	⬆️
editor/components/inserter/index.js	0% <0%> (ø)	⬆️
components/higher-order/with-context/index.js	57.14% <66.66%> (ø)
editor/components/inserter/menu.js	85.54% <84%> (-1.79%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7cc7b8c...e6642bc. Read the comment docs.

[aduth]

After reading the proposed documentation in #3567, it seems we have a few other options for limiting the types of blocks supported:

• Avoiding enqueuing their scripts in the first place (how to handle server-side registered?)
• Unregistering them after the editor has loaded

cc @youknowriad

[youknowriad]

it seems we have a few other options for limiting the types of blocks supported:

Yes, we do but I do see the value of setting the block types in the "context", I was originally thinking we should add them to editor settings and just use withEditorSettings.

I'm not sure I understand why you can't use this in the editor module since it depends on the blocks module.

--

So if I understand properly, this only affects the Inserter and still use the globally registered blocks (and for example pasting, converting can still make use of these block types). I think it's a good first step but I'd love if we can avoid to use the globally registered blocks at all, and just provide the available blocks in the context. I tried this in one of my previous PRs, it could work but it's a way bigger change. I think this could also be valuable for nesting as well where we'd want to limit the available blocks.

[aduth]

I'm not sure I understand why you can't use this in the editor module since it depends on the blocks module.

Not so much that it couldn't be done. Something about the editor consuming components from blocks didn't feel as clean as referencing the registration.