Home Forums Backend Issues (wp-admin) Field value update using update_field doesn’t show on backend…


Field value update using update_field doesn’t show on backend…

  • I’ve given up on a support ticket. I sincerely hope you good people can help with this.

    I’ve written a custom plugin that among other things creates a new post type, then registers acf fields to that post type. Everything with this plugin seems to work as expected.

    However, I’m now trying to use a simple script in an mu-plugin to get values from old fields made with a different custom field plugin, and save those values to the newly registered ACF fields. After the hooks ran, there was no update showing on the backend, ie the values of the acf fields were still blank.

    I’m sure I’m missing something simple.


    function update_owner_name_value_update_field($post_id) {
        $old_owner_name = old_field_name;
        // verified: $old_owner_name returns string "DAVE"
        if( have_rows('field_q3md98zvnm241', $post_id) ) :
            while( have_rows('field_q3md98zvnm241', $post_id) ) : the_row();
                update_sub_field('field_4v8yw6n2hbpqs', $old_owner_name, $post_id);
    add_filter('acf/save_post', 'update_owner_name_value_update_field', 10, 1);

    …seems to be adding the value, but perhaps in a newly created field rather than the registered field.

    I could be wrong about that, but in the DB postmeta…
    string “DAVE”
    …NOTE the 0 in this meta_key

    This value does NOT appear for field_4v8yw6n2hbpqs (owner_name) on the backend post editor screen for the given $post_id following a save of that post. It can be accessed and returned using get_field with the same field key though.

    On the other hand, This…

    function update_owner_name_value( $value, $post_id, $field, $original ) {
        $old_owner_name = old_field_name;
        // verified: $old_owner_name returns string "DAVE"
        if( is_string($value) ) {
            $value = $old_owner_name;
        return $value;
    add_filter('acf/update_value/key=field_4v8yw6n2hbpqs', 'update_owner_name_value', 10, 4);

    …absolutely works!

    in the DB postmeta…
    string “DAVE”
    … no zero in this meta_key.

    The value for this DOES appear in field_4v8yw6n2hbpqs (owner_name) on the backend post editor screen for the given $post_id following a save of the post.

    I need to be able to use the first method (update_field function) to achieve the same basic result as the second method (acf/update_value hook), wherein the the value actually shows up on the post editor screen.

    Here’s my field registration function (reduced to focus on the owner_name field)…

    function register_custom_fields() {
        if (function_exists('acf_add_local_field_group')) {
                    'key' => 'group_5fd8be3a8aef1',
                    'title' => 'Dealer Fields',
                    'fields' => array(
                            'key' => 'field_q3md98zvnm241',
                            'label' => 'Additional Information',
                            'name' => 'additional_information',
                            'type' => 'group',
                            'sub_fields' => array(
                                    'key' => 'field_4v8yw6n2hbpqs',
                                    'label' => 'Owner Name',
                                    'name' => 'owner_name',
                                    'type' => 'text',

    This registration function runs on init, whereas the others are in an mu-plugin, and run on the hooks shown at priority 10. If this needs to be changed please advise.

  • The meta key additional_information_0_owner_name is for a repeater and the meta key should be additional_information_owner_name for a sub field of a group field.

    This makes me think that your group field is, for some reason, being confused for a repeater. I’ve looked at the code in ACF and there does not appear to be a reason for this and I do not see anything in the code you’ve supplied that should cause this.

    I would do this differently, instead of updating the value of this field when it is saved I would populate the value of this field when it is edited because you are doing this update when a post is saved. I would do this using and acf/load_value filter (priority > 10) for the new field. If the value is empty then I’d get the value for the old field and return it.

  • “your group field is, for some reason, being confused for a repeater”

    You get it! I sincerely appreciate the response. I believe acf/load_value would work, as acf/update_value works. I’ve just had some issues consistently accessing $field[‘key’], and in any case it really complicates the code. If we can get update_field working, that would be ideal. I’d really like to make sure I’m not misunderstanding anything before going any further with the plugin I’m working on, so I want to avoid workarounds. If you think I’ve misunderstood, please explain.

    After looking and looking, I have become fixated on the group in the field registration because I can’t find any documentation for how to register this…
    …via php.

    So now, I’m not sure how I came up with this…

    	'key' => 'field_q3md98zvnm241',
            'label' => 'Additional Information',
            'name' => 'additional_information',
            'type' => 'group',
            'sub_fields' => array(

    …outside of intuition. You say it looks right and it mostly works. It looks fine on the backend post editor. Something I forgot to mention is that when recalling the information that’s been manually saved, get_field works fine.

    $activeAddtlDetails = get_field('additional_information', $post_id);
    $activeOwnerName = $activeAddtlDetails['owner_name'];

    $activeOwnerName returns the owner name that was saved in additional_information_owner_name postmeta.

    Does this offer any clues?

    I should also mention that this…

    update_field('field_4v8yw6n2hbpqs', $old_owner_name, $post_id);

    …in place of the update_sub_field creates…

    owner_name | Another Test Owner Name
    _owner_name | field_4v8yw6n2hbpqs

    I think it’s interesting that either way it’s creating new postmeta rows with the correct information from the registered field, disregarding it’s placement in the schema.

  • I would give up on updating the row and instead update the entire group field, the only question would be what other fields are in that group. This should work.

    // this will hold the value to update the group with
    $group_field_value = array();
    // initialize row value just in case the loop returns noting
    $row = array();
    // loop group field and get existing values
    if (have_rows('field_q3md98zvnm241', $post_id)) {
      while (have_rows('field_q3md98zvnm241', $post_id)) {
        // this loop always happens 1 time for a group field
        // *********************************************************
        // little known fact
        // the_row() returns an array holding the row
        // with field keys as indexes and unformatted field values
        // *********************************************************
        $row = the_row();
    // set a new value for the "owner_name" field by field key
    $row['field_4v8yw6n2hbpqs'] = 'get old value and insert here';
    // update the field
    // update the group field
    update_field('field_q3md98zvnm241', $row, $post_id);
  • This makes sense looking at it, except for the $group_field_value = array() … I’m not seeing how that’s used(?) …

    That aside it seemed like it would work, but there is no change on the field in the post edit screen and there’s no obvious changes or additions in the postmeta.

  • Heh, ignore that, I changed thoughts mid code and did not go back to remove it. I was thinking about a repeater when I started wich requires an nested array of rows. I replaced that with $row = array()

  • Excellent! Works perfectly!

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

You must be logged in to reply to this topic.