AdvancedCustomFields / AdvancedCustomFields/acf
V3 block default field values not saved on first save when only InnerBlocks are edited (autoInlineEditing: true) — regression since 6.6.2 fix
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 945
- Forks
- 197
- PR merge metrics
- No merged PRs in 30d
Description
ACF V3 blocks with autoInlineEditing: true do not commit field default_value to block attrs on first save, unless the user explicitly interacts with an ACF field before saving. The ACF 6.6.2 changelog states this was fixed ("V3 Blocks now save default field values even if the block wasn't interacted with before saving"), but the fix does not apply when only InnerBlocks are edited.
Additionally, after saving a page containing such a block for the first time, the Gutenberg save button re-activates — suggesting ACF is modifying post_content server-side after the save, causing the editor to detect a content mismatch. When two or more instances of the same block are on the same page, only the last one has defaults correctly applied after the second save.
To Reproduce
Register a V3 ACF block with autoInlineEditing: true containing a select field with a default_value and an InnerBlocks area.
Insert the block on a page. The ACF field shows the default value in the editor sidebar (client-side only — expected).
Edit one of the block's InnerBlocks (e.g. type in the paragraph) or do not edit anything at all. Do not touch the ACF select field.
Click Save.
Reload the page in the editor.
Inspect the block — the ACF field is empty in the DB; default_value was not committed.
Expected behavior
The default_value for each field should be committed to block attrs on the first save, consistent with the fix described in the 6.6.2 changelog. The save button should remain disabled after saving with no server-side content mismatch.
Code
block.json:
{
"name": "acf/my-block",
"title": "My Block",
"acf": {
"blockVersion": 3,
"autoInlineEditing": true,
"usePostMeta": false,
"renderTemplate": "my-block.php"
},
"apiVersion": 3
}
my-block.php:
<?php
$layout = get_field( 'layout' ) ?: 'left';
?>
<div class="my-block" data-layout="<?php echo esc_attr( $layout ); ?>">
<InnerBlocks />
</div>
Field group JSON: (drag and drop the exported field group containing the layout select field with default_value: "left", allow_null: 0, assigned to acf/my-block)
Version Information:
WordPress Version: 7.0
PHP Version: 8.5.6
ACF Version: ACF PRO 6.8.1
Browser: Firefox 151.0.1
Additional context
Confirmed on a clean WordPress install with no plugins except ACF PRO 6.8.1. Custom theme hooks were ruled out by testing on a bare theme.
The save button re-activation suggests ACF's server-side processing modifies the serialized block comment after save, causing Gutenberg to detect a mismatch between what the editor sent and what the server returned.
The bug appears specific to autoInlineEditing: true — worth verifying whether the 6.6.2 fix only covers blocks without inline editing.
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
Reproduce the issue with the shown block.json, my-block.php, and an exported field group containing the layout default. Start by comparing the first-save block attributes and serialized content when only InnerBlocks change, including the Gutenberg save-button state. Done means defaults persist on the first save for every block instance and the save button stays disabled after saving.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- full-stack
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100