Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Duplicated ACF blocks do not reflect TinyMCE edits in editor preview

Aperta
  • Qualcosa non va?
#1,011 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
javascript, php
Ambito
backend, frontend

Direzione di ricerca

Inizia in pro/blocks.php intorno ad acf_get_block_id() alla riga indicata e riproduci il caso dei blocchi duplicati con i block.json, block.php e il campo WYSIWYG forniti. Verifica che i blocchi duplicati ricevano gli stessi IDs e che le modifiche in TinyMCE non aggiornino l’anteprima dell’editor; il lavoro è completato quando il blocco duplicato si aggiorna in tempo reale senza compromettere quello originale, inclusi i campi WYSIWYG di repeater.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
PHP
Stelle
946
Fork
197
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di AdvancedCustomFields/acf

Tutte le issue di AdvancedCustomFields/acf

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.