WYSIWYG fields in ACF Blocks don't save without switching to Preview first
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- javascript
Research direction
Inspect acf-pro-blocks.js, especially BlockForm.componentDidAppend() and its change/key-up handling. Reproduce the nested repeater WYSIWYG case in the Gutenberg editor, then verify that content persists when saving in Edit mode without switching to Preview.
Written by the indexing model from the issue text.
Description
Description
WYSIWYG fields inside ACF Blocks (particularly when nested in repeaters or groups) silently lose their content when saving the post. The content is only persisted if the user manually switches the block to "Preview" mode before saving.
Steps to Reproduce
- Create an ACF Block with a repeater field containing a WYSIWYG sub-field
- Add the block to a post in the Gutenberg editor
- Add a repeater row and type content into the WYSIWYG field
- Click "Save" (without switching the block to Preview first)
- Reload the page — the WYSIWYG content is gone
Expected Behavior
WYSIWYG field content should be saved regardless of whether the block is in Edit or Preview mode.
Actual Behavior
Content typed into WYSIWYG fields is lost on save unless the block is switched to Preview mode first. Other field types (text, select, etc.) save correctly.
Root Cause
In acf-pro-blocks.js, the BlockForm.componentDidAppend() method binds change detection to the block wrapper:
// ACF source (deobfuscated):
i.on("change keyup", () => {
clearTimeout(a);
a = setTimeout(s, 300); // s() calls acf.serialize() → setAttributes({ data })
});- Dominant language
- PHP
- Stars
- 947
- Forks
- 198
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
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.
More from AdvancedCustomFields/acf
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
AdvancedCustomFields/acf#1056 ·
-
PHP 8.5: "Using null as an array offset" deprecation in ACF_Data::is() when rendering a block with empty data (local-meta.php is_request)Possibly taken @faisalahammad claimed this 30 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
AdvancedCustomFields/acf#1044 ·
-
is_preview was called incorrectly notice on every early get_field() since 6.8.10 (acf_revisions::acf_validate_post_id)Possibly taken @faisalahammad claimed this 30 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
AdvancedCustomFields/acf#1041 · 1 comment ·
-
True / False ACF control bug on RTL layoutsPossibly taken @elicohenator claimed this 53 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
AdvancedCustomFields/acf#1038 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
AdvancedCustomFields/acf#1034 · 3 comments ·
All issues in AdvancedCustomFields/acf
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 3 days
-
sync-en
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
[Sync EN] Formatting improvements to "Large Objects (LOBs)" docs (#6056)Possibly taken A pull request linked to this issue is open or already merged. Opensync-en
Difficulty 1/5 Under an hour Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Перевод устарел
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
Maintainers usually reply within 1 day
-
repo:cms
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
craftcms/cms#20613 · 1 comment ·
Maintainers usually reply within 1 day