Reply To: get_field() doesn't return a value when fields are created with update_field()

• John Huebner

• February 3, 2016 at 5:54 am

I’m not the developer of this plugin, I just help out around here on the forum, so take what follows as just the views of another user that happens to also be a developer that build similar thing and spends a lot of time weighing the pros and cons of different approaches to a problem.

Could it be possible? Yes. You can get the field groups, loop through them and find the field and then extract the key.

The problem is, you can have multiple fields with the same name, but they will have unique keys. If there is more than one field matching the name you’re looking for, which one do you use?

After the post is inserted, you can possibly get only the field groups that would be on that post. This requires invoking all of the location rule logic which will slow the process down. Then you still need to loop through all the field groups and fields to find the one you’re looking for. There will still be the problem of what to do if you find more than one field with the same name.

The problem with the ability to have multiple fields with the same name is more than likely the main reason why ACF does not do this. The second someone had multiple fields with the same name and the values get screwed up because ACF used the wrong field key someone would be here reporting a bug that would really have no solution other than Elliot telling you that you can never have more than one field with the same field name. I don’t think that would be very popular.

Searching thought fields is the second reason, it’s just not practical. ACF stores fields by the field key. Using the field key you can go straight to the field in question instead of searching for it. Once a post is updated this can be done by doing a database query to get the field key. It is still faster to use the field key directly because the removes the need to do te second query. There are already complaints about the speed that ACF works, searching for and matching up field names with keys would create additional losses in performance.

I don’t really see this as any kind of a problem to be honest. Instead of copying the field name I copy the field key. Since I usually have the field group displayed on one screen while I’m coding on another I just copy what I need. And even if I was using the field name I still copy and paste. Why? because it reduces the coding errors due to my dyslexic typing.

What do I do when I need to use field keys for something? Here’s an example of something I recently used in a project:

$fields = array(
  'equipment_condition' => 'field_568ad9d81e788',
  'equipment_year' => 'field_568ada4e1e789',
  'equipment_manufacturer' => 'field_568ad61835f56',
  'equipment_model' => 'field_568adac11e78a',
  'equipment_category' => 'field_568ad6d535f57',
  'equipment_serial_number' => 'field_568adba61e78d',
  'equipment_desc' => 'field_568bf44e39b14',
  'equipment_short_desc' => 'field_568bf47639b15',
  'equipment_spec_relationship' => 'field_568bff47e0c3b'
);

Using the above array I can now refer to the field I want using the name
update_field($fields['equipment_manufacturer'], $value. $post_id);

As far as ACF saving a post, have you ever looked at the fields that ACF generates on a post edit screen? If you do you’ll notice that the name used for the input field is the field key and not the field name. ACF uses the same method for updating fields, using the field keys, because it is the only value that uniquely identifies the field.

I look at it this way, the only real purpose that the field name has is to make it easier to get the values on the front end because they are easier to remember and type than the field keys. The only reason that ACF needs dual entries in the database is to provide developers with this easier method to display values and it also makes it so that you can use get_post_meta() using the same name if you chose to do so. It exists for the 90% of the people using ACF that will never modify field using code. For the 10% of us that want to do more complicated things we’re expected to do a bit more work.