Gallery Block: Use wp_enqueue_block_support_styles() if possible

[ockham]

What?

In the Gallery Block, use wp_enqueue_block_support_styles() if it's available, and if it supports the $priority arg.

Why?

To enable us to use the two-argument version of wp_enqueue_block_support_styles() (currently being backported to Core here), and eventually remove the gutenberg_enqueue_block_support_styles() shim.

How?

By checking if the function exists, and if it supports two arguments.

Testing Instructions

Verify that the Gallery block still works.

[ockham]

An alternative would be

Suggested change

	if (
	function_exists( 'wp_enqueue_block_support_styles' ) &&
	2 === count( ( new ReflectionFunction( 'wp_enqueue_block_support_styles' ) )->getParameters() )
	) {
	if ( version_compare( get_bloginfo( 'version' ), '6.1', '>=' ) ) {

but I find that less semantic. It also is less accurate, e.g. during the 6.1 alpha phase (now): It would evaluate to false even once WordPress/wordpress-develop#3158 is merged (and used in a local install).

[ramonjd]

I've tested this classic and block themes. Editor and frontend match and the CSS is loading as expected. Thank you! 👍

It seems like a clever approach.

I was just curious to know why we couldn't leave gutenberg_enqueue_block_support_styles working as it is and remove it later once migration has occurred, or the minimum version is 6.1?

[michalczaplinski]

I was just curious to know why we couldn't leave gutenberg_enqueue_block_support_styles working as it is and remove it later once migration has occurred, or the minimum version is 6.1?

I don't have an answer but would also like to understand this. FYI, It was mentioned by @gziolo in #43440 (comment) that we should:

refactor ocurrences of gutenberg_enqueue_block_support_styles in core blocks in the Gutenberg plugin

[ockham]

Thanks, folks!

I was just curious to know why we couldn't leave gutenberg_enqueue_block_support_styles working as it is and remove it later once migration has occurred, or the minimum version is 6.1?

Aside from what Michal mentioned, I think the reason is that we don't want to have any gutenberg_ prefixed functions in Core -- which includes dynamic blocks' index.php files that are backported to Core. (And while we cannot entirely avoid the gutenberg_ prefixed function call being present in Core, we can at least ensure that it will never be called from there.)

[gziolo]

It isn't the most elegant solution to run this type of check that exists only because of the limitation of the Gutenberg plugin. You can also use Webpack to rewrite PHP files during the build to use the function that patches older versions of WordPress, similar to what we have here:

gutenberg/tools/webpack/blocks.js

Lines 25 to 30 in 0a51142

	/**
	* We need to automatically rename some functions when they are called inside block files,
	* but have been declared elsewhere. This way we can call Gutenberg override functions, but
	* the block will still call the core function when updates are back ported.
	*/
	const prefixFunctions = [ 'build_query_vars_from_query_block' ];

[ockham]

Thanks @gziolo -- and TIL! That sounds like a good fit. I'll revert and will file an alternative PR.

We might need to tweak the Webpack logic a bit though to replace the wp_ prefix in wp_enqueue_block_support_styles with gutenberg_, since we might not want both, i.e. gutenberg_wp_enqueue_block_support_styles 🤔

[gziolo]

We might need to tweak the Webpack logic a bit though to replace the wp_ prefix in wp_enqueue_block_support_styles with gutenberg_, since we might not want both, i.e. gutenberg_wp_enqueue_block_support_styles 🤔

It's nice to have, but I wouldn't make it too easy so it becomes too tempting to use everywhere.