Support

Account

Register Login

Forum Replies Created

  • Elliot,

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

    Thanks,
    Alan

  • 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,

    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,

    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.

Viewing 4 posts - 1 through 4 (of 4 total)