Flexible Content + Tab field: collapsing a newly-added (unsaved) layout throws in _acf-field-tab.js and aborts field init (ACF PRO 6.8.3 / WP 7.0)

[RyanUniqueBV]

Describe the bug

On WordPress 7.0 + ACF PRO 6.8.3, collapsing a Flexible Content layout that was added in the current (unsaved) editing session throws two uncaught TypeErrors from the core tab-field JS (assets/src/js/_acf-field-tab.js). The first one aborts acf.getFields()'s init loop, so every field rendered after the tab group never initializes, in our case the WYSIWYG sub-fields inside the Flexible Content layouts. The layout can no longer be expanded and its editors are gone until the page is reloaded.

This only affects layouts added client-side in the current session. Collapsing layouts that were rendered server-side (after Save + reload) works perfectly. A field group needs at least one top-level Tab field plus a Flexible Content field to reproduce.

To Reproduce

1. Create a field group with a Tab field ("Tab A"), a second Tab field ("Tab B"), and a Flexible Content field with one layout containing a single wysiwyg sub-field (minimal JSON below).
2. Add a new post for the assigned post type.
3. In the Flexible Content field, click Add Row and pick the layout.
4. Click the new layout's handle to collapse it.
5. Open the browser console.

Expected behavior
The layout collapses/expands and the fields inside it (including the WYSIWYG) keep working, exactly as they do for saved / server-rendered layouts.

Screenshots or Video
Both errors fire on the single collapse click:

Uncaught TypeError: Cannot read properties of undefined (reading 'addTab')
    at TabField.initialize           (acf-input.js)
    at acf.newField -> acf.getField -> acf.getFields -> doAction()

Uncaught TypeError: Cannot read properties of undefined (reading 'get')
    at render -> getTabs().map()      (the tab-fields manager)
    at doAction('append' | 'show' | 'refresh')

Code

Minimal repro field group:

{
  "key": "group_repro_tab_fc",
  "title": "Repro - tabs + flexible content",
  "fields": [
    { "key": "field_repro_tab_a", "label": "Tab A", "name": "", "type": "tab", "placement": "top" },
    { "key": "field_repro_text_a", "label": "Text A", "name": "text_a", "type": "text" },
    { "key": "field_repro_tab_b", "label": "Tab B", "name": "", "type": "tab", "placement": "top" },
    { "key": "field_repro_fc", "label": "Blocks", "name": "blocks", "type": "flexible_content", "button_label": "Add Row",
      "layouts": {
        "layout_repro_text": {
          "key": "layout_repro_text", "name": "text", "label": "Text", "display": "block",
          "sub_fields": [
            { "key": "field_repro_body", "label": "Body", "name": "body", "type": "wysiwyg", "tabs": "all", "toolbar": "basic", "media_upload": 0 }
          ]
        }
      }
    }
  ],
  "location": [[{ "param": "post_type", "operator": "==", "value": "post" }]]
}

Version Information:

• WordPress 7.0
• PHP 8.4
• ACF PRO 6.8.3
• Chrome 148 (macOS). Reproduces with a stock theme; our theme JS does not touch ACF or TinyMCE.

Additional context - root cause (pinpointed to assets/src/js/_acf-field-tab.js)

After the collapse, a .acf-tab-wrap element stays in the DOM but loses its group instance: $wrap.data('acf') is now undefined. Two paths then dereference it.

1. TabField.initialize() runs again (collapse -> doAction -> acf.getFields() -> acf.newField -> initialize). With a preceding wrap present it takes the "reuse" branch:

// L84-L91
if ( ! $tabs.length || settings.endpoint ) {
    this.tabs = new Tabs( settings );
} else {
    this.tabs = $tabs.data( 'acf' );          // L87 -> undefined (orphaned wrap)
}
this.tab = this.tabs.addTab( $tab, this );    // L91 -> throws: undefined.addTab

The throw is uncaught, so the enclosing getFields().map() loop aborts and no field after the tab group initializes. This is what kills the WYSIWYG editors.

2. The tab-fields manager re-renders on append / show / refresh and maps over every wrap in the document:

// L525-L534
getTabs: function () {
    return acf.getInstances( this.findTabs() );   // L526 -> array containing undefined
},
render: function ( $el ) {
    this.getTabs().map( function ( tabs ) {
        if ( ! tabs.get( 'initialized' ) ) {      // L531 -> throws: undefined.get
            tabs.initializeTabs();
        }
    } );
},

