AdvancedCustomFields / AdvancedCustomFields/acf

Conditional logic in the Advanced Field Settings broke when a wrapper was added v6.2.9.

Open
#921 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
PHP
Stars
945
Forks
197
PR merge metrics
No merged PRs in 30d

Description

Overview

I was testing these ACF v6.2.9 plugin updates in my local environment and ran into a bug that affects one of the customizations we made in the smd-acf plugin.

What's Broken

In smd-acf, we customize the Post Type settings page by adding three additional Advanced Settings tabs
One of those tabs, Blocks, allows the user to control which blocks the post type allows
Post types need to support the editor feature for allowed blocks to be meaningful
Users can control which features a post type supports on the built-in General tab
To make the interface more clear for users, we implemented field conditions on the Blocks tab:
If the post type supports editor, the block settings fields are displayed
If not, a message is displayed explaining how to enable the editor feature
The Blocks tab field conditions no longer work - both the fields and the message are always displayed

ACF Bug

In a recent update, ACF updated the rendering code for Post Type -> Advanced Settings tabs to add a new wrapper div around each tab's content (link).
ACF uses client-side JS to watch for option changes & re-evaluate field conditions live. If a field's value changes, ACF looks for other fields that reference the updated field in their conditions. ACF then updates the UI accordingly.
The addition of the new wrapper div breaks the JS findSiblings function that is used to find referenced fields. Field conditions still work if they reference fields inside the same Advanced Settings tab, but no longer work if they reference fields inside other tabs.

Proposed Solution

The findSiblings function has a special carve-out (link) for finding basic Post Type settings fields (above the Advanced Settings tabs).
I put together a small change that adds a similar carve-out for finding fields within all Advanced Settings tabs.
My plan is to open a PR on the ACF repo w/ this change and an explanation of the issue.

Code Change
var getSiblingField = function (field, key) {
  // ...
  if (!fields.length && $('#acf-basic-settings').length) {
    fields = acf.getFields({
      key: key,
      parent: $('#acf-basic-settings'),
      suppressFilters: true
    });
  }
+  if (!fields.length && $('#acf-advanced-settings').length) {
+    fields = acf.getFields({
+      key: key,
+      parent: $('#acf-advanced-settings'),
+      suppressFilters: true
+    });
+  }
   // ...

};

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in assets/build/js/acf-input.js at getSiblingField/findSiblings, and compare the existing #acf-basic-settings handling with the proposed #acf-advanced-settings lookup. Reproduce the conditional logic behavior across Advanced Settings tabs using the smd-acf Blocks tab scenario. Done means referenced fields in other Advanced Settings tabs are found and their conditions update correctly.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, php
Domain
frontend
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.