Ship field options as JSON, build option rows from the template on first panel-open

[robin-the-going-merry]

Requested by: @Crabcyborg

What: Every option of every field ships as a full <li> on initial render - classes/views/frm-fields/back-end/field-options.php loops show_single_option() for each option, and classes/views/frm-fields/single-option.php:41-67 prints a label <input> plus a wrapper <span> with its own saved-value <input>, each carrying name/id/class/data-frmchange attributes built from the field id and option key. This happens for every field regardless of whether that field's settings panel is ever opened - on a form with 1000+ fields, or any field with a long dropdown/radio/checkbox option list, that's a lot of markup nobody looks at, sent and parsed up front.

Where the panel-open dance and the templating precedent already exist: showFieldOptions() (js/src/admin/admin.js:8295-8337) already fires frmShowedFieldSettings every time a field's settings panel is first shown - the same hook #3432/#3433 use for their own defer-to-open fixes. Separately, addFieldOption() (js/src/admin/admin.js:4103-4160) already has a full no-request way to build a real option row: it clones the hidden .frm_option_template row's outerHTML and string-replaces the 000 placeholder key/ids with the real option key (admin.js:4106,4138-4142). That's the exact job needed here, just triggered by 'panel opened' instead of 'Add option clicked,' and driven by option data already on hand instead of a template already sitting in the DOM.

Suggested approach:

1. Server-side (field-options.php / single-option.php): stop rendering a full <li> per real option. Keep the single hidden .frm_option_template row (still needed for the existing add-option flow), and instead emit the field's options as compact JSON - key/label/value - e.g. a data-options attribute on #frm_field_<id>_opts. This travels down with the field's existing payload (initial page render or the frm_load_field ajax batch already in place), not a new request.
2. Client-side: on frmShowedFieldSettings, if a field with options hasn't had its option rows built yet, run addFieldOption()'s clone+rekey logic once per JSON entry to populate the real rows, then flag it built so reopening the panel doesn't rebuild.

Related: #3432, #3433 - same underlying pattern (real work deferred to first panel-open), different mechanism (markup weight/DOM node count here, not third-party widget boot cost there).

Once merged: a field's option rows exist in the DOM only once its settings panel is opened. Until then, only the compact JSON travels with the page - roughly 10-15x smaller than the current per-option markup by itself, on top of not building the DOM nodes at all until they're needed.

[vivi-the-going-merry]

Escalating rather than attempting as a one-shot pickup.

This changes how field options render across every option-bearing field type (checkbox, radio, select, product — single-option.php and back-end/product-single-option.php both need the JSON-emit change), plus a new client-side build-on-panel-open path in admin.js reusing addFieldOption()'s clone+rekey logic. Confirmed several other spots in admin.js read .frm_single_option/.frm_sortable_field_opts DOM directly (sortable init at line ~1859, bulk-edit-option handling, keyboard nav, option-count checks) — none of that reproduces a red state without actually driving the builder in a browser per field type, which is the exact gap this workspace's fix-sop already flags as unavailable unattended (no playwright-cli in a heartbeat-dispatched session; Cypress-in-CI can't gate on a spec that doesn't exist yet).

The closest sibling in this same issue chain, #3432 (a narrower JS-only defer-to-open change), already hit this class of problem and got parked mid-Cypress-spec rather than merged. This one is broader — server + client, multiple field-type templates — so I don't think a fresh one-shot attempt is likely to land cleanly either. Clearing labels for now; this is better scoped as a supervised task with real browser verification than a background pickup.

[robin-the-going-merry]

@Crabcyborg Vivi escalated rather than picking this up: it touches server-side rendering (single-option.php + product-single-option.php) and a new client-side build-on-panel-open path in admin.js, with several other spots reading .frm_single_option/.frm_sortable_field_opts DOM directly (sortable init, bulk-edit, keyboard nav) that can't be confirmed safe without driving the builder in a real browser per field type — not available in an unattended pickup session. Same class of issue as #3432, which also parked mid-verification. Vivi cleared the vivi-pickup label; this reads as a supervised task rather than a background one.

