Add a filter for the reusable block id

[brucepearson]

Description

Add a filter so that plugins and themes can filter the reusable block id and return a different block.

Why is this needed.

Plugins may want to display a different reusable block in some situations. Eg. WPML allows you to translate the reusable block. When rendering the page that contains the reusable block WPML can detect the current language and select the appropriate reusable block to display.

How has this been tested?

This has been tested with WPML using the follow code example.

add_filter( 'gutenberg_reusable_block_id', 'gutenberg_reusable_block_id_filter' );
function gutenberg_reusable_block_id_filter( $block_id ) {
   return icl_object_id( $block_id, 'wp_block', true );
}

Types of changes

Add a new filter

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[gziolo]

I noticed that this proposal doesn’t contain any documentation - both inline and general guidelines in the handbook how to use this hook.

[noisysocks]

Cool suggestion—I think it makes sense.

I'm wondering though if we should make this more general-purpose by passing the filter the $ref and having it return the HTML that should be rendered.

I noticed that this proposal doesn’t contain any documentation - both inline and general guidelines in the handbook how to use this hook.

Yes, we'll need to document this.

[brucepearson]

@noisysocks I've added inline documentation for the filter. I couldn't find where Gutenberg hooks are documented in the handbook.

[brucepearson]

@gziolo We're waiting for this to improve compatibility with Gutenberg. Can this be included?

[gziolo]

Sorry, I missed that! Yes, we can include it. Actually it might be very useful.

Let’s add some docs with ESNext/ES5 examples about the filter in this document:
https://github.com/WordPress/gutenberg/blob/master/docs/extensibility/extending-blocks.md.

I also agree with the suggestion from @noisysocks that it would be neat to include the html as a param in the filter for some more advanced use cases.

[gziolo]

@pento @mcsf what’s the process for PHP changes now when 5.0 beta process starts?

[pento]

PHP in the block-library will continue to be maintained in Gutenberg, as changes are usually closely tied to JS changes, too. Updates land in core by updating the version in core's package.json, running npm install, then npm webpack:dev.

[andreasciamanna]

Hi there.

Is there any change this PR will get merged and included in WP 5.0?

[pento]

I'm fine with this going in, let's just change the filter name, as it'll be going straight into Core.

[pento]

Let's call the filter reusable_block_id, we don't need to use the gutenberg_ prefix anymore.

[andreasciamanna]

Done

[pento]

It'd be useful if this filter also had the post ID that the reusable block is being embedding in.

[andreasciamanna]

@pento

It'd be useful if this filter also had the post ID that the reusable block is being embedding in.

Done.

I wasn't sure if I should have used global $post or, as I did here, get_post().
They should both achieve the same result, but I've used the latter more for readability purposes.

[gziolo]

It looks like a more general solution proposed in #11730 could work here, too. The only change that would need to be applied is that the other proposed filter would have to take $post_id as one of the params.

[gziolo]

Closing in favor of https://core.trac.wordpress.org/ticket/45451. Thank you for opening this PR. It looks like there is ongoing discussion about enabling such capability in WordPress core.

[gziolo]

Patch has landed in trunk:
https://core.trac.wordpress.org/changeset/44553

It should be released next month in WordPress 5.1.