Hello,
Thanks for the feedback!
I just made some tests, and the field behave correctly in a native ACF Form and an ACFE Form.
However, as you pointed out, the field isn’t correctly loaded in an AF Form. I ran some investigations, and the problem comes from the fact that AF Form doesn’t use the native ACF functions such as acf_validate_field(), acf_prepare_field() or acf_render_field() in order to prepare/render fields on the front-end, when ACF uses it for its ACF Form feature, and ACF Extended uses it for its ACFE Form feature.
Instead, AF Form uses it’s own set of custom functions which are outside of ACF scope. This is problematic because ACF Extended uses the native acf_prepare_field() (and thus, the acf/prepare_field hook) in order to change the field type on the fly to reflect the settings in the UI in order to display the field as a Radio, a Checkbox, a Select, a Select2…
To allow all these different display type and maximize compatibility with the ACF JavaScript which handle these Radio/Checkbox/Select/Select2 scripts (and all the sub-settings such as “Allow Multiple Selection”, “Allow Null” etc…), I have to rely on that method. There are a lot of ACF Extended fields which allow multiple kind of Radio/Checkbox/Select display, such as Block Types, Countries, Currencies, Image Sizes, Languages, Menu Locations, Menus, Post Types etc…
Unfortunately I can’t really do much here, as AF Form doesn’t use the builtin ACF functions to prepare and render fields. This is a choice of the developer which has its advantages (more control), but also its inconveniences like the compatibility issues we see here.
I hope the problem is now more clear.
Have a nice day!
Regards.
