[wp-trac] [WordPress Trac] #61280: Block Variations: Allow server-side registration via variations.php (was: Block Variations: Allow server-side registration via variations.php or .json)

[WordPress Trac]

#61280: Block Variations: Allow server-side registration via variations.php
-----------------------------+---------------------
 Reporter:  Bernhard Reiter  |       Owner:  (none)
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  6.6
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:
-----------------------------+---------------------
Description changed by Bernhard Reiter:

Old description:

> As of WordPress 6.5, the [https://make.wordpress.org/core/2024/02/29
> /performance-improvements-for-registering-block-variations-with-
> callbacks/ recommended way to register Block Variations for a given
> block] is via its `variations_callback`:
>
> {{{
> register_block_type_from_metadata(
>     __DIR__ . '/template-part',
>     array(
>         'render_callback'    => 'render_block_core_template_part',
>         'variation_callback' => 'build_template_part_block_variations',
>     )
> );
> }}}
>
> As the above example shows, this is somewhat similar to adding a
> `render_callback` for a dynamic block. The latter can alternatively be
> provided via a single PHP file -- typically called `render.php` -- that
> is [https://make.wordpress.org/core/2022/10/12/block-api-changes-in-
> wordpress-6-1/ specified via the `render` field in `block.json`].
>
> === `variations.php`
>
> For developer experience, it would thus be beneficial to add a
> `variations` field to `block.json` that can be set to point to a PHP file
> that registers all known variations of that block.
>
> === `variations.json`
>
> As a potential stretch goal, it might be possible to point it to a JSON
> file instead, as some variations are statically defined (and don't need
> to run any PHP code). In those cases, they are currently often defined on
> the client side (see e.g.
> [https://github.com/WordPress/gutenberg/blob/f49e0b5958adad9fbd211d5ded07b4cabf5bfec3/packages
> /block-library/src/social-link/variations.js Social Icon block
> variations]).
>
> As we're working to expand Block Variations to be better integrated and
> supported on the server side (e.g. [https://github.com/WordPress
> /wordpress-develop/pull/6602 automatic class name generation for block
> variations]), they will need to be registered there to fully benefit from
> those new, server-side, features. Allowing a JSON format will enable
> block authors to migrate existing ("static") JS files that they use for
> variation registration more easily.

New description:

 As of WordPress 6.5, the [https://make.wordpress.org/core/2024/02/29
 /performance-improvements-for-registering-block-variations-with-callbacks/
 recommended way to register Block Variations for a given block] is via its
 `variations_callback`:

 {{{
 register_block_type_from_metadata(
     __DIR__ . '/template-part',
     array(
         'render_callback'    => 'render_block_core_template_part',
         'variation_callback' => 'build_template_part_block_variations',
     )
 );
 }}}

 As the above example shows, this is somewhat similar to adding a
 `render_callback` for a dynamic block. The latter can alternatively be
 provided via a single PHP file -- typically called `render.php` -- that is
 [https://make.wordpress.org/core/2022/10/12/block-api-changes-in-
 wordpress-6-1/ specified via the `render` field in `block.json`].

 === `variations.php`

 For developer experience, it would thus be beneficial to allow specifying
 the name of a PHP file in `block.json` that contains code to generate all
 known variations of that block.

 Unlike [54132], we cannot simply introduce a `variations` field to hold
 that filename, as the `variations` field already exist; it holds the list
 of block variations. We can however allow `variations` to accept a string,
 which will we can then interpret as the aforementioned filename.

 === `variations.json`

 As a potential follow-up, it might be possible to point the `variations`
 field to a JSON file instead, as some variations are statically defined
 (and don't need to run any PHP code). In those cases, they are currently
 often defined on the client side (see e.g.
 [https://github.com/WordPress/gutenberg/blob/f49e0b5958adad9fbd211d5ded07b4cabf5bfec3/packages
 /block-library/src/social-link/variations.js Social Icon block
 variations]).

 As we're working to expand Block Variations to be better integrated and
 supported on the server side (e.g. [https://github.com/WordPress
 /wordpress-develop/pull/6602 automatic class name generation for block
 variations]), they will need to be registered there to fully benefit from
 those new, server-side, features. Allowing a JSON format will enable block
 authors to migrate existing ("static") JS files that they use for
 variation registration more easily.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61280#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform