Connect block attributes with custom fields via UI

[cbravobernal]

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]

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]

• 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!

[cbravobernal]

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]

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]

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]

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]

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]

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

[cbravobernal]

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]

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.

Fixed in 4a0aeaf

[cbravobernal]

Let's merge it and iterate it if needed.