Blocks: Provide a general solution to customize the list of allowed blocks for inner blocks with block attributes

[edirpedro]

Part of #41236.

For example the Media and Text block can accept only [ 'core/button', 'core/paragraph', 'core/heading', 'core/list' ] and due the fact the heading block doesn't offer an option for color, I created my own block to use inside the Media and Text block, but it's not possible and I couldn't add my block to the allowed list.

I expected to filter the allowedBlocks list like that.

wp.hooks.addFilter(
	'blocks.registerBlockType',
	'core/media-text',
	function( settings, name ) {
		if ( name !== 'core/media-text' )
			return settings;
		settings.allowed_blocks.push( 'my/heading' );
		return settings;
	}
);

[gziolo]

@jorgefilipecosta - I guess this is not possible as of today given that the list of allowed blocks is hardcoded in the edit definition:

gutenberg/packages/block-library/src/media-text/edit.js

Lines 235 to 239 in 1a20e15

	<InnerBlocks
	allowedBlocks={ ALLOWED_BLOCKS }
	template={ TEMPLATE }
	templateInsertUpdatesSelection={ false }
	/>

[jorgefilipecosta]

Yes, unfortunately, we don't have a way to filter allowedBlocks in InnerBlock scenarios. Maybe we could add a generic filter that allows changing InnerBlocks properties? cc: @gziolo

For the specific case in question, a possible workaround is to define the newly created block as a child block of the media & text block, child blocks are allowed even if the allowedBlocks setting does not include them. cc: @edirpedro

[mmtr]

Maybe we could add a generic filter that allows changing InnerBlocks properties?

I wonder if we could be even more flexible and add some filter to canInsertBlockTypeUnmemoized, so the allowed blocks can be determined fully dynamically.

There might be some cases where a block can be inserted depending on the current editor state. For instance, in Automattic/wp-calypso#41850 we're interested in making a custom button block insertable as a inner block of core/buttons, but only on core/buttons blocks that are descendant of a particular custom container block.

[gziolo]

I am noting that there is an open PR #49128 that proposes adding allowedBlocks attribute and passing it to innerBlockProps for the Group block. A similar solution exists for the Cover and Columns blocks. I hope we can come up with a more general solution.

[gaambo]

A general solution to this problem would be great. The media and text block is a very common use case for this in my projects - we often only want the client to insert "text blocks" (paragraph, heading, button, list) and not embeds or "layout" blocks. Providing this option on a per-instance basis to blocks is great. Some core blocks already allow this, but not all. So combining these efforts would be great.

[gziolo]

Ideally, the information about the allowed inner blocks would be stored in attributes in some type of the metadata attribute that holds all the details about the block related to its configuration in the editor, which isn’t concerned with the content or design. The prior art is the lock attribute which is one of the top-level global attributes (see). Still, that approach might not scale well as we need to ensure that the every new attribute name added for metadata doesn’t conflict with what existing attributes that blocks use. In addition to that, every new top-level attribute like that would require changes in the WP_Block_Type class.

[gaambo]

Ideally, the information about the allowed inner blocks would be stored in attributes in some type of the metadata attribute that holds all the details about the block related to its configuration in the editor, which isn’t concerned with the content or design.

I agree with you. I think a lot of "settings" attributes which are not content-/design-related but more settings for the editor-ui of this specific block instance could be bundled into this. I think there were some discussions about this in some issues/PRs regarding container-block system. I can only find those atm: #41547 #39281 #40318
Not all blocks which have inner blocks will be sections (think: core/list block), but having a general way of storing these per-instance settings may be applicable to this use case as well.

Also related: #48112

[Mamaduka]

I agree with @gziolo. Eventually, we want to move all attributes that serve as per-block settings in the editor into meta or internal attributes.

We can consider a more general solution once the meta/internal attributes API lands into the core.

@mmtr, I believe you're describing a different issue tracked in #14515.

[gaambo]

For what it's worth: I would still like to add this property to the media & text block, since some other core blocks (cover, group) already provide that option. When a general api for meta/internal attributes is implemented they have to be migrated anyway. Just like #49128 for the group block. I can create a PR if that's an option for you?

[Mamaduka]

Sounds good, @gaambo. Feel free to ping me in the PR for testing/review.

[gziolo]

#31387 - Navigation block is another use case discussed.

[gziolo]

It can be considered done with #58262. It got backported to WordPress Core with https://core.trac.wordpress.org/changeset/57521, and it will be released in WordPress 6.5. Kudos to @jsnajdr for championing the efforts.