Do advanced rendering by hooking into render_block for navigation block

[draganescu]

Description

Instead of implementing any api changes, such as passing the whole $block to the render callback, we can hook into the render_block filter and render the block using the entire $block contents, with a callback for said filter.

This tries to avoid the need to change how the render_callback 's work by adding the changes from Trac ticket #48104

How has this been tested?

Created navigation menus and they all seem to render just as good without the shim, using the filter's callback.

[aduth]

Looks pretty straight-forward 👍

[aduth]

I don't know if the convention is codified anywhere, but typically I would expect to see the add_filter to be placed immediately following the callback function (render_block_navigation in this case).

[aduth]

What relevance does this change have in the original goal of using the filter instead of a new argument?

[draganescu]

I am not sure why, but in my local setup while testing, I got a notice of this not being defined. Also I think this check is better than the initial code, if ( $attributes['showSubmenuIcon'] assumes the item exists.

[jorgefilipecosta]

This worked well on my tests in the plugin 👍
Thank you for trying this option right away!

I tried to check if this solution works on the core, but we have another problem in core. The code to copy the PHP file is not included so core does not have navigation block PHP. I will submitt a trac ticket very soon to fix this problem.
I think with that problem fixed plus this PR navigation block should start working as expected.

[jorgefilipecosta]

I submitted a patch to include the navigation block PHP in the core. I tested it with the file being proposed in this PR, and things worked as expected.

[marekhrabe]

This has broken how the render function worked. When it is used through the render_callback, attributes of the block are resolved against the list of its defaults. After this change, only non-default attributes are passed to the function and defaults are omitted entirely. showSubmenuIcon attr is true by default and suddenly stopped rendering because the value is now omitted and thus falsy.

It was fixed here by using empty but it makes me wonder if we are not losing too much by switching how this is called and skipping some core functionality like attr defaulting.

[aduth]

This has broken how the render function worked. When it is used through the render_callback, attributes of the block are resolved against the list of its defaults. After this change, only non-default attributes are passed to the function and defaults are omitted entirely. showSubmenuIcon attr is true by default and suddenly stopped rendering because the value is now omitted and thus falsy.

It was fixed here by using empty but it makes me wonder if we are not losing too much by switching how this is called and skipping some core functionality like attr defaulting.

It's a good point to raise, but I think it's also worth clarifying that with the revisions in this pull request, it wouldn't strictly be correct to call this function a "render callback" anymore. Perhaps it should have been renamed accordingly. It behaves quite similar, true, but the change reflects the fact that it's intent is to bypass render_callback with its own substitute value by filtering render_block.

However, that being said, the underlying issue is that this render_block override had changed the original behavior from core in a way which I was not aware of, nor have I seen any discussion for upstream revision.

Namely, this bit of logic:

https://github.com/WordPress/wordpress-develop/blob/ec83cd0/src/wp-includes/blocks.php#L485-L489

It had been changed from:

	if ( $is_dynamic ) {
		$global_post   = $post;
		$block_content = $block_type->render( $block['attrs'], $block_content );
		$post          = $global_post;
	}

...to:

gutenberg/lib/compat.php

Lines 69 to 76 in 6de983f

	if ( $is_dynamic ) {
	$global_post = $post;
	$prepared_attributes = $block_type->prepare_attributes_for_render( $block['attrs'] );
	$block_content = (string) call_user_func( $block_type->render_callback, $prepared_attributes, $block_content, $block );
	$post = $global_post;
	}

Was there some discussion of this, or a corresponding Trac ticket? I didn't see it mentioned in Trac#48104, though it may have been a further evolution of this override from how it was originally forked from the core implementation.