| 7 | | When `register_block_type_from_metadata()` runs, we check if there's a block metadata collection that encompasses that given file location. For example, if I have a block file `wp-content/plugins/my-plugin/blocks/test/block.json`, a collection with `wp-content/plugins/my-plugin` would match that (good), but so would a collection with `wp-content/plugins` (bad). We wouldn't want to allow someone to tamper with how other plugins' blocks are registered, it could be used to override the block configuration data by other plugins. |
| | 7 | When `register_block_type_from_metadata()` runs, we check if there's a block metadata collection that encompasses that given file location. For example, if I have a block file `wp-content/plugins/my-plugin/blocks/test/block.json`, a collection with `wp-content/plugins/my-plugin` would match that (good), but so would a collection with `wp-content/plugins` (bad). We wouldn't want to allow someone to tamper with how other plugins' blocks are registered, it could be used to override the block configuration data by other plugins. That might make sense for a project you manage, but it would open up lots of doors for malicious intent to any plugin modifying another plugin's behavior. The risk is greater than the reward for this. Other than that, it's also a bit wasteful for performance because ''every'' plugin's blocks would also match that overall `wp-content/plugins` block metadata collection. |