Size Change: +737 B (+0.04%)

Total Size: 1.96 MB

_{compressed-size-action}

Flaky tests detected in bf9f93c.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18276654962
📝 Reported issues:

• [Flaky Test] Can add submenu item using the keyboard #71966 in /test/e2e/specs/editor/blocks/navigation.spec.js
• [Flaky Test] Can add submenu item(custom-link) using the keyboard #72064 in /test/e2e/specs/editor/blocks/navigation.spec.js
• [Flaky Test] Deleting items #72065 in /test/e2e/specs/editor/blocks/navigation.spec.js
• [Flaky Test] Focus management when creating navigation links #71108 in /test/e2e/specs/editor/blocks/navigation.spec.js
• [Flaky Test] should refresh the page when stylesheet loading fails #71722 in /test/e2e/specs/interactivity/router-styles.spec.ts

Nice progress on this PR 🔥

Nice progress on this PR 🔥

It is almost ready to review. I only need to update the PR description.

Edit: and fix the registration that broke everything 😆

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: cbravobernal <cbravobernal@git.wordpress.org>
Co-authored-by: ockham <bernhard-reiter@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: chriszarate <czarate@git.wordpress.org>
Co-authored-by: sirreal <jonsurrell@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Can you provide a more detailed explanation of the API proposed? In, particular value in some places looks unclear to me. Taking the example included:

registerBlockBindingsSource({
    name: 'my-plugin/custom-source',
    label: 'Custom Source',
    editorUI: {
        mode: 'dropdown',
        data: [
            {
                label: 'Post Title',
                value: 'post_title',
                type: 'string'
            },
            {
                label: 'View Count', 
                value: 42,
                type: 'number'
            }
        ],
        onSelect( { value, updateBlockBindings, attribute } ) {
		updateBlockBindings( {
		    [ attribute ]: {
		       source: 'core/post-meta',
		         args: {
			  key: value,
		         },
		       },
		} );
	},
    }
});

What value represents in onSelect callback? I see in other places value set to an arbitrary number 42, which is unlikely to be a post meta key necessary. It would help to clarify how the post meta key gets passed from the list of options in the dropdown. The value might be confusing to me because it seems to be signaling that it holds the current value for the linked field, which isn't something we want to serialize in the block's saved metadata.

Can you provide a more detailed explanation of the API proposed? In, particular value in some places looks unclear to me. Taking the example included:

registerBlockBindingsSource({
    name: 'my-plugin/custom-source',
    label: 'Custom Source',
    editorUI: {
        mode: 'dropdown',
        data: [
            {
                label: 'Post Title',
                value: 'post_title',
                type: 'string'
            },
            {
                label: 'View Count', 
                value: 42,
                type: 'number'
            }
        ],
        onSelect( { value, updateBlockBindings, attribute } ) {
		updateBlockBindings( {
		    [ attribute ]: {
		       source: 'core/post-meta',
		         args: {
			  key: value,
		         },
		       },
		} );
	},
    }
});

What value represents in onSelect callback? I see in other places value set to an arbitrary number 42, which is unlikely to be a post meta key necessary. It would help to clarify how the post meta key gets passed from the list of options in the dropdown. The value might be confusing to me because it seems to be signaling that it holds the current value for the linked field, which isn't something we want to serialize in the block's saved metadata.

We should also pass the attribute to the modal by the way.

The value is the 'value' from the 'value' key provided in the data, when the source data is selected. I agree that is not the best way to call it, as it may cause some confusions. I'll change it.

Should we pass the entire data element?

@gziolo I updated the code to use 'item' instead of 'value'. item is now contains the entire data object value selected on click.

@gziolo I updated the code to use 'item' instead of 'value'. item is now contains the entire data object value selected on click.

I see the updated core sources now use item.key. The developer has access to other elements for the item, which should be helpful. They will be able to pass and consume as many arguments as they need. In the description, a tiny update in editorUI.data is necessary as key is missing there.

Ping to @chriszarate. Who did a review on a remote branch that I will address. That way we won't miss him on the props commit.

Here's another -- unrelated issue I just found while testing. If I try to edit the value in the "Bindings" panel in the block inspector, it doesn't work. Instead, I'm getting a console error:

It is indeed e2e code only.
[...]
The code is trying to edit "hardcoded" the post id 1 and type post. Let's get it from the context and fix it.

Edit: Fixed in 7095be1

I'm still getting an error, although the message is different now:

I'll look into a fix.

I'm still getting an error, although the message is different now: [...]

Context wasn't being exposed to the source. I've pushed a fix: 372c976

This removes the error. It's still not working for the "Modal Source" and "Complete Source" -- editing the text in the field in the "Bindings" panel doesn't show any effect. But at least the error is gone 😬

(Wondering a bit what's the purpose of that text field in the first place, and if it's used/required by e2e tests if it's not working 🤔)

(Wondering a bit what's the purpose of that text field in the first place, and if it's used/required by e2e tests if it's not working 🤔)

If you remove it, tests break, so yes, seems to be necessary 😆

I'm still getting an error, although the message is different now: [...]

Context wasn't being exposed to the source. I've pushed a fix: 372c976

This removes the error. It's still not working for the "Modal Source" and "Complete Source" -- editing the text in the field in the "Bindings" panel doesn't show any effect. But at least the error is gone 😬

(Wondering a bit what's the purpose of that text field in the first place, and if it's used/required by e2e tests if it's not working 🤔)

Looks like the error I initially saw is also present on trunk. I'll try removing the "Bindings" panel in a follow-up to this PR.

@cbravobernal, how's the dev note for this PR coming along? ☺️

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: Needs Dev Note, [Feature] Block bindings.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

Dev Note: Block Bindings improvements.

For WordPress users.

The Block Bindings user interface has been upgraded to improve how different data sources are displayed in the editor.
Users can now easily switch between sources, as well as bind and unbind attributes with a single click.

For WordPress developers.

On the server

A new filter, block_bindings_supported_attributes_{$block_type}, allows developers to customize which of a block’s attributes can be connected to a Block Bindings source.

On the editor

Developers can now register custom sources in the editor UI by adding a ``getFieldsList property to their source registration function.

This function must return an array of objects with the following properties:

• label (string): Defines the label shown in the dropdown selector. Defaults to the source label if not provided.

• type (string): Defines the attribute value type. It must match the attribute type it binds to; otherwise, it won’t appear in the UI.

  Example: An id attribute that accepts only numbers should only display fields that return numeric values.

• args (object): Defines the source arguments that are applied when a user selects the field from the dropdown.

This is an example that can be tried directly in the console from the Block Editor:

wp.blocks.registerBlockBindingsSource({
	name: 'state-word/haikus',
	label: 'Haikus',
	useContext: [ 'postId', 'postType' ],
	getValues: ( { bindings } ) => {

	        // this getValues assumes you're on a paragraph
		if ( bindings.content?.args?.haiku === 'one' ) {
			return {
				content:
					'Six point nine arrives,\nBlock bindings bloom like spring flowers,\nEditors rejoice.',
			};
		}
		if ( bindings.content?.args?.haiku === 'two' ) {
			return {
				content:
					'New features unfold,\nPatterns dance with dynamic grace,\nWordPress dreams take flight.',
			};
		}
		if ( bindings.content?.args?.haiku === 'three' ) {
			return {
				content:
					"December's gift shines,\nSix nine brings the future near,\nCreators build more.",
			};
		}
		return {
			content: bindings.content,
		};
	},
	
	getFieldsList() {
		return [
			{
				label: 'First Haiku', 
				type: 'string',
				args: {
					haiku: 'one',
				},
			},
			{
				label: 'Second Haiku', 
				type: 'string',
				args: {
					haiku: 'two',
				},
			},
			{
				label: 'Third Haiku', 
				type: 'string',
				args: {
					haiku: 'three',
				},
			},
		];
	},
} );

After executing the code above, when inserting a paragraph, a new UI selector for the Block Binding should be available for the content attribute of the paragraph.

Props: @ockham and @cbravobernal for implementation.

Nice, thanks for the quick turnaround. Feel free to publish on make/core 🙂

@cbravobernal It would be wonderful to also have one or two screenshots with the Dev Note.

With WP 6.9 RC1 already released, please go ahead and publish the Dev Note on make.wordpress.org/core 🙏

Thanks, Carlos! I marked is a fully done ✅