Adding option in registerBlockType function to specify post_types to restrict a block from appearing everywhere

[emfluenceindia]

Is your feature request related to a problem? Please describe.
As @greatislander mentioned in #2685 (comment), I believe this should be prioritize in order to make development clean and easy to maintain. There is no point of loading whole bunch of JS in order to hide blocks from certain post types. To me this is not the best way to do.

Describe the solution you'd like
This is how I see it should work. If we have an option in registerBlockType function to let the block know about the post_types where a block would render that would be the ideal solution. If nothing is specified the block will be available for all.

I am thinking something like:

registerBlockType('cgb/my-block-for-event', {
   ...
   post_types: [
      'event',
      'another_post_type',    
   ]
});

The above snippet will make this block available only for event and another_post_type post types.

[swissspidy]

This also needs an equivalent for the register_block_type() function.

I'm using register_block_type() with the editor_script and editor_style arguments and I want that block type to be limited to a specific post type.

For ultimate flexibility this shouldn't be limited to an array of post types, but perhaps a callback function could be passed that determines whether to enqueue the scripts depending on the context.

[pbiron]

Similarly, a list of post_types to not allow the block in would also be useful.

Here's my use case:

• I'm writing a plugin that registers a CPT
• The plugin overrides the theme's template hierarchy to display a custom archive for the CPT
• The plugin also registers a block for displaying that custom CPT archive for use in other post_types
• I would like to tell GB to not allow that block in that CPT (without having to enumerate all other post types in an allow statement).

[manake]

Is this planned?

[paaljoachim]

Limit Block to Certain Post Type(s)
#2685

[aduth]

My initial impression here is that, at least in the context of the client-side editor, a block shouldn't have any knowledge of "post" or "post types". A block type is totally independent from posts.

It feels to me something that should occur server-side. Even there, I think the idea of the independence of block types should hold true. I had considered that it could be up to the plugin developer to detect the post type of the editor before deciding to register their block type. However, I feel that all block types should always be registered, so this is not ideal.

Thus, I think an approach could be one of the following, which may require some changes from core or Gutenberg:

• Support post_types as a property of register_block_type settings.
• Or: Support or enhance allowedBlockTypes (disallowedBlockTypes?) of the block_editor_settings filter to give plugin authors the opportunity to allow/disallow block types on the basis of some logic (e.g. post type)

FYI: allowedBlockTypes does already exist. The problem is that since it's a whitelist, you must know the full set of blocks to allow, which is currently difficult to achieve server-side. As such, improvements would be needed in one of (a) make all block types available server-side and/or (b) also provide a blacklist option disallowedBlockTypes.

Edit: There's also the allowed_block_types filter:

https://developer.wordpress.org/block-editor/developers/filters/block-filters/#hiding-blocks-from-the-inserter

[t-hamano]

I think this problem can now be covered in most scenarios by allowed_block_types_all hook.

function custom_allowed_post_type_blocks( $allowed_block_types, $block_editor_context ) {
	// Limit blocks by post type
	if ( 'book' === $editor_context->post->post_type ) {
		return array(
			'core/paragraph',
			// ...
		);
	}

	// Limit blocks by user role
	if ( ! current_user_can( 'administrator' ) ) {
		return array(
			'core/paragraph',
			// ...
		);
	}

	return $allowed_block_types;
}

add_filter( 'allowed_block_types_all', 'custom_allowed_post_type_blocks', 10, 2 );

On the contrary, you can implement the block you want to disable as follows.

function custom_allowed_post_type_blocks( $allowed_block_types, $block_editor_context ) {

	// Get all registered blocks.
	$all_blocks        = array();
	$registered_blocks = WP_Block_Type_Registry::get_instance()->get_all_registered();

	foreach ( $registered_blocks as $registered_block ) {
		$all_blocks[] = $registered_block->name;
	}

	// Remove blocks.
	$disallowed_blocks = array(
		'core/image',
		//...
	);

	// Return allowed blocks.
	$allowed_block_types = array_values( array_diff( $all_blocks, $disallowed_blocks ) );

	return $allowed_block_types;
}

add_filter( 'allowed_block_types_all', 'custom_allowed_post_type_blocks', 10, 2 );

Therefore, I would like to close this issue, but if you have any scenarios that are not covered by this hook, please feel free to comment.