ACF block's saved data (repeater sub-fields) silently blanked on normal Update — block `mode` flips to "preview" even without touching preview/expanded-editor UI

Aperta
  • Qualcosa non va?
#1,026 1 commento 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
42/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
php, wordpress
Ambito
backend, frontend

Direzione di ricerca

Inizia confrontando i diff del contenuto della revisione e le tempistiche dell’access-log di Apache intorno a acf/ajax/fetch-block e alla richiesta di salvataggio wp-json/wp/v2/pages. Leggi l’issue #1025 sul comportamento correlato di isFetchingBlock e segui come gli attributi del blocco vengono riconciliati prima della serializzazione. Il lavoro è completo quando la regressione viene riprodotta oppure viene definito un test di regressione che impedisca allo stato di preview/loading di sovrascrivere i valori del repeater durante Update.

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

Descrizione

TITLE:
ACF block's saved data (repeater sub-fields) silently blanked on normal Update — block mode flips to "preview" even without touching preview/expanded-editor UI

BODY:
Describe the bug

A block registered via acf_register_block_type() (no acf_block_version set, so default V2/mode: edit behavior) containing a repeater field can have its mode attribute flip from "edit" to "preview" on a normal Save/Update click — with no one touching the block's preview/expanded-editor toggle. When this happens, every repeater sub-field value (e.g. image) is serialized as an empty string in the saved post_content, and the front end renders the block's static registration-time preview instead of the real content. This has happened twice in production for us in the last 24 hours, both times on ordinary edits (removing/updating repeater rows) via the standard sidebar "Block" panel — never via the pencil/expand icon or any preview toggle.

To Reproduce

We were not able to build a deterministic, isolated repro — this is what we reconstructed from two real production incidents via WordPress revision history and Apache access logs:

  1. Register a block via acf_register_block_type() with 'mode' => 'edit' and a repeater sub-field (e.g. image + text), no acf_block_version set.
  2. Open a page containing the block in the block editor. Click the block (not the pencil/expand icon) and edit a repeater row in the standard sidebar "Block" panel — the panel shows correct, real data.
  3. Click Update.
  4. Compare the resulting revision to the one before it: in both of our incidents, every block on the page had "mode":"edit" flip to "mode":"preview", and every repeater image sub-field flipped from a real attachment ID to "".
  5. In both cases, saving again (Update) a second time, ~15–50 seconds later, produced a correct revision (mode:"edit", real values restored) — so the underlying field data was never actually lost, just the specific save was corrupted.

Apache access logs around the bad save show a burst of POST /wp-admin/admin-ajax.php requests (consistent with acf/ajax/fetch-block) in the 10–30 seconds immediately before the POST /wp-json/wp/v2/pages/{id} save request that produced the bad revision — in both incidents. We were not able to capture the exact in-browser request bodies live (both incidents were caught after the fact from logs), but the timing strongly suggests a race between an in-flight block preview/fetch and the block's attributes being read for serialization at save time — similar in spirit to the isFetchingBlock timing issues described in #1025, but manifesting as silent data loss on a normal save rather than a stuck UI.

Expected behavior

Clicking Update should never serialize a block's in-progress/loading state (mode: preview, blank repeater values) over real, already-saved data — either by not allowing the save to proceed while a block's data is still resolving, or by never letting a block's committed attributes regress to a default/blank state once real values have loaded.

Version Information

  • WordPress: 7.1
  • Advanced Custom Fields PRO: 6.8.8
  • PHP: 8.3.6
  • Block registered via acf_register_block_type() (PHP array registration, not block.json), 'mode' => 'edit', no acf_block_version set.

Additional context

This may be related to two other things we found while investigating:

  1. A separate, purely cosmetic issue: without acf_block_version set, the editor canvas shows the block's registered example/preview image instead of a live render whenever the block isn't the actively-selected block. Setting acf_block_version: 3 fixes that, but on our repeater blocks it breaks the V3 "expanded editor" panel instead — every repeater sub-field renders blank in that panel's form (real data, correct on the server side, just not applied to the panel's inputs), which is why we reverted to the V2 default and are hitting the bug described above instead.
  2. #1025 (filed today) describes the Expanded Editor becoming unresponsive during an in-flight block preview re-fetch (isFetchingBlock), which reads to us like the same underlying fetch/attribute-reconciliation timing area of the codebase, just a different symptom (stuck UI there, silently-blanked saved data here).

Happy to provide the exact revision content diffs (before/after JSON) and access log excerpts from our two incidents if useful — redacted to remove real customer data.

Lingua principale
PHP
Stelle
947
Fork
198
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.