Typically, when registering a new block type, its metadata is read from the provided `block.json` file. The more block types are registered on a site, the more costly becomes this process, as it involves filesystem reads and parsing JSON.
WordPress Core's built-in blocks have in the past worked around that by having a auto-generated PHP manifest file that includes the already parsed JSON data for all blocks. This changeset effectively allows plugins to do the same, by introducing a new API function `wp_register_block_metadata_collection()`. The WordPress Core block manifest is now handled using this API as well, rather than custom logic baked into `register_block_type_from_metadata()`.
The `wp_register_block_metadata_collection()` function requires 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 block-specific directory matching the block name (without the block namespace). For example, for a collection `$path` of `/wp-content/plugins/test-plugin` and a block `test-plugin/testimonial`, the block file could be `/wp-content/plugins/test-plugins/blocks/testimonial/block.json`.
It is recommended that plugins use the new API function for enhanced performance, especially if they register several block types. However, the use of the function is entirely optional. Not using it will not result in any difference in user-facing behavior.
Props mreishus, flixos90, gziolo, spacedmonkey, azaozz, mukesh27.
Fixes#62002.
Built from https://develop.svn.wordpress.org/trunk@59132
git-svn-id: http://core.svn.wordpress.org/trunk@58528 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Felix Arntz