gutenberg
gutenberg copied to clipboard
Blocks: Add support for block name aliases for variations
What problem does this address?
Part of Block API roadmap #41236.
Let's explore whether some block variations can be read as a block type. For example, instead of core/template-part/header
be able to just have core/header
to still get resolved by the template part functions. We used to have a similar granular naming schema for Embed and Social Link blocks before we converted them to block variations:
https://github.com/WordPress/gutenberg/blob/bdb6a41099529541ce1f35d05037fef066674150/packages/blocks/src/api/parser/convert-legacy-block.js#L23-L29
https://github.com/WordPress/gutenberg/blob/bdb6a41099529541ce1f35d05037fef066674150/packages/blocks/src/api/parser/convert-legacy-block.js#L31-L50
Benefits of using aliases
- Aliased block names would get converted into unique class names assigned to block variations, giving more options to style their sites.
- Manipulate in
theme.json
granularly (like attach custom CSS that only is used when the block is used, etc.). - Aliases used would give easier access for site owners to the content analysis of which blocks and variations are used in posts and templates.
- Benefit from all the block API tools in existence (like
multiple
block support).
What is your proposed solution?
Add handling for block type name aliases used with block variations. They should fall back if necessary to the original block type name, e.g. woocommerce/product-list
that can get resolved to the product-list
variation added to the core/query
block.
Some examples to consider:
<!-- wp:template-part {"slug":"header","theme":"twentytwenty"} /-->
<!-- wp:meta { "name": "mykey", "type": "heading" } /-->
becomes
<!-- wp:template-part/header {"theme":"twentytwenty"} /-->
<!-- wp:meta/mykey { "type": "heading" } /-->
This could also remove the need for complex logic used with block variations when detecting the variation based on the result of the isActive
callback executed.