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.
