WordPress 6.7 introduces a new function wp_register_block_metadata_collection() which allows plugins to improve the performance of registering their blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. types, especially for plugins that register multiple block types.

Expanding WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. behavior to plugins

Since WordPress 6.1, WordPress Core has included a mechanism to improve performance for loading all of the built-in block types: As part of the build process, the individual block.json files are being parsed into a single blocks-json.php file that returns all of their data in an array. This notably enhances performance by avoiding many costly filesystem and JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. operations on every single WordPress request. See #55005 and its dev note for context on the original change.

The way this mechanism was implemented only worked for WordPress Core itself though. Plugins so far have not been able to achieve the same benefits. Especially for plugins that include many block types themselves, this effectively meant a performance penalty. This is going to change as part of WordPress 6.7.

Registering block metadata collections

Plugins can now optionally register a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher “manifest” file, which includes all the metadata for their block types. For any block type that is being registered, WordPress Core will now check whether such a manifest file is present covering the block type, and if so, it will use the data from the manifest file instead of reading and parsing the block type’s block.json file directly.

In order to use this new capability, pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developers need to use the new wp_register_block_metadata_collection() function, which takes two parameters:

• $path: The base path in which block files for the collection reside.
• $manifest: The path to the manifest file for the collection.

Every block.json file that is supposed to be part of the collection must reside within the provided $path, within its own directory matching the block type name (without the block namespace). Please see the full example for further clarification.

Note that registering block metadata collections does not replace the need to register individual block types at this point. You will still need to call register_block_type() or register_block_type_from_metadata() for every block type that is part of a collection. Usage of the new function is optional to help performance, but it is strongly recommended particularly for plugins that register several block types. Please continue reading for additional tooling to facilitate this process.

Automatically generating a block metadata collection manifest

Plugin developers are responsible for generating and maintaining the manifest file they register for their plugin’s block types metadata collection. To make this process simple, a new command build-blocks-manifest has been implemented as part of the @wordpress/scripts NPM package, released as part of version 30.3.0.

The wp-scripts build-blocks-manifest command accepts two arguments:

• --input: The directory in which the block types reside. The default for this is “build”.
• --output: The file path for where to store the built block metadata collection manifest. The default for this is “build/blocks-manifest.php”.

Effectively, the arguments for this command are equivalent to the parameters for wp_register_block_metadata_collection(): The --input argument is the equivalent of the $path parameter, and the --output argument is the equivalent of the $manifest parameter.

Full example

For this example, let’s say you have a plugin my-block-library that registers 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 src directory, more specifically in directories as follows:

• src/pricing for the my-block-library/pricing block.
• src/services for the my-block-library/services block.
• src/testimonial for the my-block-library/testimonial block.

By using the existing wp-scripts build command, the code gets built into the plugin’s build directory, with the same subdirectories for each block type.

After running the build, you can use the new wp-scripts build-blocks-manifest command. Since the plugin is using the default location for its block types, you don’t need to pass any arguments to the command. Simply run wp-scripts build-blocks-manifest, and it will read the block.json metadata for all three blocks from the build directory and combine them into a build/blocks-manifest.php file.

The manifest file will look something like this:

<?php
// This file is generated. Do not modify it manually.
return array(
	'pricing' => array( /* Block metadata. */ ),
	'services' => array( /* Block metadata. */ ),
	'testimonial' => array( /* Block metadata. */ )
);

You can use the same two commands in the future, whenever you have made changes to the block types and their implementation:

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

With the manifest file generated, you can now register the block metadata collection as follows:

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

Last but not least, don’t forget to register the actual block types:

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 . '/my-block-library/build/testimonial' );

And that’s already it, you have everything in place for improved performance of the plugin’s block types registration.

Summary and further reading

The new wp_register_block_metadata_collection() and its tooling support in @wordpress/scripts are a powerful combination to improve performance of register block types from your plugin. They make the process almost effortless, so if your plugin registers block types, please consider incorporating this approach into your development workflow and plugin codebase.

Please see the following links for further reading:

• TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #62002 for implementing the wp_register_block_metadata_collection() function.
• GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ pull request #65866 for implementing the wp-scripts build-blocks-manifest command.

Props @gziolo and @mreishus for review and proofreading.

#6-7, #dev-notes, #dev-notes-6-7