Inserter: Restrict unallowed block types more broadly

[aduth]

Closes: #3990.
Related: #4091

This pull request seeks to broaden the application of the allowed_block_types to apply more universally. Prior to these changes, if a block type was not allowed, it would still be surfaced in:

• Slash autocomplete
• Frequently used blocks inserter
• Drop zone transforms

Implementation notes:

I debated between the approach here (where each component is responsible for checking allowed block types) and something more low-level where the block types themselves would not be registered. I decided in this direction because "allowed types" is arguably an editor setting, selecting from the totality of block types registered.

Testing instructions:

Ensure tests pass:

npm test

Verify that restricting allowed block types is reflected in the above-listed behaviors.

Example change:

diff --git a/lib/client-assets.php b/lib/client-assets.php
index 31507acc..b1558757 100644
--- a/lib/client-assets.php
+++ b/lib/client-assets.php
@@ -811,7 +811,7 @@ function gutenberg_editor_scripts_and_styles( $hook ) {
         * @param bool|array $allowed_block_types Array of block type slugs, or
         *                                        boolean to enable/disable all.
         */
-       $allowed_block_types = apply_filters( 'allowed_block_types', true );
+       $allowed_block_types = apply_filters( 'allowed_block_types', [ 'core/paragraph' ] );
 
        $editor_settings = array(
                'wideImages'       => ! empty( $gutenberg_theme_support[0]['wide-images'] ),

[aduth]

cc @greatislander

[greatislander]

@aduth Thanks for this! I believe it will also fix #3990 which I reported earlier.

[gziolo]

@aduth what is the current status of this one? Should we also consider filtering based on the category name?

[aduth]

The status of this is that it lacks reviews 😄

Should we also consider filtering based on the category name?

Can you clarify what you mean by this?

[aduth]

Will rebase the branch shortly to resolve conflicts.

[aduth]

References to a few commits which are planned to be dropped in rebase:

• 9ab6465
  • VisualEditorInserter removed in Writing Flow: Trailing placeholder attempt 3 #4539
  • If reintroduced, we'll need to find a way to reconcile with refactoring of Move data logic out of the inserter #4497 (cc @noisysocks)
• b88af3a
  • Superseded by State: Assign default for all allowed blockTypes #4707

[gziolo]

We recently introduced this new function which registers all core block. Can we move now filtering there?

[gziolo]

The status of this is that it lacks reviews 😄

It should be better since I discovered it :)

Should we also consider filtering based on the category name?

Can you clarify what you mean by this?

Yes, so every block has this category type specified. There is another PR open when they propose to make it possible to add custom categories to group 3rd party blocks. I was wondering if we could allow to limit blocks registered based on this value. Let’s say I want to have all blocks that have category embeds or widgets. It’s similar to this filtering but based on a different block’s field. I hope it’s better explained now.

[noisysocks]

If we move ahead with something like #4769 then we won't need the changes that this PR makes to blocksAutocompleter.

We recently introduced this new function which registers all core block. Can we move now filtering there?

This is a good idea. We could just never register a block if it's disabled.

[noisysocks]

Wrong button 😅

[gziolo]

I debated between the approach here (where each component is responsible for checking allowed block types) and something more low-level where the block types themselves would not be registered. I decided in this direction because "allowed types" is arguably an editor setting, selecting from the totality of block types registered.

I should read this earlier :P Sorry about that. However, I still feel that we should discuss if it makes sense to register all blocks and only filter them in UI. Unless there is a reason to register all blocks even in the case when they can't be selected. /cc @mtias

[gziolo]

Related: #3992, #3990.

[aduth]

We'll need to address this, though ideally not in a way which is scattered across the various implementations. Some ideation at #6067 (comment) and #6067 (comment) .