Allow wp_register_block_metadata_collection() in themes

[wongjn]

I am aware that block registration is discouraged in themes, but we have a use case where we only use one theme for a site. In this theme, we have several blocks registered, so it would be good for performance to be able to use wp_register_block_metadata_collection() in a theme.

Currently, the underlying function WP_Block_Metadata_Registry::register_collection() checks valid paths for wp-includes and plugins and rejects all others.

[gziolo]

Discussed under the dev note: ​https://make.wordpress.org/core/2024/10/17/new-block-type-registration-apis-to-improve-performance-in-wordpress-6-7/#comment-47247.

Resharing my comment:

It should be perfectly fine to allow registering block type collections from the theme. At some point, we added the support for individual block types to integrate with themes. In practice, it was possible with WP hooks to register block type in themes, so we decided to make the experience smoother while keep recommeding locating block types in plugins.

[louwie17]

This is not only a blocker for themes, but also a blocker for plugins that are symlinked. In WooCommerce we make use of the ABSPATH for registering blocks, which will refer to the official plugin directory instead of the symlinked version.
While it doesn't entirely prevents us from still using it in WooCommerce, it does make testing it more difficult as many of us use symlinks for testing WooCommerce in our local environments.

Here ( ​https://github.com/woocommerce/woocommerce/pull/51184 ) is the initial implementation of using wp_register_block_metadata_collection() in WooCommerce.

[swissspidy]

Looks like we're already tracking this in #62251, so closing as a duplicate.

[wongjn]

Thank you for pointing that out @swissspidy. Could you provide a link to the ticket this is a duplicate of please?

[swissspidy]

Argh, I wrote the wrong ticket number above. It was #62140