Important: I tried defensively guarding both sites (try/catch around initialize, and filtering falsy values out of getInstances). That silences both console errors, but it does not restore the editors or the collapse/expand behaviour, the form state is already corrupted by then. So the underlying issue is that the PRO Flexible Content collapse / re-render leaves a .acf-tab-wrap without its data('acf') group (it should keep it bound, or re-bind on re-render). L87/L91 and L526/L531 are only where it surfaces; null-guarding them would mask the symptom, not fix it.

Possibly related: #986 (Flexible Content expand/collapse state).

Notes:

• The console line that often co-occurs, Failed to load plugin url: .../wp-includes/js/tinymce/langs/<locale>.js, is unrelated and cosmetic: ACF already prints tinymce.ScriptLoader.markDone(...) for that URL. The editor breakage is the tab crash above, not the TinyMCE language file.
• Also reproduces with the post type's editor support removed and a non-en admin locale, but neither is required for the crash.

repro.json

[mattgrshaw]

Hi @RyanUniqueBV,

Thanks for the incredibly detailed report and sorry to hear you're running into this.

I tried replicating this on WordPress 7.0 with your example field group and unfortunately wasn't able to replicate the issue. Could you please confirm if this is happening in the Gutenberg or Classic editor? You mentioned that this happened on a stock theme, but could you also please confirm if there are any other plugins active when this happens?

Also, after the failing collapse, could you run this in the console and share the output? It'll show us how many wraps exist, which (if any) are orphaned, and where they sit in the DOM:

jQuery('.acf-tab-wrap').each(function(i){
  console.log(i, jQuery(this).data('acf'), this.outerHTML.slice(0, 200), this.parentNode);
});

[RyanUniqueBV]

Thanks for the quick look!

Editor: Classic — and that's almost certainly the missing piece

We disable the block editor site-wide:

add_filter( 'use_block_editor_for_post_type', '__return_false' );

So every edit screen renders ACF in the classic metabox. The field group I attached targets post_type == post, which on a stock install opens in Gutenberg — and it does not reproduce there. With the block editor disabled it reproduces 100% of the time.

Verified minimal repro (no custom post type, no removed editor support)

1. Disable the block editor (Classic Editor plugin, or the one-liner above).
2. Import the field group from my first comment (it targets post).
3. New Post → Tab B → Add Row → pick the layout.
4. Collapse the row you just added.

→ Uncaught TypeError, and the WYSIWYG in that layout is dead until reload. I re-ran exactly this on a clean post (which still has its own content editor) and it throws every time, so it isn't tied to a custom post type or to remove_post_type_support( …, 'editor' ) — only the classic-editor context matters.

Other active plugins

Only ACF PRO 6.8.3 and Gravity Forms 2.9.4, plus three must-use plugins (security headers, a robots.txt/IndexNow helper, and an ACF "fill with lorem" dev helper). All are server-side only; none enqueue or patch ACF's input JS, and the whole stack trace stays inside ACF's own _acf-field-tab.js / acf-input.js.

Console snippet output (after the failed collapse)

There is an orphaned .acf-tab-wrap whose data('acf') is undefined:

// plain post (content editor present): the collapse leaves TWO wraps —
// the original keeps its group, a duplicate is orphaned
0  Tabs {tabs: Array(6)}   <div class="acf-tab-wrap -top">…   parent → <div class="inside acf-fields -top">
1  undefined               <div class="acf-tab-wrap -top">…   parent → <div class="inside">

// our editor-less CPT: a single wrap that has lost its group
0  undefined               <div class="acf-tab-wrap -top">…   parent → <div class="inside acf-fields -top">

Timing note: the wrap is only orphaned after the re-render settles. Logged synchronously in the same tick as the collapse it still shows the group; one tick later data('acf') is gone. That lines up with the two throw sites in _acf-field-tab.js — TabField.initialize taking the this.tabs = $tabs.data('acf') branch (L87 → undefined.addTab), and the manager's getTabs() feeding the orphaned wrap into render() (L526 → L531, undefined.get).

BEFORE → Working: a freshly added Flexible Content layout; the WYSIWYG initialises with its toolbar. AFTER → After one collapse of that same layout: the WYSIWYG no longer initialises (Visual/Text tabs remain, but no toolbar and an empty editor). The field-init loop aborted on the tab TypeError. AFTER (cleaned out WP Sidebar)