I’ve been trying to debug this for quite awhile now with no avail.
I have an acf field named code in a acf field group called coupons. Everything was working fine and then, bam, things started breaking as ACF was not returning the correct value. Basically code is returning false using get_field('code', $post_id); Even though when I go to the post I’m referencing, the code field has a value. I realized that if I do get_field('key_xxxxxxxxxx', $post_id); it works.
I don’t have a problem with that. I went through all the code and changed from names to keys for everything… all update_fields and get_fields.
However, the issue I’m having is that I use get_fields($post_id) on coupons in ajax requests quite a bit, and that won’t return the correct value, it only returns false.
How do I remedy this?
EDIT:
Correction, using get_field(‘key_xxx’, $id) also returns false. But the post shows that it’s there. Note that the posts are created with php (not manually). I know I’ve read that somehow that messes things up. I’m assuming that if I click update, it will work, but I want to know how to do this without having to click update.
By the way, I looked at db and that post does not have multiple entries for code. It only has one. So there shouldn’t be anything that would fumble the lookup. The strangest things as I said, was that it was working. The famous last words, “nothing changed”, heh. Obviously something changed, but it really seemed like the difference of refreshing the page.
Here’s a pic of the db.
Hmmm, so I figured out the issue. It’s a little concerning to me, but perhaps it was because I was updating with names instead of keys. Perhaps making the change to keys will solve the issue.
Basically, the database was confused 🙂
I used this
public static function get_fields($id){
global $wpdb;
$rows = $wpdb->get_results(“SELECT meta_key, meta_value FROM $wpdb->postmeta WHERE post_id = $id AND meta_value LIKE ‘field_%'”);
var_dump($rows);
exit();
}
And thought for a second that one of the keys looked familiar. If you look at the image above, you’ll see why it looked familiar….because the key that being returned for post 490 was the same key that was associated with 488. For a second, I thought maybe keys were just unique on posts, but then looking at the admin custom fields section keys, I realized that wasn’t the key at all that should be in the database for post 490. Somehow, ACF created a wrong entry for post 490 by using a field key that was not related to that post in any way.
I’m a little confused about what your issue is, except that you said you are creating posts and inserting values using PHP. If you create a new post and add a new ACF value, then you need to use the field key when using update_field(). If you are inserting the values yourself using SQL, the you must also insert the field key reference shown in your DB image. With a new post, using the field name in update_field() does not create the field key reference, this is why editing a post and saving the value makes it work.
I was using update_field(‘field_name’, $id) not the field key. And perhaps this was the issue.
Largely the issue was that when I would use get_field it was returning a field with the wrong key…or at least differing from what was the expected key.
As you pointed out, this may very well have been related to me using field_names instead of keys when updating a field.
It is, Not sure what type of field it is, but it should work with basic fields. The problem is with other types of fields, without the field key reference ACF does not really know what to return. In the case of get_field('code', $post_id); it should have been returning the text or number that was stored. If you were expecting a post ID this would be a problem.
Like I said, it was definitely concerning…but since switching to all keys, I have not seen the problem again.
It is a simple text field. As you can see in the image above, the code field with post_id of 490 was returning the field key ending in fb2, but this field key is associated with a completely different acf-group. The field key it should have been returning ended in ee.
I wish I would have saved all the queries so I could show what I was seeing about a little better.
I’ve never seen anything like that before.
