[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:  flixos90
     Type:  enhancement                          |      Status:  closed
 Priority:  normal                               |   Milestone:  6.7
Component:  Editor                               |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests commit      |     Focuses:
  needs-dev-note                                 |  performance
-------------------------------------------------+-------------------------
Changes (by flixos90):

 * status:  reviewing => closed
 * resolution:   => fixed


Comment:

 In [changeset:"59132" 59132]:
 {{{
 #!CommitTicketReference repository="" revision="59132"
 Editor: Allow registering PHP manifest file for block metadata collections
 for enhanced performance.

 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.
 }}}

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