WordPress 6.7 Introduced a new feature that allows plugins to raise the registration of their blockswp_register_block_metadata_collection()type performance, especially for plugins that register multiple block types.

Extending WordPress Core Behaviors to Plugins

Since WordPress 6.1, WordPress Core has included a mechanism to improve the performance of loading all of the built-in block types: as part of the build process, individualblock.jsonThe file will be parsed as ablocks-json.phpfile, which returns all its data as an array.Significantly improves performance by avoiding the need to perform many expensive filesystem and JSON on each WordPress requestoperation. For background information on the original changes, see the#55005The

However, the way this mechanism is implemented only applies to WordPress Core itself. So far, plugins have not been able to realize the same benefits. Especially for plugins that contain many block types themselves, this effectively means a performance loss. This will change in WordPress 6.7.

Registered Block Metadata Collection

Plugin now optionally registers PHP "list of items" file that contains all the metadata for its block type. For any block type being registered, WordPress Core will now check to see if a manifest file exists that covers that block type, and if it does, it will use the data in the manifest file instead of theblock.jsonRead and parse block type files directly.

In order to use this new feature, plugin developers need to use the newwp_register_block_metadata_collection()function, which takes two arguments:

• $path: The base path where the collection's block files are located.
• $manifest: Path to the manifest file for the collection.

everyoneblock.jsonThe documents that should be part of the collection must all be located in the provided$path, located in its own directory matching the block type name (without the block namespace).

take note of: Registering a collection of block metadata does not replace the need to register individual block types. It is still necessary to call theregister_block_type()mayberegister_block_type_from_metadata(). Use of the new feature is optional to improve performance, but it is highly recommended to use this feature, especially for plugins that register multiple block types.

Automatic generation of block metadata collection lists

Plugin developers are responsible for generating and maintaining the manifest files they register for the plugin's block type metadata collections. In order to simplify this process, the community has made theNPM PackageThe implementation of a newcommandbuild-blocks-manifestThis command was released as part of version 30.3.0.@wordpress/scripts

ought towp-scripts build-blocks-manifestThe command accepts two parameters:

• --input: The directory where the block type is located. The default value is "build".
• --output: The path to the file where the build block metadata collection manifest is stored. Defaults to "build/blocks-manifest.php".

In fact, the parameters of this command are equivalent to the parameters of thewp_register_block_metadata_collection()::--inputParameters are equivalent to parameters$path(math.) genus--outputParameters are equivalent to parameters$manifestThe

Full Example

For this example, suppose you have amy-block-libraryRegistered plugins for 3 block types:

• my-block-library/pricing
• my-block-library/services
• my-block-library/testimonial

The source code for these block types is implemented in the plugin's directorysrc, more specifically in the following catalog:

• src/pricinguse formy-block-library/pricingBlocks.
• src/servicesuse formy-block-library/servicesBlocks.
• src/testimonialuse formy-block-library/testimonialBlocks.

By using existingwp-scripts buildcommand, the code will be built into the plugin'sbuilddirectory, and each block type has the same subdirectory.

After running the build, you can use the newwp-scripts build-blocks-manifestcommand. Since the plugin uses the default location of its block type, there is no need to pass any parameters to the command. Simply run thewp-scripts build-blocks-manifestIt willblock.jsonRead metadata for all three blocks from the catalogbuildand merge them into abuild/blocks-manifest.phpDocumentation.

The manifest file looks like this:

array( /* Block metadata. */ ), 'testimonial' => array( /* Block metadata.
'testimonial' => array( /* Block metadata. */ ), 'testimonial' => array( /* Block metadata. */ )
).

In the future, the same two commands can be used when making changes to the block type and its implementation:

wp-scripts build
wp-scripts build-blocks-manifest

After generating the manifest file, you can now register the block metadata collection, as shown below:

wp_register_block_metadata_collection(
wp_plugin_dir . '/my-block-library/build',
wp_plugin_dir . '/my-block-library/build/blocks-manifest.php'
);

One last important point, don't forget to register the actual block type:

register_block_type_from_metadata( WP_PLUGIN_DIR . '/my-block-library/build/pricing' ).
register_block_type_from_metadata( WP_PLUGIN_DIR . '/my-block-library/build/services' ); register_block_type_from_metadata( WP_PLUGIN_DIR .
register_block_type_from_metadata( WP_PLUGIN_DIR . '/my-block-library/build/testimonial' ); register_block_type_from_metadata( WP_PLUGIN_DIR .

summarize

new featurewp_register_block_metadata_collection()and its tool support@wordpress/scriptsare a powerful combination for improving the performance of plugin registration block types. They make the process easy and simple, so if plugins register block types, consider incorporating this approach into your development workflow and plugin code base.