Can’t get the bidirectional field to work

I’ve looked at this again and when I click the bidirectional ‘select’ drop down, using Google console I can see the AJAX request is returning ‘Woof Woof Woof’, which suggests a nonce issue?

This is the form data being submitted in the request:

action: acfe/fields_settings/bidirectional/query
s:
paged: 1
field_key: acfe_bidirectional_related
nonce: 49aede077c
post_id: 557

Any help would be greatly appreciated.

Many thanks.

Hello,

Sorry for the late answer, I’m currently really busy working on ACF Extended. The message “The results could not be loaded” is a fallback error message of the Select2 field, which basically says there’s something wrong.

I was about to ask you if you see anything strange in the debug console, and your second answer confirms what I thought. There’s definitely something weird on your website. I’ve made a full search in the code source, and never seen any Woof Woof Woof anywhere in WordPress, ACF & ACF Extended code.

I would suggest you to run a full search on your side, in your core/plugins/theme code to look for that string. On my side the field is working correctly. You should make a fresh WP install with ACF Pro, ACF Extended & Default WP Theme to test it, you’ll see everything’s alright.

I hope you’ll find that Woof Woof Woof thing, because it’s really weird.

Regards.

Hi, I couldn’t edit my reply fast enough to say I’ve figured out what the problem is.

I have this filter running in the backend post edit screens:

add_filter('acf/load_field/key=field_5f0588503f494', 'post_edit_content_verification');

post_edit_content_verification is a callback function called on that filter and also as the callback in an AJAX action: add_action("wp_ajax_post_edit_content_verification", "post_edit_content_verification")

The ‘Woof Woof Woof’ is a response in the callback for a failed nonce verification…

I’ve now fixed the problem by only calling this filter on post edit screens of a certain post type. The select drop down now works correctly.

However I’m at the limits of my technical knowledge when trying to understand why my very specifically named function was being called by ACF Extended…

I’m glad it’s fixed but I’m eager to understand how the crossed wires happened.

Any light you can shed would be appreciated.

Many thanks.

Hello,

The major issue here is that you use the same callback for the acf/load_field hook, which is a filter that expect a return $field, and for a wp_ajax_ action which is an action triggered during an ajax request, and doesn’t expect any return.

I suppose that you echo 'Woof Woof Woof' and then die(), which break the acf/load_field hook. You should split your callbacks, one for the field hook and one for the ajax action.

If both are doing the same thing, then write a function to output the expected result, but you need to return $field; at the end of your acf/load_field, no matter what you’re doing with it.

Note: acf/load_field hook is a “dangerous” hook, because it is executed everywhere in ACF and has an aggressive cache on top of that.

It is executed during “Export Field Group” action, in the ACF Field Group UI, in the page headers before printing a form etc… everywhere. Unless you specifically want to alter the field choices during an ajax request (and thus correctly target that event), you should prefer acf/prepare_field, which is more optimized and is only executed right before the field is printed in the “Post Edit” screen.

Hope it helps!

Have a nice day.

Regards.

Hi thanks for the detailed response!

I’m reluctant to split the callback in to two, because they are doing pretty much the same thing. The difference being it’s called on page load and the then via AJAX when someone clicks a ‘verify’ button. The callback just decides if the call is coming from a page load of an AJAX call. So I don’t want to duplicate the code for the sake of a couple lines.

However, I have changed it so that the filter only gets run on certain admin post edit screens (ie. not ACF). And I’ve also changed it to acf/prepare_field, as per your suggestion, so thanks for that.

The bidirectional field is working great now so thank you for your help.

Kind regards,

Richard

• This reply was modified 4 years, 7 months ago by rnbutler87.
• This reply was modified 4 years, 7 months ago by rnbutler87.

Hello,

I’m glad to hear that it now works as expected ??

Note: acf/prepare_field is not executed during ajax calls, so if you want to change the field choices when using the “Lazy Load choices” settings, you’ll have to stick to acf/load_field.

Have a nice day!

Regards.

Hi thanks for the heads up. I’m actually using the acf/prepare_field on page load to populate a ‘Message’ field and then using an ajax call to update that message.

Thanks again.

Hello,

Cool! An another note, ACF Extended includes a new field called “Dynamic Message” which let you write any PHP/HTML code, and target specifically that field by simply using the code:

add_action('acf/render_field/name=my_dynamic_message_field', 'my_message');
function my_message($field){
    
    echo 'Hello World!';
    
}

It’s much easier to use than the native ACF Message field, which can be pretty hard to target as it has no name/key.

Hope it helps!

Have a nice day.

Regards.

Hi, this is good to know! You’re right, the message field was a bit annoying to target and since building that functionality I have installed ACF extended (primarily for the bidirectional functionality). So I’ll look in to the dynamic field now instead.
Thanks again!