[wp-trac] [WordPress Trac] #62002: Extend Block Metadata PHP Cache to Third-Party Blocks

[WordPress Trac]

#62002: Extend Block Metadata PHP Cache to Third-Party Blocks
--------------------------+-----------------------------
 Reporter:  mreishus      |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Editor        |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 == Summary ==

 WordPress 6.1 introduced a performance improvement for core blocks by
 reading block metadata from a single PHP file instead of parsing
 `block.json` files on each request. This change proposes extending this
 optimization to third-party blocks, allowing them to register their block
 metadata in a centralized location and benefit from the same performance
 improvements.

 == Description ==

 In WordPress 6.1, the core team implemented a performance enhancement for
 core blocks by compiling block metadata into a single PHP file (`wp-
 includes/blocks/blocks-json.php`) to avoid parsing multiple `block.json`
 files on each request. This change notably improved the block registration
 process's performance, as detailed in the
 [https://make.wordpress.org/core/2022/10/07/improved-php-performance-for-
 core-blocks-registration/ developer note].

 However, this optimization is currently only available for core blocks.
 Third-party blocks, especially those from large plugins with numerous
 blocks (for example, Jetpack or WooCommerce), could also benefit from this
 performance improvement.

 This proposal introduces a new class, `WP_Block_Metadata_Registry`, which
 allows core and third-party plugins to register their block metadata in a
 centralized location. The `register_block_type_from_metadata` function is
 modified to accept an optional `$metadata_source` argument, which is a
 string in the format `namespace/source`. If this argument is provided, the
 function will attempt to retrieve the block's metadata from the registry
 before falling back to reading from the `block.json` file, maintaining
 backward compatibility with the current behavior.

 Key points:

 - Introduce a new function, `wp_register_block_metadata`, for core and
 third-party plugins to register their block metadata.
 - Modify `register_block_type_from_metadata` to accept an optional
 `$metadata_source` argument to retrieve metadata from the registry.
 - Fall back to reading from the `block.json` file if metadata is not found
 in the registry, ensuring backward compatibility.

 By extending the block metadata PHP cache to third-party blocks, we can
 provide a notable performance benefit to sites using large block
 libraries, like those from WooCommerce and Jetpack. This change also
 encourages plugin developers to optimize their block registration process,
 leading to better overall performance for WordPress sites.

 The implementation is based on the original optimization for core blocks
 introduced in WordPress 6.1, as described in the
 [https://make.wordpress.org/core/2022/10/07/improved-php-performance-for-
 core-blocks-registration/ developer note].

 == Related Tickets ==

 #55005: Improve PHP performance for block.json files. This ticket is where
 the idea originally came from.
 [https://core.trac.wordpress.org/changeset/54276 changeset 54276]: Editor:
 Improve block loading PHP performance. This commit implemented the
 original $core_blocks_meta for core only.

 == Alternative Approach Considered ==

 An alternative approach was considered that didn't require making core
 changes. It involved modifying a third-party plugin to keep its own
 compiled block file and use that to generate `$args` to pass to
 `register_block_type_from_metadata()`, taking advantage of the change
 introduced in [https://core.trac.wordpress.org/changeset/57026 changeset
 57026].

 However, this approach had some drawbacks:

 When registering blocks through the `$args` function without passing a
 path to a block.json file, attempting to register blocks with styles did
 not work. This is because the linking is done to the style from looking at
 `$metadata['name']`, but when registering via `$args`, the block name is
 not present in `$metadata`. It only exists in `$args`/`$settings` at this
 point. This issue has been reported in a new bug: #61910.

 The need for additional processing from the `block.json` file, which needs
 to be kept in sync with core. For example, the field named `apiVersion` in
 the block.json file needs to be transformed to `api_version` before
 passing through to `$args`. While this isn't too problematic, it's
 concerning that if core changes the fields, this extra processing from the
 third-party plugin will have to be kept in sync with core's list of
 fields.

 In contrast, the mechanism developed in changeset 54276, which works for
 core only, does not require this processing, making it ideal. The build
 script only needs to be '<?php return ' + json2php( blocks ) + ';'.

 == Patch ==

 The proposed patch includes:
 - Introduction of the `WP_Block_Metadata_Registry` class to manage block
 metadata from various sources.
 - Addition of the `wp_register_block_metadata` function for registering
 block metadata.
 - Modifications to `register_block_type_from_metadata` to use the metadata
 registry and accept an optional `$metadata_source` argument.
 - Additional unit tests to cover the new functionality.

 See the attached patch for the complete implementation.

 == Backward Compatibility ==

 The proposed change is designed to be backward compatible with existing
 third-party blocks. If a block's metadata is not found in the registry, or
 the `$metadata_source` argument is not provided,
 `register_block_type_from_metadata` will fall back to reading from the
 `block.json` file, preserving the current behavior.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62002>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform