Connect block attributes with custom fields via UI #176

cbravobernal · 2025-06-12T20:53:51Z

What

⚠️ It needs to be loaded as a beta feature in their respective admin panel.
⚠️ Pattern overrides cannot be set up connected to fields. They are still not compatible on Core.
⚠️ There is some duplication both in code and UI with Core.

The PR allows to connect block attributes with custom fields via UI. Is still experimental, as I have not yet tested with any field type that can be created. In a future PR we can add an advanced view, using DataViews.

The image block will only search for image type fields, and all their attributes can be bound at once, just selecting the image field.

The paragraph, heading, and button blocks will only work with an initial set of items set in this variable:

const BLOCK_BINDINGS_RELATED_FIELD_TYPES = {
	'core/paragraph': {
		content: [ 'text', 'textarea', 'date_picker', 'number', 'range' ],
	},
	'core/heading': {
		content: [ 'text', 'textarea', 'date_picker', 'number', 'range' ],
	},
	'core/image': {
		id: [ 'image' ],
		url: [ 'image' ],
		title: [ 'image' ],
		alt: [ 'image' ],
	},
	'core/button': {
		url: [ 'url' ],
		text: [ 'text', 'checkbox', 'select', 'date_picker' ],
		linkTarget: [ 'text', 'checkbox', 'select' ],
		rel: [ 'text', 'checkbox', 'select' ],
	},
};

Screenshare

Screen.Recording.2025-07-08.at.18.04.35.mov

ockham · 2025-07-04T11:19:11Z

I think there's a minor UX glitch with regard to the tools panel and link/unlink button:

AFAIU, we should change two things here:

The panel's heading shouldn't change based on the link/unlink button; it shouldn't describe the link/unlink option, but the nature of the panel's controls (so probably "Attributes").
The panel's "vertical three dots" menu shouldn't change contextually; it should only apply to the whole Attributes panel, not its individual rows.

(This is based on how I observed the UX pattern to work e.g. for the existing margin panel in the style tab of the block inspector.)

cbravobernal · 2025-07-07T08:18:11Z

The panel's "vertical three dots" menu shouldn't change contextually; it should only apply to the whole Attributes panel, not its individual rows.

But, in that case, if you have the four of them unlinked, and want to reset only the image title or alt, you will need to reset every of them at once and set one by one again, right?

It's better to keep consistency, but as we change the number of toolsitem, that is the default behaviour. I'll take a look at how is implemented for margin and styles.

Thanks @ockham!

gziolo · 2025-07-09T11:45:17Z

Removing selected connection doesn't work properly:

The editor remains in this weird state where it looks like the field is still connected with SCF field.

gziolo · 2025-07-09T11:47:37Z

For some reason, the panel moves in the sidebar after selecting the value:

gziolo · 2025-07-09T11:50:23Z

The experience for the Button block is less fluid. Should we limit it to mapping to the text attribute and leave the advanced connection to the Attributes panel?

Maybe we could limit it to URL and text?

The filtering for the URL looks pretty nice:

cbravobernal · 2025-07-09T11:56:45Z

For some reason, the panel moves in the sidebar after selecting the value:

That happened too in Gutenberg with the tab. It maybe a hook-related thing. I'll take a look at it.

ockham · 2025-07-09T12:03:09Z

assets/src/js/bindings/sources.js

+const handleDateFieldValue = ( fieldValue, fieldConfig ) => {
+	if ( ! fieldValue ) {
+		return '';
+	}
+
+	return dateI18n( fieldConfig?.display_format, fieldValue ) || '';
+};


