Duplicated ACF blocks do not reflect TinyMCE edits in editor preview

Describe the bug

When an ACF block containing a WYSIWYG field is duplicated in the block editor, editing the
duplicated block's WYSIWYG field does not update the block preview in the editor. The content typed
in TinyMCE is not propagated to setAttributes({ data: ... }), so the preview remains stale.

This occurs because ACF generates the block ID via acf_get_block_id() using an MD5 hash of the
block attributes. Since the duplicated block has identical attributes to the original, both blocks
receive the same block ID. This causes the TinyMCE <textarea> elements in both block forms to share
the same id attribute (e.g. acf-block_abc123-field_xyz), resulting in TinyMCE instance conflicts.
The duplicated block's TinyMCE onChange handler fails to correctly call setAttributes, leaving the
block preview unchanged.

The frontend preview (via "Preview in new tab") renders correctly — the issue is limited to the
editor's real-time block preview.

To Reproduce

1. Register an ACF block with a WYSIWYG field (e.g. b_content) and "mode": "edit" in block.json
2. Open the block editor and add the block to a post
3. Enter some text in the WYSIWYG field (e.g. "hello")
4. Save the post
5. Duplicate the block using the block toolbar (⋮ → Duplicate)
6. Select the duplicated block
7. Edit the WYSIWYG field in the sidebar or via the pencil icon toggle (edit mode → type new text →
   switch back to preview mode)
8. Observe that the block preview still shows the original text ("hello"), not the newly entered
   text

Expected behavior

The duplicated block's preview should update in real-time to reflect the content entered in the
WYSIWYG field, identical to how it works for the original (non-duplicated) block.

https://github.com/user-attachments/assets/45c9a76d-2bfc-47b9-aff9-347db71ba8eb

Code

Minimal block.json:

{
  "name": "acf/example-wysiwyg",
  "title": "Example WYSIWYG Block",
  "category": "common",
  "apiVersion": 3,
  "acf": {
    "mode": "edit",
    "renderTemplate": "block.php"
  },
  "supports": {
    "align": false
  }
}

block.php:

<?php
$content = get_field('b_content');
if ($content) {
    echo '<div class="example-block">' . $content . '</div>';
}

Field group: a single WYSIWYG field with name b_content assigned to the block.

Root cause analysis

acf_get_block_id() in pro/blocks.php (line ~1469) generates the block ID from
md5(wp_json_encode($attributes)). When a block is duplicated, $attributes (including data) is
identical, producing the same hash. This results in:

1. Identical block IDs for both original and duplicate
2. Identical <textarea> element IDs in both block forms (e.g. acf-block_<same_hash>-field_)
3. TinyMCE instance collision — tinymce.get(id) returns the original block's editor instance,
   preventing the duplicate's TinyMCE from correctly binding its onChange to setAttributes

The issue affects both the sidebar form (InspectorControls) and the inline edit mode form when
toggled via the pencil icon.

Current workaround

We implemented a JavaScript workaround that bypasses ACF's internal onChange pipeline entirely. It
listens for TinyMCE change/keyup events directly and calls
wp.data.dispatch('core/block-editor').updateBlockAttributes() to sync the content to the Gutenberg
store:

tinymce.on("AddEditor", function (evt) {
  evt.editor.on("init", function () {
    var el = evt.editor.getElement();
    var dataKey = parseDataKeyFromTextareaName(el.name);
    // e.g. "acf[block_xxx][note_items][0][note_text]" → "note_items_0_note_text"

    evt.editor.on("change", function () {
      var clientId = wp.data.select("core/block-editor").getSelectedBlockClientId();
      var block = wp.data.select("core/block-editor").getBlock(clientId);
      var newData = Object.assign({}, block.attributes.data);
      newData[dataKey] = evt.editor.getContent();
      wp.data.dispatch("core/block-editor").updateBlockAttributes(clientId, { data: newData });
    });
  });
});

This works but is a workaround — ideally ACF should ensure unique block IDs for duplicated blocks
(e.g. by incorporating the Gutenberg clientId into the hash, or forcing a new unique ID on
duplication).

Version Information:

• WordPress Version: 6.9
• PHP Version: 8.x
• ACF Version: ACF PRO 6.9.4
• Browser: Chrome (latest)

Additional context

• The issue also manifests with blocks that have WYSIWYG fields inside repeaters (e.g. a "mixed
  notes" block with a repeater containing note_text WYSIWYG sub-fields)
• Setting "autoInlineEditing": false in block.json prevents a related but separate issue where the
  placeholder "Click to set content" appears instead of the preview
• The issue does NOT occur with native Gutenberg blocks (e.g. Heading, Paragraph) since they don't
  use ACF's block ID / TinyMCE pipeline
• Upgrading apiVersion from 2 to 3 does not resolve the issue

Start in pro/blocks.php around acf_get_block_id() at the reported line and reproduce the duplicate-block case with the provided block.json, block.php, and WYSIWYG field. Verify that duplicated blocks receive the same IDs and that TinyMCE changes fail to update the editor preview; done means the duplicated block updates in real time without breaking the original, including repeater WYSIWYG fields.