Fix: Block manager doesn't respect allowed_block_types hook

[jorgefilipecosta]

Description

Fix: #15598

Currently, the block manager shows blocks that are not allowed by the allowed_block_types filter.
This PR fixes this problem by removing hiding these blocks from the block manager. The user should not notice the existence of blocks not allowed by the allowed_block_types so not showing them in the block manager seems the best approach.

How has this been tested?

I tested these changes without applying any filter, and things worked exactly as before.
I added the following code to functions.php of the currently enabled theme:

function whitelistBlocks( $allowed ) {
	$allowed = [
		'core/image',
		'core/gallery',
		'core/list',
		'core/button',
		'core/columns',
		'core/column',
		'core-embed/youtube',
		'core-embed/vimeo',
		'core/separator',
		'core/text-columns',
		'core/heading',
		'core/subhead',
		'core/block',
		'core/shortcode',
	];
	return $allowed;
}

add_filter( 'allowed_block_types', 'whitelistBlocks' );

I verified only blocks that are returned by whitelistBlocks are part of the block manager; all other blocks don't appear at all.

[aduth]

How feasible would it be to include end-to-end tests here?

[aduth]

I would think we need some dependencies (a second argument) here, at least blockTypes and probably allowedBlockTypes (or settings)?

[jorgefilipecosta]

Updated 👍

[aduth]

I guess this is more for convenience in making the settings available to the modal component? I thought whether we had this tracked in state, but I guess that's only in the editor and block-editor modules. We could do the same in this module as well, but it might be a bit overkill for the one setting we're interested in (I also feel it's already become difficult to manage in the two modules it is present).

[jorgefilipecosta]

Yes, I used context as a convenience. Adding it to the edit-post store seemed overkill, and it seemed it would just bring more confusion, I guess we can reconsider later if we have other reasons to add it. While if we add now, I think we can not easily remove them because of o back-compatibility.

[jorgefilipecosta]

Hi @aduth, your feedback was addressed and an end 2 end test was added.

[youknowriad]

These are all available in the editor store why not just use that store instead of adding a new context provider?

[jorgefilipecosta]

Hi @youknowriad, when a user disables a block in the block manager the block is removed from the editor store allowed blocks. Using just the editor store, it is not possible to differentiate between a block disabled by the user and a block restricted on the server using a plugin. In this case, we need to distinguish both cases.

[youknowriad]

It's minor but It feels like something that can be solved in the store somehow instead of adding a new context for sharing data while we already have a context for that (the store).