I'd be interested in making date_picker fields work with Core's Date block (that I'm currently working on). That block will allow binding to its datetime attribute, which will be using this format. The user can use the block inspector to set the format that the date is rendered with (this is a feature of the Date block that already exists).

However, AFAICS, the SCF source will always return the date using the display_format that's set in SCF options, meaning that the Date block might receive the date in a format that it won't understand ❌

In this particular case, one solution would be to allow binding the Date block's format attribute to a source, and to have SCF expose its format. This could be a fairly elegant solution, as it would allow both using SCF's format, but also setting a custom format from within the Date block. (We would need to allow unlinking individual bound attributes, however.)

This might work well enough in the case of date fields, but might not scale to other cases. In the bigger picture, this is a question of who decides the formatting of a given piece of information. An alternative approach would be for SCF to always just provide a standardized "raw" format, and to leave formatting up to the individual block that it is bound to. IMO, this makes some sense, as it encapsulates the data layer in SCF, and leaves the formatting to the presentational layer (i.e. the blocks). However, it would mean that SCF's own format settings will be ignored, and some data won't look pretty when bound to a more "primitive" block (e.g. binding datetime to a paragraph block).

I was wondering how the question of formatting was previously considered in the context of Block Bindings. For example, so far, all examples of Block Bindings use args: { key: ... } to select a given source field for binding; was the idea that format could be supplied as an additional arg? (E.g. args: { key: date, format: 'M j, Y' }?

@cbravobernal @gziolo

We probably don't have to answer this for this PR, but it might be good to keep in mind for our next steps.

However, it would mean that SCF's own format settings will be ignored, and some data won't look pretty when bound to a more "primitive" block (e.g. binding datetime to a paragraph block).

I guess we could auto-convert paragraphs bounded to a datetime field to that date block to avoid that. But then it would not be compatible with future "shortblocks". My opinion is that the format value defined on the field has been widely used, so it should be the default one, and then the block should be capable to override that format option.

That way we wouldn't break backwards compatibility neither. We could for sure update the source with more args. The key one was a convention from the beginning of the project.

ockham · 2025-07-09T12:11:50Z

assets/src/js/bindings/sources.js

+const handleNumericFieldValue = ( fieldValue, attribute, getMedia ) => {
+	if ( attribute === 'content' ) {
+		return fieldValue.toString() || '';
+	}
+
+	// For image fields or numeric values, try to resolve as media
+	const imageObj = getMedia( fieldValue );
+	return resolveImageAttribute( imageObj, attribute );
+};


I'd love if we could restructure this a bit. IMO, it feels a bit backwards that when given a numeric value, we have to guess if it's an image ID, when we have higher-level information about field types available at the callsite. (A similar note applies to handleObjectFieldValue.)

I'll quickly try out locally what that would look like.

Please! Totally agree.

This is more or less what I have in mind: At the top level, a switch for all possible SCF field types. It's still incomplete since I'm not yet totally familiar with all the possible ways they are mapped to block attributes.

switch ( fieldType ) { case 'text': case 'textarea': return fieldValue || ''; case 'number': if ( attribute === 'content' ) { return fieldValue.toString() || ''; } break; case 'image': // fieldValue is a (numeric) image ID. const imageObj = getMedia( fieldValue ); return resolveImageAttribute( imageObj, attribute ); case 'date_picker': if ( ! fieldValue ) { return ''; } return dateI18n( fieldConfig?.display_format, fieldValue ) || ''; }

Done in 2c96d62.

cbravobernal · 2025-07-09T12:28:06Z

The experience for the Button block is less fluid. Should we limit it to mapping to the text attribute and leave the advanced connection to the Attributes panel?

Sure, my opinion is that the rel and target options should be in the block toolbar or the block sidebar, rather than being bindings (for UI based blocks). I would keep those bindings just for more complex cases (attributes based on external sources or php conditionals).

ockham · 2025-07-09T12:32:17Z

assets/src/js/bindings/sources.js

+	// Special fallback: if we're looking for 'content' and no content property exists (or is falsy),
+	// but there's a 'url' property, use that instead
+	if ( attribute === 'content' && fieldValue.url ) {
+		return fieldValue.url;
+	}


Is this for images?

Image doesn't have 'content' as a bindable attribute, lets change that.
Updated in 60976f6

cbravobernal · 2025-07-09T13:01:06Z

If I create a new CPT and corresponding field group, but forget to enable the "Allow Access to Value in Editor UI" toggle in a field's "Presentation" tab, I'm still able to connect blocks to that field in the editor. However, it doesn't show up on the frontend:

......
It works on the frontend once I enable those toggles.

I guess the solution is to disallow connecting to a field in the editor if its "Allow Access to Value in Editor UI" toggle is disabled?

Fixed in 89d69ff
It will only show fields with the toggle enabled.

ockham · 2025-07-09T13:16:40Z

BTW the date_picker field currently shows a date in the editor (when bound to a paragraph) that's different from what's set in SCF 🙈

My hunch is that it has to do with timezones -- one of them probably uses UTC, and the other one the local timezone 😬

cbravobernal · 2025-07-09T14:41:04Z

BTW the date_picker field currently shows a date in the editor (when bound to a paragraph) that's different from what's set in SCF 🙈
My hunch is that it has to do with timezones -- one of them probably uses UTC, and the other one the local timezone 😬

Ouch.

BTW the date_picker field currently shows a date in the editor (when bound to a paragraph) that's different from what's set in SCF 🙈
My hunch is that it has to do with timezones -- one of them probably uses UTC, and the other one the local timezone 😬

Should we just take the formatted value from the server and print it as a string?

ockham · 2025-07-09T15:40:47Z

Should we just take the formatted value from the server and print it as a string?

Maybe 🤔

Plus I guess I need to file a bug report against Gutenberg, since it seems that dateI18n (JS) behaves differently from date_i18n (PHP).

cbravobernal · 2025-07-09T16:07:06Z

Should we just take the formatted value from the server and print it as a string?

Maybe 🤔

Plus I guess I need to file a bug report against Gutenberg, since it seems that dateI18n (JS) behaves differently from date_i18n (PHP).

I have a prototype working, but is adding all values parsed by SCF to the types endpoint, ending with maybe too much information.

I will instead try to extend acf object data to include the formatted value.

ockham · 2025-07-10T10:20:27Z

Per discussion via DM, I've pushed a fix for the date issue: 718af07

assets/src/js/bindings/block-editor.js

…onnect-bindings-with-ui

cbravobernal · 2025-07-11T11:50:35Z

Removing selected connection doesn't work properly:

.....
The editor remains in this weird state where it looks like the field is still connected with SCF field.

This one has been fixed.

cbravobernal self-assigned this Jun 12, 2025

cbravobernal added the [Type] Enhancement New feature or request label Jun 12, 2025

cbravobernal mentioned this pull request Jun 23, 2025

Support custom sources (like acf/field) in the Attributes Panel UI WordPress/gutenberg#69841

Open

cbravobernal requested a review from ockham June 24, 2025 09:56

cbravobernal force-pushed the update/connect-bindings-with-ui branch from 917b150 to 8d471bc Compare June 24, 2025 13:03

cbravobernal added this to the 6.6.0 milestone Jun 27, 2025

cbravobernal requested a review from priethor June 27, 2025 11:31

cbravobernal marked this pull request as ready for review June 27, 2025 11:31

cbravobernal requested a review from gziolo June 27, 2025 14:32

cbravobernal and others added 18 commits July 7, 2025 17:07

First commit

464fa1f

Set binding

66c9f18

fix margin

3606d36

Include it as beta feature

07ae7d7

Add clear all fields button

8b31839

Fix format date

e8d2d18

Add edit button, still not working

dc2f05a

Fix option name

1cea2b0

Make work with all attributes

8d7c6b4

Pending refactor, allow all attributes connection for images

6c47ea5

Add a not working change, used ai a lot here

521b36d

Remove edit stuff

6cd6504

Remove now-obsolete modal related code

d9a43fd

Use link/unlink button

24db51e

Use toolspanel

69d65aa

Use better link button

8493b04

Make some cleaning

ffa345b

update lock son

7fa68ab

cbravobernal force-pushed the update/connect-bindings-with-ui branch from 63e9e91 to 7fa68ab Compare July 7, 2025 15:09

ockham reviewed Jul 9, 2025

View reviewed changes

Fix not allowed bindings

89d69ff

Restructure processFieldBinding

2c96d62

Remove non used bindings

60976f6

Indentation

c57b271

Fix client-side formatting of the date field

718af07

cbravobernal added 2 commits July 10, 2025 12:49

Huge refactor

a4c8f8d

Remove password case

4b1b3ce

ockham reviewed Jul 10, 2025

View reviewed changes

assets/src/js/bindings/block-editor.js Outdated Show resolved Hide resolved

ockham reviewed Jul 10, 2025

View reviewed changes

assets/src/js/bindings/block-editor.js Outdated Show resolved Hide resolved

ockham reviewed Jul 10, 2025

View reviewed changes

assets/src/js/bindings/block-editor.js Outdated Show resolved Hide resolved

ockham reviewed Jul 10, 2025

View reviewed changes

assets/src/js/bindings/block-editor.js Outdated Show resolved Hide resolved

cbravobernal added 3 commits July 10, 2025 16:41

Merge branch 'update/connect-bindings-with-ui-refactor' into update/c…

866bb43

…onnect-bindings-with-ui

Fix unset bindings (AI based)

46cea17

More refactors

fc5ceff

cbravobernal changed the title ~~Experiment: Connect block attributes with custom fields via UI~~ Connect block attributes with custom fields via UI Jul 11, 2025

Connect block attributes with custom fields via UI #176

Are you sure you want to change the base?

Connect block attributes with custom fields via UI #176

Uh oh!

Conversation

cbravobernal commented Jun 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Screenshare

Uh oh!

ockham commented Jul 4, 2025

Uh oh!

cbravobernal commented Jul 7, 2025

Uh oh!

gziolo commented Jul 9, 2025

Uh oh!

gziolo commented Jul 9, 2025

Uh oh!

gziolo commented Jul 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cbravobernal commented Jul 9, 2025

Uh oh!

ockham Jul 9, 2025

Choose a reason for hiding this comment

Uh oh!

cbravobernal Jul 9, 2025

Choose a reason for hiding this comment

Uh oh!

ockham Jul 9, 2025

Choose a reason for hiding this comment

Uh oh!

cbravobernal Jul 9, 2025

Choose a reason for hiding this comment

Uh oh!

ockham Jul 9, 2025

Choose a reason for hiding this comment

Uh oh!

ockham Jul 9, 2025

Choose a reason for hiding this comment

Uh oh!

cbravobernal commented Jul 9, 2025

Uh oh!

ockham Jul 9, 2025

Choose a reason for hiding this comment

Uh oh!

cbravobernal Jul 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cbravobernal commented Jul 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ockham commented Jul 9, 2025

Uh oh!

cbravobernal commented Jul 9, 2025

Uh oh!

ockham commented Jul 9, 2025

Uh oh!

cbravobernal commented Jul 9, 2025

Uh oh!

ockham commented Jul 10, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cbravobernal commented Jul 11, 2025

Uh oh!

Uh oh!

cbravobernal commented Jun 12, 2025 •

edited

Loading

gziolo commented Jul 9, 2025 •

edited

Loading

cbravobernal Jul 9, 2025 •

edited

Loading

cbravobernal commented Jul 9, 2025 •

edited

Loading