Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 7 months ago

#61642 closed defect (bug) (fixed)

Block Bindings: Add context needed by sources during its processing

Reported by: santosguillamot Owned by: gziolo
Priority: normal Milestone: 6.7
Component: Editor Version: 6.6
Severity: normal Keywords: has-patch has-unit-tests commit
Cc: Focuses:

Description

Block bindings sources sometimes need to access some context that is not initially available in the block. Right now, we are extending it when the source is registered. The idea is to move the logic so it is added when the block bindings are processed. This means:

  • Before: Extend context during block bindings source registration. This implies that the blocks extend the context even when they don't use bindings.
  • After: Extend context during block bindings processing. This implies that the context is extended ONLY for the blocks where bindings are defined.

Change History (12)

This ticket was mentioned in PR #6456 on WordPress/wordpress-develop by @santosguillamot.


2 years ago
#1

  • Keywords has-unit-tests added

Trac ticket: https://core.trac.wordpress.org/ticket/61642

## What?
Block bindings sources sometimes need to access some context that is not initially available in the block. Right now, we are extending it when the source is registered. This pull request moves the logic so it is added when the block bindings are processed. This means:

  • Before: Extend context during block bindings source registration. This implies that the blocks extend the context even when they don't use bindings.
  • After: Extend context during block bindings processing. This implies that the context is extended ONLY for the blocks where bindings are defined.

## How?
Instead of using the get_block_type_uses_context created back then for this use case, use the available_context in the block class during bindings processing.

I assume it is not possible to remove that filter because of backward-compatibility.

### Testing instructions

  1. Register a custom field in your site to test it. You can use a code snippet like this:
    register_meta(
    	'post',
    	'url_custom_field',
    	array(
    		'show_in_rest' => true,
    		'single'       => true,
    		'type'         => 'string',
    		'default'	   => 'https://wpmovies.dev/wp-content/uploads/2023/04/goncharov-poster-original-1-682x1024.jpeg',
    	)
    );
    
  1. Go to a page and insert an image block.
  2. Go to the Code editor and connect the image to the custom field by adding the metadata bindings property. It should look something like this:
    <figure class="wp-block-image size-large">[[Image(https://wpmovies.dev/wp-content/uploads/2023/04/goncharov-poster-original-1-682x1024.jpeg)]]</figure>
    
    
  3. Save the page and check that in the frontend, the URL defined in the custom field is used.
  4. Repeat the process for paragraph, heading, and button blocks.

#2 @gziolo
2 years ago

  • Component GeneralEditor
  • Keywords commit added
  • Milestone Awaiting Review6.7
  • Owner set to gziolo
  • Status newassigned

This patch is ready to go. It is compatible with Block Binding sources registered in the core. I'm not entirely sure whether it will work with all custom sources registered by 3rd party code if they define uses_context without the related changes that were applied in the Gutenberg plugin. Should we wait until the WordPress packages get synced to WordPress core?

#3 @santosguillamot
2 years ago

Should we wait until the WordPress packages get synced to WordPress core?

Yes, I think you are right, and it requires the code added to the editor to bootstrap the sources defined in the server. The server rendering will work as expected, but not the editor. I am not sure how the process of syncing with WordPress packages works.

#4 @gziolo
2 years ago

@noisysocks, when do you plan to run the first sync of WordPress packages in the 6.7 release cycle?

@gziolo commented on PR #6456:


2 years ago
#5

@peterwilsoncc opened https://github.com/WordPress/wordpress-develop/pull/7226 where he started the process of syncing WordPress packages to WordPress core for the WP 6.7 release. Once that lands, this PR needs to be rebased as it already reports some merge conflicts and it will be ready to commit.

@cbravobernal commented on PR #6456:


2 years ago
#6

@peterwilsoncc opened #7226 where he started the process of syncing WordPress packages to WordPress core for the WP 6.7 release. Once that lands, this PR needs to be rebased as it already reports some merge conflicts and it will be ready to commit.

Happy to rebase, review and test it once is ready.

@gziolo commented on PR #6456:


2 years ago
#7

It’s time to rebase this branch and commit changes 🚀

@santosguillamot commented on PR #6456:


2 years ago
#8

Rebased done 🙂 Let's see if tests pass, but I believe this should be ready.

@santosguillamot commented on PR #6456:


2 years ago
#9

I've been manually testing it and it looks good. If I connect an image to a custom field it shows the connected value in both the editor and in the frontend (server processing).

#10 @gziolo
2 years ago

  • Resolutionfixed
  • Status assignedclosed

In 59080:

Block Bindings: Adds context needed by sources during its processing

Extends block context during block bindings processing. This implies that the context is extended ONLY for the blocks where bindings are defined and only when rendered on the page.

Props santosguillamot, gziolo, artemiosans, cbravobernal.
Fixes #61642.

#12 @westonruter
7 months ago

In 61642:

Code Quality: Remove unused WP_Block_Bindings_Registry::$supported_blocks private member variable.

Developed in https://github.com/WordPress/wordpress-develop/pull/10912

Follow-up to [59080], [57641].

Props soean.
See #64238, #61642.
Fixes #64633.

Note: See TracTickets for help on using tickets.