issues related to field key references

• Alan

• January 16, 2014 at 3:07 pm

We’re seeing issues with ACF 4.3.4 and WP 3.7.1 that didn’t appear to be happening with WP 3.5.

firstly, we have a custom data importer that uses the XMLRPC protocol. in the WP plugin portion of the importer solution, calls to update_field() are being used to set the values for ACF fields upon creation of a new post.

when we upgraded to the 4.x series of ACF the problem with key reference values became apparent and we modified the code for updating the ACF data to match the solution in http://support.advancedcustomfields.com/forums/topic/get_field-not-working-with-json-in-4-1-8/ …

with WP 3.5 setting the key reference (e.g. _some_key) to a value that matched the reference key name minus the preceeding underscore seemed to work.

with 3.7.1 we’re seeing that this still seems to work for retrieving string values, but the get_field_object() function doesn’t appear to be working properly. it appears that it’s prepending ‘field_’ to the value in the _some_key reference value that’s stored in the database. as a result trying to get the [‘choices’] value for radio buttons or checkboxes isn’t working.

I can only assume that this is a bug, but to be honest I’m not that familiar with the WP development environment (or PHP for that matter).

Additionally, it seems like there should be a master table of ACF field name -> field key mappings. it would be really useful to have a function that could be used to lookup against the master table to get properly defined reference key names programatically (not tied specifically to the post ID)

our importer plugin currently uses the get_field_reference() function, but that’s tied to the post ID so it doesn’t return keys like “field_1234567” (as associated with the master field definitions) when the post is new.

none of the this data is being input via the back-end editor.

any assistance would be greatly appreciated.

Thanks

• Elliot

• January 17, 2014 at 10:11 am

Hi @Alan

Thanks for all the info, but after reading the above, I don’t understand what the issue is.

The issue is related to importing data. Perhaps you could elaborate more on this? Is it a custom importer or a known plugin? Why is XMLRPC important?

What data are you importing? values? fields?
Can you confirm that the field reference is created for each value saved to the DB?

You can learn about the reference field by reading the docs on update_field

Thanks
E

• Alan

• January 17, 2014 at 1:09 pm

Elliot,

thanks for the response.

This is a custom plugin that accepts data over the XMLRPC protocol. it’s important because we’re not using the WP back-end (via /wp-admin/edit.php?…) to add data but basically a batch processor.

we’re importing values to fields that have been already defined via the ACF administrative back-end.

with the importer plugin, the wp_insert_post() function is used to actually create the post and then return the newly created post ID.

once the post ID has been returned, the update_field() function is called for each of the ACF field values within the data package to associate the values to the field names for that post ID.

the problem we have been experiencing is that the field reference (originally) was NOT being created for newly created posts.

at that point I used the work-around referenced in my original post to set the field reference manually.

the problem as I see it currently is that these steps do not associate the field key values that are assigned at the time of definition to the field names.

even the get_field_reference() function provided by ACF doesn’t return the ‘field_<some-hash-number-here>’ field keys, but basically returns ‘field_<field_name>’. The problem with this is that the field_name doesn’t start with ‘field_’ and there is a disconnect.

I wrote a wrapper to the update_field() function which attempts to get the field key using get_field_reference() and if it returns ‘field_<field_name>’ then it fiddles it and uses update_post_meta() to assign the actual field_name to the reference key. (e.g. if the field name is ‘acf_name’ , get_field_reference() would return ‘field_acf_name’ and set ‘_acf_name’ to ‘field_acf_name’ which doesn’t match ‘acf_name’)

what this did was set two meta_key values in the postmeta tables:

meta_key = ‘acf_name’, meta_value = ‘my name here’
meta_key = ‘_acf_name’, meta_value = ‘field_acf_name’

the modifications I made in the wrapper provided the following results:

meta_key = ‘acf_name’, meta_value = ‘my name here’
meta_key = ‘_acf_name’, meta_value = ‘acf_name’

in WP 3.5 this workaround seemed to work without issues. the ACF provided get_field_object() would also properly map ‘_acf_name’ to ‘acf_name’ and retrieve the values within the object.

after the upgrade to WP 3.7.1, we have specifically seen with radio button type fields that get_field_object() prepends ‘field_’ to the value in the reference field so that a lookup of ‘_acf_name’ would not return ‘acf_name’ (as defined in the database) but ‘field_acf_name’ and thus not returning a proper object. (in this case, the [‘choices’] element was missing)

My thoughts are that when the ACF fields are originally defined, they’re assigned field_key values like ‘field_<some-hash-number-here>’ which ultimately need to be matched up to the reference fields in each post. Couldn’t there be some way to look up the ‘master’ field_key value via a function?

for what it’s worth, I know enough PHP to be dangerous and not much more; I don’t really fully understand the inner workings of wordpress and how all the hooks / filters work (or are supposed to work). I’m submitting this issue mostly because the issue only arises as a result of using our importer and not by means of using the WP back-end editing and thus our theme developers are unable to assist. it seems to me that some hook and/or filter related to the ACF plugin isn’t being executed when the wp_insert_post() function is called as opposed to when the update/publish button is clicked in the back end editor.

hopefully this was useful information.

• Elliot

• January 19, 2014 at 6:02 pm

Hi @Alan

The only thing I can think of is that you are using the field_name instead of the field_key when saving data via the update_field function. Is this possible?

Thanks
E

• Alan

• January 19, 2014 at 7:51 pm

Elliot,

yes. we are using the field_name within our app/importer. The reason for this is because we have several environments (e.g. dev. / staging / production) where the field_keys are not guaranteed to be the same on each system. We also have hundreds of ACFs defined. This is why the lookup is so important.

