Support

Account

Register Login

Home › Forums › Feedback › update_field() clarification

Solving

update_field() clarification

  • Hi community, to be honest, I am aware about the docs explaining this function, but after some tests, I am confused when to use the “field key”. The docs argument that this should be used when it is a “NEW” value.

    I am considering a “NEW” value, i.e. a custom post “MyCustomReport”, and I recently added the field “last_viewed” where I want to update with a “current date”.

    btw, I am using the DateTime field for my custom post type.

    Then I am using 

    $now_value = current_time("Y-m-d H:i:s");
update_field("last_viewed", $now_value, $this->_wp_id);

    in my script, what creates the right entry for “last_viewed”, and a “_last_viewed” field reference with a value “field_5ac3e2a8a9656”.

    then I go to the database and erase those 2 rows (last_viewed and _last_viewed)
    then I run the script again, and the fields are created again.

    So I am not sure if it is entirely necessary to use
    update_field(‘field_5ac3e2a8a9656’, $value);
    or in which circumstances this is absolutely necessary.

    Thank you for any clarification on this matter.

  • This all depends on where this is happening.

    For example, if you can see the ACF field on the page that you’re submitting, then the field and key reference are being created when you click on the update button. You are in fact updating a field that already exists in the database.

    Before updating the value you can probably see this with something like

    

echo 'is it set?<br />';
echo 'last_viewed = ',get_post_meta($this->_wp_id, 'last_viewed', true),'<br />';
echo '_last_viewed = ',get_post_meta($this->_wp_id, '_last_viewed', true),'<br />';

$now_value = current_time("Y-m-d H:i:s");
update_field("last_viewed", $now_value, $this->_wp_id);

    You need to use the key only under conditions where the field is guaranteed to not exist. This can happen when you are creating posts in code.

  • Hey John!, thankx for your response. I totally understand what you are saying, but I am in fact doing everything in code. (there is no update button).

    Maybe the only situation you might be refering to, is when the field was created at a later stage, then updated the post throught the admin, then delete the two rows from the database, and then update it again in code. <- this is what I did in my local environment, and as I said the fields created without issues.

    What I am going to do next is to update with code in my remote environment without adding the field data in the post, then check if there is an issue. <- this has to be the cleanest, non-existent data-field whatsoever. (I am really hoping something will go wrong in that scenario) otherwise, I will still be confused about when to use the field reference…

  • I have seen issues on and off when using the field name in the past, for this reason I haven’t actually used a field name for update_field() in a very long time and I always use the field keys. It just avoids any potential issues and me needing to dig around in code and figure out why it’s not working in some specific case. I just include comments in my code about what field key belongs to what field name.

    I’ve also done things like set up arrays

    
$fields = array(
  "{$field_name}" => "{$field_key}"
)

    So that I can refer to the field name like

    
update_field($fields[$field_name], $value, $post_id);

    As far as I’m aware, and I’ve looked into the code of ACF and I don’t see anything that suggests otherwise, if you use update_field() with a field name and the meta_key "_{$field_name}" does not exist for $post_id then ACF will not create the correct field reference. It will create the meta_key "_{$field_name}", but this entry in the database will have an empty field value rather than containing the correct field key.

    Under these conditions, some fields will work and some fields will not work. It really depends on the field type and how the data is stored. It can really be hit or miss. In the case of fields that contain text, or something that is simple text, and this includes a date/time field, acf will simply return whatever text value is stored in the database. The reason for this is that without the correct field key ACF does not know what to do about formatting the value so it just assumes it’s a text based field.

    Rather than figure it out on a field-by-field basis whether you can use the field name or need to use the field key, it’s just simpler to always use the field key.

  • Yes, I used to have a project where I definitely used the field references and it was a mess, because the site lived in a local, test, stage and production environments, and obviously the field hashes didnt match at all, so update script files had to be updated frequently. I was just hoping to find an easy way to handle this. I also didn’t find any api function to get the field reference name, do we have to look for it always in the database? or there is a special function to get it?

  • You can get the field key in the admin where you create the fields, you can show them under screen options.

    I generally do not have an issue with live/staging/dev because my field keys are always the same in all environments. I guess this depends on how you transfer data between them.

    It could be possible, using code to get the correct field reference after the post is created, but it’s not all that easy and would take a lot of resources/db queries to achieve, and it would be specific to the version of ACF you’re using (4 or 5)

  • You can get the field key in the admin where you create the fields <- this is a nogo, overkilling workflow for a deployment script.

    Unfortunately, my expected behavior on updating an existent POST / un-existent custom field in production, did not caused an issue and correctly created the field reference “field_5ac3e34638087”.

    So I am still confused when we HAVE TO use the field for updating records.

    The only scenario left I could think of, is when the field does not exist at all, and then you try to update it, then it would make sense to go and create one manually or programatically, and then update it.

    Thnks for any comment you may have on this.

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

The topic ‘update_field() clarification’ is closed to new replies.