[WIP] Check if a block can be inserted when finding raw transforms

[notnownikki]

Fixes: #11245

Needs discussion on the approach, as this introduces a dependency from blocks to editor.

Description

When blocks are disabled, pasting content that matches their transforms should not insert them.

How has this been tested?

Disable the embed blocks, paste a URL. You should not get an embed block.

Types of changes

Bug fix

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[aduth]

This creates a circular dependency between editor and blocks. The blocks module should not be aware of editor.

Can this be enforced from the editor module instead?

[notnownikki]

If we could introduce a filter, something like:

availableTransforms = applyFilters( 'blocks.transforms', transforms );

then the editor module could register a filter to remove any transforms to blocks that weren't allowed. How does that sound? It seems that this filtering does need to happen here, because if the editor gets a block type that isn't allowed, it doesn't have any information about what to do with it, because the content of the paragraph block that should be created instead could live in any attribute of the block that isn't allowed.

[aduth]

As an alternative to a filter, could we pass as an additional argument an array of "available" block names which can be applied as a filter for the block type? I could see this might be made more difficult by the fact there are other functions within the blocks module which call getBlockTransforms, it's not just called by the editor module.

My worry with a filter might be that in mind of a refactor like proposed in #7119, there may be multiple editors present which each have their own set of limited blocks, which seems difficult/impossible to manage from a single filter.

[notnownikki]

Passing in an argument would work for cases where editor needs a list of valid transforms, but pasteHandler from blocks is used in the RichText component to handle incoming pastes, and neither of these have a dependency on editor, and I figure that we don't want to introduce that either. So we'd have to have a new prop on RichText that was the list of allowed, or denied, block types, so that the RichText instances for the editor instance would have the right list. Does that seem right to you? It would mean altering every instantiation of a RichText component, wouldn't it?

[jorgefilipecosta]

Hi @notnownikki, I guess we don't have this problem anymore, given that we now have a mechanism that ignores blocks in the replace action that cannot be inserted.