FIX: Option fields apply dynamic and multi-value defaults https://github.com/Crocoblock/issues-tracker/issues/18508

[Gawuww]

Issue - https://github.com/Crocoblock/issues-tracker/issues/18508

[github-actions]

🤖 AI PR Review

Risk level: medium

Review

Summary

• This PR updates a large number of built/compiled JS assets (compatibility/* and modules/* build outputs) and asset version files. The PR title and issue reference indicate the intent: "FIX: Option fields apply dynamic and multi-value defaults". However, I could not find corresponding source-level changes (unminified sources, PHP logic, or unit tests) in this diff — only the built artifacts and asset manifest/version hashes were changed.

What I checked

• Files changed are almost exclusively build outputs: JS files under compatibility/ and modules/ and their corresponding *_asset.php files. No core PHP logic or non-minified JS source files were modified in this PR.
• Sanity checks for security-sensitive flows: I looked for any changes that would remove nonce usage or capability checks in server endpoints — none of those appear here because no server-side endpoints were changed.

Concerns & required follow-ups

1. Missing source changes or explanation

   • If the intention was to change behaviour (option fields to apply dynamic and multi-value defaults), the repository should include the source (unbundled) JS and/or PHP changes that implement the fix. Currently only compiled assets changed. Please either:
     • Include the source changes (and build output) in the PR, or
     • Add a clear note why only the build artifacts are included (for example: the change was done in a separate repository/tool and this PR only updates the built bundles).

2. Tests / QA

   • There are no unit or integration tests added. This is a behaviour-fixing change for form defaults and could affect lots of front-end behaviour. Please add at least a manual QA checklist and (ideally) automated tests covering:
     • Options field with a static single default (regression test).
     • Options field with a dynamic default (macro/dynamic tag) that resolves to single value.
     • Options field with a multi-value default (multiple selections), both static and dynamic values.
     • Confirm behaviour in Gutenberg, and in compatibility contexts (Bricks/JetEngine/Booking/Appointment where relevant).
   • Provide steps to reproduce the original issue and verification steps showing this PR fixes it.

3. Backward compatibility

   • Ensure the public JS API and block attributes remain unchanged. Because you changed many compiled files, verify there are no breaking changes to block attribute names, dataset keys (data-field, data-settings), or callable APIs (JetPlugins.hooks.* / JetFormBuilderAbstract.*) used by third-party add-ons.
   • Mention any migration that may be required if behaviour changed for existing forms that relied on previous default-handling behaviour.

4. Performance / Caching

   • Many asset version strings were updated (asset.php). That's correct for cache busting. Please ensure build process increments are intentional and that no unnecessary code was introduced that increases bundle size or runtime cost.

5. Security

   • Even though this PR only touches client bundles, please ensure any dynamic default resolution that might inject content into the form does not allow unescaped HTML or open redirects. Server-side validation/sanitization should still be the single source of truth; double-check that nothing in the new front-end logic bypasses expected sanitization flows.

6. Multisite / large datasets

   • If option defaults can be pulled from option pages or remote APIs, ensure the implementation is efficient and safe for large option lists (avoid N+1 lookups or heavy synchronous operations blocking initial rendering). If dynamic defaults use remote requests, show the timeout/error handling.

Minor items

• Please keep the PR description aligned with the diff. If this PR is intentionally build-only (updating compiled bundles after merging source changes elsewhere), state that explicitly and link the source PR/commit.
• Add a short changelog line (see below) and include QA steps in PR description for the reviewer.

Recommendation

• Do not merge until either (A) the source-level fix is included in this PR or (B) a clear explanation + linked source commit is provided. Also add tests / QA verification steps as described above.

Files changed (examples)

• compatibility/bricks/assets/build/frontend.js (+.asset.php)
• compatibility/jet-appointment/assets/build/frontend.js (+.asset.php)
• compatibility/jet-booking/assets/build/frontend.js (+.asset.php)
• compatibility/jet-engine/** many blocks and frontend assets changed
• compatibility/woocommerce/assets/build/editor.js (+.asset.php)
• modules/actions-v2/*/assets/build/editor.js (+.asset.php)

If you can provide the source change or a reproduction demonstrating the fix and a short test plan, I will re-review the runtime behavior specifically for the option field default handling.

Suggested changelog entry

- FIX: Option fields apply dynamic and multi-value defaults — option field defaults now support dynamic tags and multi-value defaults (affects options/defaults handling in form fields)