Hi,
We’re registering some new fields / groups via PHP. But when the post edit page triggers the screen change functions in ACF, all ACF fields are hidden and those marked as needing to be “visible” are then unhidden.
Our PHP registered fields are not listed in the JSON returned to ACF, which decides what needs to be “visible”, so they remain hidden whenever something on the edit page triggers an AJAX call.
This seems like odd behaviour – ideally we would like to keep registering fields via PHP, as it’s the best option for our plugin development. But it’s frustrating that ACF seemingly ignores PHP registered fields when the change functions are triggered.
Is there a way to keep PHP registered fields visible?
Are you using gooberbug? There are some issues with field groups appearing when they should with the block editor.
If not, check your location rules for the field group. I’m not seeing issues when fields not displaying when registered in PHP. What are your location rules for these groups.
Thanks for responding. No, we’re not. This is on WordPress 4.9.8.
So the fields are being displayed – they’re on the form, and are visible when you first load the page. But when certain actions in the Edit Post screen trigger acf.screen, all fields with a class of acf-postbox are hidden. Then, only those contained in the json data are unhidden again.
Fields registered in PHP don’t then get unhidden, and remain on the page with an inline style of display: none that has been applied by the ACF JS.
This is all behaviour from acf-input.js, and you can see it starting around line 10858.
What version of ACF are you using?
I have done some testing and I cannot duplicate your issue. All of my field groups appear where they are supposed to when they are supposed to.
Where/When are you calling the code that sets up the field group? Are they always registered?
What are the location rules? Do they match where you want them to appear?
Always registered, always appear correctly, just that they’re being hidden by the ACF JavaScript when the page is being edited.
However, upgrading to 5.7.12 seems to have fixed this issue. I couldn’t see anything specific in the change logs, but the function that was doing this seems to have been considerably re-written compared to 5.7.7, so this bug has been addressed (either intentionally or unintentionally!).
Thanks for your efforts.
