Support

Account

Register Login

Home › Forums › Bug Reports › Bug: acf_get_reference() is returning incorrect field reference

Solved

Bug: acf_get_reference() is returning incorrect field reference

  • Hi support,

    I have been hassling a lot for the last couple of hours. And the problem appeared to be that the ACF is grabbing the incorrect field reference using acf_get_reference() function.

    So I have 2 CPTs (trips & explore-trips), and both of them have separate ACF field groups. Some of those groups have the same key, which in my case is _products.

    _products is a repeater field. In ‘trip’ CPT, it has total 6 sub-fields whereas in ‘explore-trip’ CPT, it has only 3 sub-fields.

    I am using update_row() function to update the value of _products in trips CPT. However, what ACF is doing behind the scene is that it’s actually getting the reference from the explore-trips field group instead. And because of that, update_row() is only updating the values of 3 sub-fields instead of the actual 6.

    And just to be sure, all the field references are different and unique. I checked that first time to ensure the _products key doesn’t have same reference in both field groups.

    I found this out by directly checking in ACF Pro’s plugin folder and it appears that acf_get_reference() is the function that is returning the incorrect reference.

    I believe this is a bug and should be fixed. I’m happy to help with more details if needed.~

  • Update:

    This seems to be affecting the old posts. Not the new ones that I create. Which makes me believe if this has to do with the cache?? If yes, then why doesn’t ACF clear cache when a field group is updated?

    Or is there a way to clear the fields/ACF metadata cache of a post?

  • Update 2:

    Not for new trips either. Please note that I am using update_row() function to add to the _products field. And that is not working even for new trips which makes me believe that it’s a bug within update_row() or some internal functions.

    Please check and fix this asap as it’s affecting our work.

    Thanks in advance.

  • Are you specifying the post ID when working with the repeater? If the current post ID for the current page is for “post type A” and you are trying to update “post type B” then ACF is returning the wrong field reference because it’s looking at the wrong post.

    Just guessing, additional code that explains what you are doing might help.

  • @hube2 thanks for your response.

    Yes, I am passing the correct post ID in the update_row() function. It’s all happening in the backend using a webhook. I built a plugin to dynamically create posts and update ACF fields.

    So the problem occurred, when I duplicated the field group for “post type A” and renamed it for “post type B”. I ensured that the location is unique. Now, every time when the plugin dynamically creates a post in “post type A”, basically uses the repeater field from the “post type B”. This does not happen when I manually create a post from WP admin.

    I believe that because the field group for “post type B” was created later, update_row() is somehow picking the _products field key from “post type B” instead of the correct “post type A”.

    Here’s the code if it can help:

    
$images = isset( $data['images'] ) ? $data['images'] : array();
$post_id = isset( $data['post_id'] ) ? $data['post_id'] : '';
$swingline_id = isset( $data['swingline_id'] ) ? $data['swingline_id'] : '';
$acf_key = isset( $data['acf_key'] ) ? $data['acf_key'] : '';
$acf_repeater_key_values = isset( $data['acf_repeater_key_values'] ) ? $data['acf_repeater_key_values'] : '';
$row_index = isset( $data['row_index'] ) ? $data['row_index'] : 1;

$new_images = $this->helpers->upload_images( $images, $post_id, $swingline_id );

if ( ! empty( $new_images ) && is_array( $new_images ) ) {
	$acf_repeater_key_values['_images'] = $new_images;
}

$updated = update_row( $acf_key, $row_index, $acf_repeater_key_values, $post_id );

    I hope this helps to understand the problem. I really think it’s a bug which ACF devs should look into. I can help with more details if needed.

  • When ACF gets the reference (field key) it uses the post ID supplied and the field name supplied to get the hidden ACF field key reference. There are only two ways that this can return the key reverence for a different post/post type.

    1) The post ID supplied is incorrect
    2) The field key reference is the database for them meta key/post ID pair is the wrong field key

    Another possibility is that these repeater fields have the same field key. Field keys must be unique. If they are the same then ACF could be getting the definition of the wrong field. But this does not seem likely since you since you are not having a problem in the admin.

  • So I am also creating the post dynamically using wp_insert_post() WP function. Is it possible that during this creation, ACF somehow gets the reference of a different post/post type?

    1) the post ID is correct as it works for all other non-repeater fields.
    2) yes, you are right here. that’s what I mean, the key/post ID pair seems to be wrong in the database.

    As for the same key, so the repeater fields have same field key but they are showing on totally different post types. e.g., one repeater field with _products that has 6 sub-fields is showing on “post type A” and another repeater field with _products that has only 3 sub-fields is showing on “post type B”. So this should not be an issue.

  • If you are using wp_insert_post() then

    1) There cannot be a post ID before it is inserted, you will only have the correct post ID after it is inserted.

    2) The fields will not exist on the newly inserted post. Even with the correct post ID the fields will not exist and ACF will fail to find the reference and fail to update the field. When adding/updating fields that do not exist you must use the field keys, see the update_field() documentation.

    Field keys, unlike field names, must be unique to your entire WP site. All field keys must be unique, they cannot be repeated in multiple field groups. If you have duplicate field keys then this is more then likely the source of your issue.

  • 1) Yes, I first create the post and get the post ID. And then pass it down to the fields.

    2) Ah, that’s a good point. So you mean that if the fields do not exist, then we must use field key (e.g., field_1231231) instead of the field name (e.g., _products)? However, my client is how do I get the field key programmatically by providing the field name? if possible at all?

    Sorry, I confused field key with field name. Yes, field keys (e.g., field_123123) are unique throughout the site in all field groups. Only field names (e.g., _products) are being used in multiple field groups.

  • There is not a way to get the field keys programmatically by the field name if they do not already exist. At least not easily.

    There is a round-a-bout way to do this. There is a function in ACF, acf_get_field_groups(). This function takes arguments. I don’t remember the specifics, but the last time I looked at it I was able to get field groups based on the post ID. You can then loop over the field groups and get the fields in each groups using the function acf_get_fields(). Then you could loop over all of the fields and find the field name and get its key.

    When working with repeaters you must use keys for the repeater and all of its sub fields.

  • I accept this has a solution. After my last message, I checked a bit and the only way seemed was to actually read the JSON file stored in the plugin and get the field keys from there.

    But thanks for pointing out in the right direction with acf_get_field_groups() hint. I’m gonna check this out and probably will share my solution here if I could have one.

    Thanks a lot for the quick support!

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.