Block variations: Add class name

[ockham]

For a given block my/block with a variation myvariation that's registered on the server side (via variation_callback or get_block_type_variations), add a class wp-block-my-block-myvariation to the block wrapper.

Design choices

This PR introduces a new function called get_active_block_variation(), which is modelled after its client-side counterpart, getActiveBlockVariation(). The signatures are almost identical, the major differences being:

• The client-side version accepts a block type name, whereas the server side one expects a WP_Block_Type object. Some discussion on that here.
• The client-side version accepts an additional scope argument, which is forwarded to getBlockVariations(). It is used to specify if a variation should show up in the inserter, in transforms, or if it should only be used internally by the block. Since the server-side's counterpart WP_Block_Type::get_variations() doesn't support a scope argument, it is also not implemented in get_active_block_variation(). (It should be possible to add it later on to both functions if we so wish.)

No separate block-supports. This doesn't introduce a separate block-supports field to control the addition of a generated variation class name; instead, it relies on the existing className block-supports, as does the block's generated class name (i.e. the wp-block-my-block thing). The reason for this is that the addition of an extra class name was considered innocuous and similar enough to the generated block class name that it didn't merit introducing a separate block-supports, which would otherwise increase the API surface.

~Inference. Note that while get_active_block_variation respects the isActive field to determine the variation of a block given its attributes, it also has a fallback mechanism, which is to compare the variation's set of defining attributes to the block's.~

~I believe that this is a reasonable technique to determine a block variation, especially in the absence of an isActive field (which on the server side is furthermore limited to an array of attributes that need to be considered in determining a variation, as opposed to the client side, where arbitrary callbacks are allowed for isActive).~

~If we agree with this fallback mechanism, I'm inclined to add it to the client side's getActiveBlockVariation as well.~

Edit: Removed the fallback mechanism, see https://github.com/WordPress/wordpress-develop/pull/6602/files#r1616104632.

TODO

• [ ] Carry over refinements to how the active block is determined if isActive is an array of attribute names. See
  • [ ] https://github.com/WordPress/gutenberg/pull/62088
  • [ ] https://github.com/WordPress/gutenberg/pull/62031
  • [ ] https://github.com/WordPress/gutenberg/pull/62272
  • [ ] https://github.com/WordPress/gutenberg/pull/62325
• [ ] Add unit test coverage for the above. Ideally, find a way to reuse test data from client-side getActiveBlockVariation unit tests.

Testing Instructions

Test with a Block Theme (such as TT4) that uses Template Part block (and ideally also Navigation Link blocks), as those are among the few blocks with server-side registered variations. Inspect the page source and verify that the aforementioned blocks have indeed a variation-specific classname added, e.g. wp-block-template-part-area_footer or wp-block-navigation-link-page.

Screenshots

---

Trac ticket: https://core.trac.wordpress.org/ticket/61265

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[tjcafferkey]

I'm assuming we're going to need to open a GB counterpart to deal with the same logic for adding variation class names in the editor too?

[github-actions[bot]]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance, it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[ockham]

I'm assuming we're going to need to open a GB counterpart to deal with the same logic for adding variation class names in the editor too?

Oh, good point! I was originally just focused on dynamic blocks, but you're right, we'll probably need something somewhere around addGeneratedClassName and/or getBlockDefaultClassName.

[ockham]

I'm assuming we're going to need to open a GB counterpart to deal with the same logic for adding variation class names in the editor too?

Oh, good point! I was originally just focused on dynamic blocks, but you're right, we'll probably need something somewhere around addGeneratedClassName and/or getBlockDefaultClassName.

@tjcafferkey Mind giving that a stab? 😄

[tjcafferkey]

Mind giving that a stab? 😄

I'd love to!

[github-actions[bot]]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props bernhard-reiter, tomjcafferkey, ntsekouras, gziolo.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions[bot]]

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 59964 GitHub commit: https://github.com/WordPress/wordpress-develop/commit/07e3b258b5f111f2d3d5d093f929bbd040ac19b9

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.

[gziolo]

It looks like https://github.com/WordPress/wordpress-develop/commit/07e3b258b5f111f2d3d5d093f929bbd040ac19b9 referenced a wrong ticket.