[wp-trac] [WordPress Trac] #62140: Consider allowing themes to register block metadata collections

[WordPress Trac]

#62140: Consider allowing themes to register block metadata collections
--------------------------+---------------------
 Reporter:  flixos90      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  6.7.1
Component:  Editor        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------

Comment (by dougwollison):

 Replying to [comment:4 flixos90]:
 > The reason those conditions exist has nothing to do with allowlisting in
 the first place. They exist because we need to prevent certain directories
 from being used, for example it needs to be impossible to register e.g.
 the root plugins or root themes directory as a block collection, since
 then all block types from all other plugins would be considered part of
 such a collection. So that part of the behavior needs to be maintained no
 matter what we allowlist. Another example would be if someone tried to
 register the parent directory of the entire WordPress site, that would be
 a problem so it needs to be prevented.

 Wait, how is that so disasterous? I'm looking at the source again and I'm
 confused.

 From what I can tell, registering a collection simply enables skipping the
 block.json file reading in `register_block_type_from_metadata()`. If a
 match isn't found though, it still reads the specified JSON file anyway,
 which has no restrictions on where it's trying to read from. There are no
 glob or recursive scans used to find block files, so registering a root
 directory doesn't seem like it'd do much damage.

 I haven't literally tried it, but if I actually tried registering the root
 folder as a collection:

 {{{#!php
 <?php
 wp_register_block_metadata_collection( ABSPATH, 'my-manifest.php' );
 }}}

 It looks like the absolute worst it could do is:
 - Nullify the performance improvement provided by the metadata registry by
 forcing `register_block_type_from_metadata()` to just read the json files
 as before, and/or,
 - Allow my manifest file to specify overrides for blocks from core or
 other plugins, and really slopily at that. If I wanted to mess with that
 stuff it'd be simpler to hook into `block_type_metadata` or
 `block_type_metadata_settings`.

 If we're already on the same page that themes and mu-plugins should be
 included in the checks, fine, but I'm thrown off by this argument as it
 doesn't track with my current understanding of how this all works.

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