[59132] introduced the `wp_register_block_metadata_collection()` function and underlying `WP_Block_Metadata_Registry` class to allow central registration of a block metadata PHP manifest file in favor of parsing individual JSON files. While this improves performance, it only increases the amount of APIs and code that plugin developers need to use to register their block types properly.
This changeset introduces a new function `wp_register_block_types_from_metadata_collection()` that improves the developer experience of registering block types from a single source, by handling it in only a single function call.
Developers that already use a generated block metadata PHP manifest file (e.g. via the `wp-scripts build-blocks-manifest` tool) can now call `wp_register_block_types_from_metadata_collection()` with that file to automatically register all block types from that block metadata collection. Individual calls to `register_block_type()` or `register_block_type_from_metadata()` are no longer necessary when the new function is used.
Props flixos90, gziolo, joemcgill, mreishus, mukesh27, swissspidy.
Fixes#62267.
See #62002.
Built from https://develop.svn.wordpress.org/trunk@59874
git-svn-id: http://core.svn.wordpress.org/trunk@59216 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset allows for block metadata collections to be registered for almost any source, such as MU plugins, themes, or custom directories with e.g. symlinked plugins or symlinked themes. Prior to the change, block metadata collections could only be registered for plugins and WordPress Core.
There are still safeguards in place to prevent registration of collections in locations that would cause conflicts. For example, it is not possible to register a collection for the entire `wp-content/plugins` directory or the entire `wp-content/themes` directory, since such a collection would conflict with any specific plugin's or theme's collection. In case developers would like to enable this safeguard for their own custom directories, they can use the new `wp_allowed_block_metadata_collection_roots` filter.
Props assassinateur, bowedk, desrosj, dougwollison, flixos90, glynnquelch, gziolo, jorbin, mreishus, swissspidy.
Fixes#62140.
Built from https://develop.svn.wordpress.org/trunk@59730
git-svn-id: http://core.svn.wordpress.org/trunk@59072 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
