As outlined in some other topics here, there has been a problem with field data population when creating new posts.
My situation deals with creating posts for new vehicles as an inventory system. Some data is stored in the post itself (title, content) and the remaining vehicle details are stored in ACF fields.
For some reason, fields don’t seem to populate properly when a post is freshly inserted – calling update_field('field_legiblename', $value) won’t actually populate the field with data. As a workaround, I created a lookup table that equates the raw field ID with the legible name, so instead I end up calling update_field('field_533c93f263489', $value) which DOES populate the field properly. Only once a post has been manually saved can ACF properly execute its update_field() function, and I believe that this is due to mismatched meta key/value pairs for the ACF fields.
I was hoping that ACF5 would solve this problem due to the way that ACF field data was stored. However, now I have this problem to a more extreme degree – data intermittently populates the appropriate fields, and the ACF data isn’t even visible on the front end until each post is manually saved… not even firing the save_post hook will update this properly! As a result, the hundreds of vehicles I am importing data for have improper storage and I have to go through each post and update it (Quick Edit doesn’t work either).
@elliot – can you offer any insight as to why this might be happening?
edit: solved the intermittent population issue – some field IDs updated during the upgrade
Hi @emcniece
The field_key instead of field_name issue is outlined in this doc http://www.advancedcustomfields.com/resources/functions/update_field/ and I will take a look at adding in functionality to step around this problem.
As for your solution, I’m glad you have found one. Just to confirm, when you upgraded from v4 to v4, you got multiple field’s with the same key?
Were these the newly created fields which got the same key? If so, how many fields got the same key?
Hey @elliot, thanks for stopping by.
The update_field documentation you have just provided is precisely the situation I’m dealing with, and it helped me sort this out in the past. There is a new problem since upgrading to v5 however! Previously, data could be saved properly by using the field_key and users would be able to immediately view the front end and see the content that was retrieved using the field_name. Now with v5, the data is not visible on the front end unless each post is manually updated after populating the ACF fields. Interestingly, get_field($field_key) is not working either.
Was there a change to the way that update_field() performs in respect to the save_post hook?
In regards to the updated field keys – closer investigation reveals that the keys were simply updated for a few fields, no fields had duplicate keys. This makes sense though – the field keys that changed were those belonging to Repeater and Gallery fields… I would expect that the new v5 system recreated the fields in migration 🙂
I’ve made some progress – ACF fields must be added to the post following the wp_insert_post() call if they are to be used in the theme!
In V4, it seems that calling update_field would add the data to the post and calling get_field() ultimately returned something regardless of whether the post had been updated or not.
In V5, calling get_field() on uninitialized fields will return NULL until the post is updated through the WP admin!
My theme was doing logic checks to see if a field was true or false before printing some text. Before upgrading, it didn’t matter if the ACF field was actually populated with data, but now it seems that the field will not return a boolean value (instead returns null) if update_field() was never called.
Simple solution – call update_field() on all ACF fields directly following the wp_insert_post() call!
Hi @emcniece
Aah, I think I understand the issue now.
In version4, AF would return false if the value did not exist in the database. This has been changed to null for better data validation.
If you allow for any false value in your if statement, you will be fine:
if( ! get_field('field_name') ) {
}
