AdvancedCustomFields / AdvancedCustomFields/acf
Block Bindings API - potential bug - native updates to ACF custom fields won't work out of box because of "meta box" saving mechanism.
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 945
- Forks
- 197
- PR merge metrics
- No merged PRs in 30d
Description
It's unclear to me whether this is a bug. Maybe other mechanisms are being developed to further aid with block bindings for ACF defined custom fields, but as long as there is a "meta box" for a custom field present on the editor screen, this issue is likely to persist,
As originally described in this thread -
https://github.com/AdvancedCustomFields/acf/issues/687
the issue is also relevant for current implementations of the described principle (using native blocks to edit an ACF defined post meta value) using the WordPress block bindings API. See this article https://developer.wordpress.org/news/2024/10/getting-and-setting-block-binding-values-in-the-editor/ for an example implementation.
When using this approach for an ACF custom field, the "meta box" for the custom field present in the editor, whether rendered or not, will prohibit the correct saving of the edited value in the native block because it is not automatically updated when the value in the native block is edited and its value will be saved after the native block value thus overwriting the edited with the unedited value in the course of the saving process.
As described in the above linked post, this can be (for some custom field types) be worked around by linking the two values. This also works in the block bindings registerBlockBindingsSource()-function, using the setValues()-method (see above link to the tutorial) - for example like this, updating the "meta box" field value of a textarea custom field with the value edited in the native paragraph block:
if (newValue !== undefined) { document.getElementById('acf-field_58d9b3b2e8de4').value = newValue; dispatch(coreDataStore).editEntityRecord( 'postType', postType, postId, { meta: { [metaKey]: newValue } } ); }
It would thus be helpful to be able to decide on a field by field basis whether a "meta box" for an ACF defined custom field should be present in the block editor to avoid the described problem if there is a native block bound to the particular field.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the block bindings example linked in the issue, especially registerBlockBindingsSource() and its setValues() method, then trace how the ACF meta box is saved in the block editor. Reproduce an edited native block value alongside its ACF field and verify that a field-level choice can prevent the meta box from overwriting the block-bound value.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, php, wordpress
- Domain
- backend, content
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100