AdvancedCustomFields / AdvancedCustomFields/acf
Conditional logic in the Advanced Field Settings broke when a wrapper was added v6.2.9.
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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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