Add support for template part areas in block variations

[ndiego]

What problem does this address?

As of WordPress 6.2 and Gutenberg 15.5, you can define block variations for core/template-part but there is no way to add variations to a specific area, for example, core/template-part/header. Interestingly enough, you can target areas with semantic patterns.

For example, the following code will define a pattern specifically for header template parts via the blockTypes property.

register_block_pattern(
    'example-theme/semantic-pattern',
    array(
        'title'      => __( 'A semantic pattern for header template parts.', 'example-theme' ),
        'blockTypes' => array( 'core/template-part/header' ),
        'content'    => '<!-- Insert Pattern Content -->',
    )
);

This issue was reported in the WordPress.org Gutenberg support forum.

What is your proposed solution?

Ideally, registering a block variation for core/template-part/header would only add the variation to template parts assigned to that area (header).

[talldan]

I didn't quite follow at first, so I'll explain my understanding. Sorry if it's obvious.

I think the issue is that variations have no way to control whether they're listed. The OP wants to register a transform that will only appear on template parts with the 'header' area.

Ideally, registering a block variation for core/template-part/header would only add the variation to template parts assigned to that area (header).

'core/template-part/header' is a variation itself (areas are added as variations of the template part block), so it might be complicated to have a variation that targets another variation.

Being able to add an isVisible (or isMatch to mirror the transform API) function to a variation might be a different solution. Using the example from the forum:

wp.blocks.registerBlockVariation('core/template-part', [
    {
        name: 'sticky-header',
        title: __('Sticky Header'),
        attributes: {
            area: 'header',
            className: 'site-header is-sticky',
        },
        scope: ['transform'],
        isVisible( { scope, block } ) {
                     // The scope needs to be checked, because a variation can also support an 'inserter' and 'block' scope.
            return scope === 'transform' && block.attributes.area === 'header';
        }
    },

It'd only really be useful for a block that has a scope of transform though.

I think @ntsekouras has worked on variations a lot, so might have some ideas.

[ntsekouras]

This use case for me is a better fit for the styles API. Besides the fact that the shared examples in the trac ticket could be more generic styles('is-static', etc..) and therefore not need to target specific variations, it might be worth exploring adding styles(registerBlockStyle) for block variations and augment that API, to also check for an active block variation.. This would be similar to pattern handling. --cc @gziolo