update_field on new post creates mismatched meta_keys before save_post()

• emcniece

• April 17, 2014 at 2:39 am

We’re dealing with two separate projects in the office right now that use ACF to handle a variety of custom fields. In both cases, new posts are created programmatically using wp_insert_post(), then using the returned ID we call update_field($field_name, $id) to populate the custom fields. However, the fields are not populating consistently – it seems to depend on whether the post has had its “Publish” or “Update” button clicked.

In this example, ACF fields are being called with “myfield” and not with “field_myfield”.

Before the initial insertion (zero posts of this type, zero ACF entries), the database looks like this:

SELECT * FROM wp_postmeta WHERE meta_key LIKE '%myfield%';
- 0 results

SELECT * FROM wp_postmeta WHERE meta_value LIKE '%myfield%';
- 1 result
- meta_key: field_534d7b392dc8c, meta_value: (serialized ACF definition)

After the wp_insert_post() call:

SELECT * FROM wp_postmeta WHERE meta_key LIKE '%myfield%';
- 2 results
- meta_key: myfield, meta_value: 58350
- meta:key: _myfield, meta_value: field_myfield

SELECT * FROM wp_postmeta WHERE meta_value LIKE '%myfield%';
- 2 results
- meta_key: field_534d7b392dc8c, meta_value: (serialized ACF definition)
- meta:key: _myfield, meta_value: field_myfield

So we see that ACF has created an alias field of field_myfield, and this seems to be what http://www.advancedcustomfields.com/resources/functions/update_field/ recommends using to call update_field() on. However, while using this field_myfield name the fields don’t always get updated! In this state, both update_field() and get_field() calls fail and return false. Something happens during the action when the “Publish” or “Update” button is clicked – go to the newly created post in WP and click the “Update” button and check the database:

SELECT * FROM wp_postmeta WHERE meta_key LIKE '%myfield%';
- 2 results
- meta_key: myfield, meta_value: 58350
- meta:key: _myfield, meta_value: field_534d7b392dc8c

SELECT * FROM wp_postmeta WHERE meta_value LIKE '%myfield%';
- 1 result
- meta_key: field_534d7b392dc8c, meta_value: (serialized ACF definition)

The field_myfield meta key/value has been removed from the database! As such, we can no longer successfully reference our ACF fields and the subsequent update_field() calls have been failing. Clicking the “Update” button on the post seems to apply this database update to all ACF fields available in the database, not just the ones related directly to the active post.

We have tried looking at the hooks and actions around acf/save_post and have attempted to instantiate the ACF classes and execute do_action('save_post') between the wp_insert_post() call and the update_field() calls. This seems to have no effect on database status.

Is this expected behavior? What’s the difference in action hooks between save_post() and actually clicking the “Update” button?

• emcniece

• April 17, 2014 at 5:38 am

We’ve been doing a bit of troubleshooting. The problem seems to lie with a failed field GUID lookup, having provided a top-level field name.

• Clicking the “Publish” or “Update” button executes actions that do not get executed by manually calling the save_post action. This means that the database contains errant meta keys and values for myfield, _myfield, field_myfield and field_###########
• wp_insert_post() does execute the save_post action, but again does not produce the final meta key/value associations required
• During this in-between state of wp_insert_post() and manually updating the post, get_field_object() returns empty field definitions since the $field_key variable contains the name of a field that does not have a corresponding meta value
• Executing acf/save_post manually does not work as the function requires a populated $_POST variable. Manually saving the post works, since the $_POST object contains field GUIDs, then calls acf/update_value
• acf/update_value fails because $field is an empty field definition
• Updating fields with their GUIDs works fine at any point

It seems that we need a solid way to update fields that are attached to a programmatically-created post before the post ACF meta data has been initialized.

• bar7b

• April 24, 2014 at 5:29 pm

Bump.

Any solution found?

• emcniece

• April 25, 2014 at 8:02 am

Unfortunately, no. I ended up making a workaround lookup table that associates the GUID field name with the clean field name. Here’s what the code looks like:

/*==========================================================
=               ACF Field Association Helper               =
==========================================================*/
// Helps ACF make the correct field associations for un-initd post type fields
function custom_get_field($fieldname, $post_id=null){
	global $post;
	$acf_field_pairs = array(
		'field_534c20ba37335:caf_gallery',
		'field_534c209137334:caf_carproof_link',
		'field_534c20e537336:caf_summary_features',
		'field_534c431f9d29f:caf_description',
		'field_534d6eda9dbc3:caf_sale_price'
	);

	$acf_fields = array();
	foreach($acf_field_pairs as $pair){
		$pair = explode(':', $pair);
		$acf_fields[$pair[1]] = $pair[0];
		$acf_fields[$pair[0]] = $pair[1];
	}

	$output = get_field( $acf_fields[$fieldname] , $post_id);
	return $output;

}

So in this function, I’m using a manual lookup $acf_field_pairs array – it’s a colon-separated pair because that’s how it comes in from my Redux Options Framework, but your system might build this differently. The left side is the unique field ID (can be found by inspecting elements in your ACF field groups) and the right side is the clean field name. This function adds both pairs to the generated array so that it can work in both directions.

This is obviously a problem because you have to add new ACF fields here when you add them to the admin.

I have a sneaking suspicion that this might not be a problem in the new ACF v5 however as ACF data will be a full post object instead of meta data.