anyways, the important issue with regards to my OP is that the workaround, whereas we populated the reference ‘_text’ with a value of ‘text’ (as an example) and ‘text’ had a proper value in it, was working fine with wordpress 3.5 but then stopped working properly in conjunction with the wordpress 3.7.1 upgrade.

specifically with regards to radio buttons in which the get_field_object() function appears to be prepending ‘field_’ to the value that is stored in the reference (in this example ‘_text’)

so, let’s use the following example:

meta_key = ‘radio_button’, meta_value = ‘pick me!’
meta_key = ‘_radio_button’, meta_value = ‘radio_button’

get_field_object() is returning ‘field_radio_button’ for the value of ‘_radio_button’ meta_key. it should be returning ‘radio_button’ as the value of the ‘_radio_button’ meta_key, but it’s prepending ‘field_’ and thus the actual values are not being properly returned as an object. (and subsequently as a result the [‘choices’] array element does not exist within the returned object)

Regards,
Alan

• Elliot

• January 20, 2014 at 9:56 am

Hi @Alan

For ACF to successfully retrieve a field object, it must know the field key. The field object can’t be loaded from just the name.

The DB row: meta_key = ‘_radio_button’, meta_value = ‘radio_button’ should look more like this: meta_key = ‘_radio_button’, meta_value = ‘field_abc123’

I don’t doubt that this worked on an older version of ACF, but the modern day ACF requires a field key. It is important that you import the data correctly and use the field_key, not the field_name in the update_field function.

The trick here is how to get the field key…

Perhaps you could export the fields to PHP and include them in each install? This way, they are not in the DB and can all contain the same field key.

Would that help?

Thanks
E

• Alan

• January 20, 2014 at 12:57 pm

Elliot,

Thanks for all of your time and effort, however; I feel like we’ve kind of ended up on a tangent. to simplify the issue I’m reporting; both installations have the SAME version of ACF (4.3.4). one installation has WP 3.5 and the other has 3.7.1

get_field_object() works as expected in WP 3.5: it reads the value of ‘_radio_button’, sees it’s set as ‘radio_button’, returns a field_key value of ‘radio_button’ and then returns the value of ‘radio_button’ as expected.

on WP 3.7.1 the same code reads the value of ‘_radio_button’, sees it’s set as ‘radio_button’, returns a field key value of ‘field_radio_button’ and then returns an invalid object (because there is no ACF in the post that has a field key of ‘field_radio_button’)

this is the issue that i’m reporting. all the other stuff is fluff that has apparently distracted from the real issue. (sorry about that)

Alan

• Elliot

• January 21, 2014 at 5:24 pm

Hi @Alan

Thanks for the clarification. Do you have different versions of ACF on both sites? I find it hard to imagine that the update in WP only is effecting the get_field function so much…

Thanks
E

• Alan

• January 21, 2014 at 5:48 pm

Elliot,

No. they are identical versions of ACF on both sites.

Thanks,
Alan

• lopo

• January 22, 2014 at 12:38 pm

Hi,
I have a similar issue: I have to import some data from a MySQL DB, and with an older version of ACF I just used field names (so I could cycle easily on the querys’ result rows) to store values with update_field, and get_field retrieved them perfectly.

I recently updated to the last version of ACF, and get_field stopped working unless I edited the post and saved, which I can’t do given the size of my data (thousands of posts).
Trying to solve the issue, I found that in function get_field_object() in core/api.php there is a test
if( !$field)
It happens that when get_field is retrieving a field with a temporary field key (e.g. field_myfieldname) $field at that point is an array with all the correct keys, but no values.
Changing the line to
if( !$field || !$field['key'])
to detect an empty key enables the execution of the following code

		// treat as text field
		$field = array(
			'type' => 'text',
			'name' => $orig_field_key,
			'key' => 'field_' . $orig_field_key,
		);
		$field = apply_filters('acf/load_field', $field, $field['key'] );

which seems to fix the problem and retrieve the data.
I can imagine there would be problems with some types of field, but it’s OK for me since they are text fields.

• sergiozambrano

• June 30, 2015 at 8:05 am

Ohhh… I DID have this problem time ago. I hope I remember this the day those websites get ACF updated! This and/or setting up my own key names when programmatically declaring the field groups for several websites will give me a headache soon 🙁

Thanks everyone for the long detailed posts 🙂

This gives me an insight of the issues I’m having right now.

This and “allow me to recycle the fields” kind of feature requests could be fixed by adding a new input field to the field creation process to select another field as the source of the ref _key. That would make to ignore all the settings for that field, so it would be faster to create them. Not optimal, but it will provide a field-reusage system 🙂

I’ll take a look at the code to see if I can inject the new custom field everywhere without breaking anything and we might have a solution to mine and this kind of issues 🙂

• sergiozambrano

• July 1, 2015 at 3:56 pm

Since this is one of the few topics about field key references, I’ll post what fixed it for me.

If you have problems that seems to point to the wrong reference key being retrieved, make sure you don’t have a filed name duplicated SOMEWHERE ELSE.

I know you probably triple-checked the fields failing to save the data to the right key, but that was what was mixing up my field values.

I kept double and triple checking the field values and keys of the fields of the issue… I even fed the update_field function with the right keys, rather than field names, and it still failed, but I never thought to check OTHER fields from other subfields in other layouts (flexible content sub_fields).

I really thought “if using the same name is so terrible, it would be plain prohibited, validated and auto-corrected if necessary”.

My guess:
When the keys are retrieved from the DB, and one is overwritten with the other in the array being generated, the indexes of the returned field keys don’t match the total fields and I assume that’s why the value for one field ends up in another, completely unrelated. It probably affects fields that were created after the one with the duplicated name.