colorcrate
Forum Replies Created
-
No worries, I think we can work with prematching on a default WP field
Do you have any input regarding (non-ACF) custom fields not updating their contents when a post is successfully prematched and data has changed?
A couple of additional notes (maybe helpful, maybe not!)
• It looks like if I pass data to plain old custom fields (not created through ACF), prematching still doesn’t work on those custom fields, even if the SF field is required (eg. Account ID).
• If I make an update to a piece of data on SF which triggers a pull, that data will be correctly updated on WordPress if it is mapped to a default WP field (ie. post title, post content, post excerpt, etc), but it still won’t be updated if it’s mapped to a traditional custom field, even if that field wasn’t created through ACF.
Hey @jonathanstegall, thanks for the reply! We’re using ACF to create the field using the acf_add_local_field_group function (https://www.advancedcustomfields.com/resources/register-fields-via-php/), and out of the two fields it creates (_business_id and business_id), we’re using the one without the leading underscore.
I just tried mapping the Account ID into the post_excerpt field instead and that works as far as prematching is concerned! However now I’m running into another issue with meta fields updating properly.
When we pull data from SF the first time, a post is created successfully and all the meta fields are filled out with their data correctly according to the mapping. However when a piece of data is updated in Salesforce (say the business name), and a subsequent pull is triggered, I see a “successful upsert” message in the plugin log, but the business_name field doesn’t actually update to reflect the change on WordPress.
On the other hand edits made to fields that map to standard WP fields (ie. post title, post content, post excerpt, etc), work just fine.
Is there a better/different way we can create these fields that will play more nicely with the plugin?
Thanks so much for your help!