[vivi-the-going-merry]

Picked this up, but the suggested approach has a real regression the issue text doesn't account for — escalating rather than shipping it.

The save-side risk isn't actually a risk. FrmForm::prepare_field_update_values() (classes/models/FrmForm.php:563-577) already falls back to $field->options (the current DB value) when $_POST['field_options']['options_<id>'] is absent:

$new_field[ $col ] = $values['field_options'][ $col . '_' . $field->id ] ?? $default;

So a field whose option rows were never built in the DOM — and therefore never posted — keeps its existing saved options untouched. No data loss on save.

The real problem: other consumers read a field's option rows straight out of the DOM, keyed by a field ID that isn't necessarily the field whose panel is open. Conditional Logic is the concrete case:

• Picking a source field in a logic row's field-select fires getFieldValues() (js/src/admin/admin.js:7064), which calls fillDropdownOpts(fillField, { sourceID: val, ... }) (admin.js:7108) for the source field, not the field whose settings panel is currently open.
• fillDropdownOpts() (admin.js:6776) calls getMultipleOpts(sourceID) (admin.js:6834), which reads input[name^="field_options[options_${sourceID}]"] from the whole document — it needs that source field's per-option <li> markup (and its [label]/[value] inputs) to already exist in the DOM.
• Under the suggested fix, a field's option rows only get built when that field's own frmShowedFieldSettings fires. If the source field referenced by a conditional-logic rule has never had its own panel opened, getMultipleOpts() returns an empty array and the logic row's value picker silently shows no options.

Same shape of bug likely affects getFieldOptions()/adjustConditionalLogicOptionOrders() (admin.js:6660-6717) for the same reason — both scan #frm_field_${fieldId}_opts for a field ID that comes from elsewhere in the builder, not from the panel-open event.

Proposed handling, if someone picks this back up: the "build real rows from the compact JSON, once" logic needs to live behind a single ensureOptionRowsBuilt(fieldId) primitive (checked-and-memoized, e.g. via a data-built attribute on #frm_field_<id>_opts) called from every read site, not just frmShowedFieldSettings — at minimum also from the top of getFieldValues() before it reads the source field's options, and anywhere else in admin.js that reads #frm_field_<id>_opts/field_options[options_<id>] for a field other than the one whose panel just opened. That's a wider audit than the issue's two-file suggestion, and it needs the same audit repeated against formidable-pro (dynamic/lookup fields, repeaters commonly mirror a Lite field's option list when building their own previews) — not something this pass could safely verify without that repo in scope.

Clearing labels rather than shipping the narrower fix and risking a silent conditional-logic regression.

[robin-the-going-merry]

@Crabcyborg Vivi picked this back up and escalated again (2nd time): the save side is fine (FrmForm::prepare_field_update_values() already falls back to the DB value when a field's options weren't posted), but she found a real regression risk in the suggested approach — Conditional Logic reads a source field's option rows straight out of the DOM (getMultipleOpts()/fillDropdownOpts() in admin.js), keyed by whatever field ID the logic rule references, not the field whose panel is currently open. Under a build-only-on-panel-open scheme, a source field whose own panel was never opened would return empty options to a conditional-logic rule referencing it.

Her proposed fix is wider than the issue's original two-file suggestion: a single memoized ensureOptionRowsBuilt(fieldId) called from every read site (not just frmShowedFieldSettings) — including the top of getFieldValues() — plus the same audit repeated against formidable-pro (dynamic/lookup fields and repeaters that mirror a Lite field's option list). That formidable-pro half is out of scope for an unattended pickup regardless.

This needs an architectural call on scope (ship the narrower panel-open-only fix and accept the conditional-logic gap as a follow-up, or scope the wider multi-read-site + Pro audit up front) — your call as the product-line owner. Labels cleared on Vivi's side.