Sync always creates new record

[nodakjones]

I'm pulling records from SF to WP. It seems from your documentation (https://github.com/MinnPost/object-sync-for-salesforce/blob/master/docs/syncing-setup.md) that I should set a field that holds the SF Record ID in my mapping and use this field for upserts?

Expected behavior

When a record is changed in SF, existing WP records should be updated

Actual behavior

When a record is changed in SF, always a new records is being created in WP

Steps to reproduce behavior

1. Set up mapping per attached image
2. Create record in SF
3. Observe that record is created in WP
4. Update record address in SF
5. New record is created in WP instead of updating existing record.

[nodakjones]

For the Salesforce pull process, In your docs it says, "Upsert is used with the Prematch field defined above (the Salesforce Key field is ignored on pull operations)". So, this tells me I need to set a prematch field. We are getting the the ID from SF into our external_id_from_sf field so that is working correctly. I realize per your documentation that the Salesforce Key is ignored, so I didn't need that checked. I've tried multiple combinations of Direction, but it seems that I really just need Salesforce to Wordpress. Also, I've checked the asynronous because it sounded like on another issue that was potentially a problem. I'd prefer to not have to jump into a hook to further define my sync criteria because it seems this should work out of the box... I'm just missing something simple? Thank you so much for your help!

[nodakjones]

Also, the debug log is showing: Success: Upsert WordPress duplexes with ID of 19303 (Salesforce Duplex__c Id of a00f400000E40gHAAR). However, 19303 is a new record (post with post type of duplexes). So, it was not Upserted, but Inserted.

[jonathanstegall]

@nodakjones I think you've found a bug here that happens when trying to match against post metadata fields.

I should be able to have a fix for this in the next few days. Possibly tomorrow, but early next week if not. Do you have any interest in testing the fix via GitHub before we release a new plugin version?

[nodakjones]

Yes. I’d be happy to test.

Eric C Jones

Managing Partner
Data Imagery data-imagery.com(http://www.data-imagery.com) eric@data-imagery.com(mailto:eric@data-imagery.com)
253-461-1110(tel:253-461-1110)

On September 27, 2018 at 10:43:18 PM, Jonathan Stegall (notifications@github.com(mailto:notifications@github.com)) wrote:

@nodakjones(https://github.com/nodakjones) I think you've found a bug here that happens when trying to match against post metadata fields.

I should be able to have a fix for this in the next few days. Possibly tomorrow, but early next week if not. Do you have any interest in testing the fix via GitHub before we release a new plugin version?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub(https://github.com/MinnPost/object-sync-for-salesforce/issues/200#issuecomment-425327324), or mute the thread(https://github.com/notifications/unsubscribe-auth/AAFSFze129lvLwDAReTPTSLyPIJ-tNa-ks5ufbb2gaJpZM4W9HVw).

[jonathanstegall]

@nodakjones great. I've got a branch for this issue here. I'd love to see if it behaves as expected for you.

[nodakjones]

Thanks! I downloaded the branch into my plugins dir and when I activated, I got the following error:

Warning: require(/var/www/duplexesoftexas.com/public_html/wp-content/plugins/object-sync-for-salesforce-200-prematch-against-meta-fields/vendor/prospress/action-scheduler/action-scheduler.php): failed to open stream: No such file or directory in /var/www/duplexesoftexas.com/public_html/wp-content/plugins/object-sync-for-salesforce-200-prematch-against-meta-fields/vendor/composer/autoload_real.php on line 66

Thoughts?

[jonathanstegall]

Do you know how to use composer? You can fix by running composer install in a command line to install the libraries. It'll be tricky to test via GitHub without that, but let me give it some thought.

[jonathanstegall]

@nodakjones Ok, you can download from that branch now, and it will have all the composer libraries without you needing to install them.

[nodakjones]

Oh. Sorry. Got composer to work. But syncing stopped so I’m troubleshooting that now.

On September 28, 2018 at 12:01:24 PM, Jonathan Stegall (notifications@github.com(mailto:notifications@github.com)) wrote:

@nodakjones(https://github.com/nodakjones) Ok, you can download from that branch(https://github.com/MinnPost/object-sync-for-salesforce/tree/200-prematch-against-meta-fields) now, and it will have all the composer libraries without you needing to install them.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub(https://github.com/MinnPost/object-sync-for-salesforce/issues/200#issuecomment-425534881), or mute the thread(https://github.com/notifications/unsubscribe-auth/AAFSF3vvEiUaLWOhPWkYAVuy5IfesrxXks5ufnIEgaJpZM4W9HVw).

[nodakjones]

Ok, so this update didn't work. I created a record in SF and it synced over and my external ID from SF came through correctly into the post meta. Then I edited the address in SF. The logs say Success: Upsert WordPress duplexes with ID of 22770 (Salesforce Duplex__c Id of a00f400000E426EAAR). But 22770 is the ID of a new post (which has the new edited title). The existing post was not edited and has the same title.

[jonathanstegall]

@nodakjones is the post being created as a draft? If it is, you’ll want to resave the field map and make sure the pull to drafts box is checked. I should’ve mentioned that in case it applies to you.

[nodakjones]

Yes, drafts was a part of the problem. We handled this by setting a default field in salesforce with a value of publish and then synced that field over in the mappings. Now it seems it is finding the correct post id for an upsert, but it giving an error and not actually doing the update. Unfortunately the error is very vague:

Object: duplexes with ID of 26122

Message: Array ( [0] => Array ( [key] => external_id_from_sf [value] => Array ( [value] => a00f400000E43zoAAB [method_modify] => update_post_meta [method_read] => get_post_meta )

)

)

[jonathanstegall]

Thanks for trying this. I'm assuming the title of the error log was something like "Error syncing: pull to WordPress (Salesforce [object name] Id [sf id])" and then the message body was what you pasted.

If that is correct, I'm actually not sure why it's happening. This log shouldn't ever happen, which is why it's a vague error message. It should be printing the $result['errors'] array, which is what you're seeing. At this stage, $result is coming from the attempt it makes to save the post, but the only time errors gets populated when WordPress runs its own create or update methods.

To me, your error log looks like it's not up to date with the changes in this branch. It should contain a method_match parameter in that array if there is a prematch field.

I'm not entirely sure what to tell you at this point. I'm assuming you have already resaved the field map and cleared the plugin cache.

Are you seeing any PHP errors in your server logs for any of this?

[jonathanstegall]

I'm curious about possible ways to move this forward. Here's what I can think of, off the top of my head.

If you'd like to do further testing before release:

1. You could re-download the plugin from this branch just to make sure (no composer should be needed for this branch, now).
2. You could then resave your existing fieldmap, and/or create a new fieldmap with conditions where this branch would apply.
3. Either way, you could check the wp_object_sync_sf_field_map table in the database. Make sure it has a pull_to_drafts field with a value of 1 and a version field with a value of 1.5.0.
4. You could also search the fields column in the same table for the value "match". A SQL query to do this would be select * from wp_object_sync_sf_field_map WHERE fields LIKE '%"match"%'; and if it does not return any results when a prematch field is selected, the data is not stored in an up to date way.

This would allow you to make sure the code and data structure is up to date. Then you could see if it's still behaving as in the log message above, either with a resaved fieldmap and/or a new fieldmap.

If you don't want to do further testing, we could:

1. Release a new version of the plugin.
2. It's possible your plugin is missing something that would occur in the activation hook if you installed the update from the plugin directory (if this turns out to be the case, it'd be great to find out what it was that required this).

It's certainly possible that some other factor is causing the issue for you, and perhaps it would be easier to find it after a new release. But I'm inclined to think it's worthwhile since the worst case scenario appears to be that in some case the bug exists as it currently does without being fixed, while in others it is fixed.

If I don't hear from you in by early next week I'll go ahead and release this as an update release and I'll go from there.

[nodakjones]

1. I re-downloaded the plugin.
2. I deleted the existing field mapping and re-added a new one
3. Version is 1.5.0.  I’m pulling in the posts now as publish.  So, I would think pull_to_drafts should be 0?  Either way I’ve performed a test with the pull_to_drafts set to 0 and to 1
4. Running the sql query you provided does return the single record I have in the wp_object_sync_sf_field_map table.

Things still aren't working. Each time I edit the record in SF it creates a new record in WP.  The logs say this:

Success: Create WordPress duplexes with ID of 28865 (Salesforce Duplexc Id of a00f400000E4QQcAAN) Success: Create WordPress duplexes with ID of 28860 (Salesforce Duplexc Id of a00f400000E4QQcAAN)

You will notice that in each case the SF record id is the same.  I’m seeing that SF record id is correctly being stored each time in the post meta.  

It seems like you should be able to replicate my case:

1.  I’m using a custom post type (shouldn’t matter but just to make sure)
2.  I have a simple mapping
   • Mapping from my custom object in SF to my custom post type in WP
   • Date field to trigger pull: Last Modified Date
   • Fieldmap - sf id ( this is set the Salesforce Key), name, status (this is a formula field in SF set to publish so that we are confusing issue with drafts)
   • I have all fields direction set from Salesforce to WordPress
   • action triggers are Salesforce create, Salesforce update, Salesforce delete
   • I’ve tested with pull_to_draft checked and unchecked
3.  Create a new record in the salesforce object.  I see new record come to WP and it correctly has the sf id post meta field populated
4.  Edit the SF record, new post record is created in WP instead of editing the existing record.

On October 5, 2018 at 1:30:30 PM, Jonathan Stegall (notifications@github.com) wrote:

I'm curious about possible ways to move this forward. Here's what I can think of, off the top of my head.

If you'd like to do further testing before release:

You could re-download the plugin from this branch just to make sure (no composer should be needed for this branch, now). You could then resave your existing fieldmap, and/or create a new fieldmap with conditions where this branch would apply. Either way, you could check the wp_object_sync_sf_field_map table in the database. Make sure it has a pull_to_drafts field with a value of 1 and a version field with a value of 1.5.0. You could also search the fields column in the same table for the value "match". A SQL query to do this would be select * from wp_object_sync_sf_field_map WHERE fields LIKE '%"match"%'; and if it does not return any results when a prematch field is selected, the data is not stored in an up to date way. This would allow you to make sure the code and data structure is up to date. Then you could see if it's still behaving as in the log message above, either with a resaved fieldmap and/or a new fieldmap.

If you don't want to do further testing, we could:

Release a new version of the plugin. It's possible your plugin is missing something that would occur in the activation hook if you installed the update from the plugin directory (if this turns out to be the case, it'd be great to find out what it was that required this). It's certainly possible that some other factor is causing the issue for you, and perhaps it would be easier to find it after a new release. But I'm inclined to think it's worthwhile since the worst case scenario appears to be that in some case the bug exists as it currently does without being fixed, while in others it is fixed.

If I don't hear from you in by early next week I'll go ahead and release this as an update release and I'll go from there.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jonathanstegall]

Have you already tried with your "sf id" field as a prematch field instead of as a Salesforce key field? That is the main difference I'm seeing.

[nodakjones]

I have both the prematch and sf key field checked on the id in the mapping. 

Now, in the log when I create the record in SF I see the following:

Error syncing: Upsert to WordPress (Salesforce Duplexc Id a00f400000E4QbjAAF) Success: Upsert WordPress duplexes with ID of 28899 (Salesforce Duplexc Id of a00f400000E4QbjAAF)

Then when I update the same record in SF, I see the following in the log:

Error syncing: Upsert to WordPress (Salesforce Duplex__c Id a00f400000E4QbjAAF)

On October 8, 2018 at 8:36:05 AM, Jonathan Stegall (notifications@github.com) wrote:

Have you already tried with your "sf id" field as a prematch field instead of as a Salesforce key field? That is the main difference I'm seeing.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jonathanstegall]

Ugh, I think I found/fixed the issue. I was able to have the same problem anyway, and fix it. I think I forgot to commit some lines to the git repo that I had and lost, so if it works, thanks!

Anyway, if you can download the wordpress.php file (here's the raw code URL), let me know if that fixes it for you.

[nodakjones]

I replaced the wordpress.php file.  Now, not getting the error in the log.  However, still upserting to a new WP post when editing the SF record instead of changing the existing WP post.

Success: Upsert WordPress duplexes with ID of 29049 (Salesforce Duplexc Id of a00f400000E4R75AAF) Success: Upsert WordPress duplexes with ID of 29045 (Salesforce Duplexc Id of a00f400000E4R75AAF)

On October 8, 2018 at 12:09:32 PM, Jonathan Stegall (notifications@github.com) wrote:

Ugh, I think I found/fixed the issue. I was able to have the same problem anyway, and fix it. I think I forgot to commit some lines to the git repo that I had and lost, so if it works, thanks!

Anyway, if you can download the wordpress.php file (here's the raw code URL), let me know if that fixes it for you.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jonathanstegall]

Okay. Here's what is working for me. Maybe we'll find something revelatory:

1. I have a custom post type called "apps" that is mapped to the Salesforce Lead object.
2. I'm using CMB2 to create these custom fields: First Name, Last Name, Company, Lead ID, and Post Status. Each is mapped to its corresponding field on the Lead object with Salesforce to WordPress as its direction.
3. Post Status in Salesforce has a default value of "publish"
4. The Lead ID field has Prematch checked.
5. Triggers checked are Salesforce create, Salesforce update, Salesforce delete.

I cleared the plugin cache after adding the post status and lead ID fields, as I was previously matching on the company field.

When I create a new lead in Salesforce, I get this log:

Success: Upsert WordPress app with ID of 306 (Salesforce Lead Id of 00QW0000007I9oyMAC)

When I update that same lead in Salesforce, changing the values for first name, last name, and company, I get this log:

Success: Update WordPress app with ID of 306 (Salesforce Lead Id of 00QW0000007I9oyMAC)

I can try with a custom Salesforce object. I don't foresee that making a difference, but it's worth a shot. Do you see any other differences?

[nodakjones]

I tried with the lead object and I’m getting the same result.  Do you have Salesforce Key checked for the ID field?  Also, what is your direction set to?

On October 8, 2018 at 1:35:24 PM, Jonathan Stegall (notifications@github.com) wrote:

Okay. Here's what is working for me. Maybe we'll find something revelatory:

I have a custom post type called "apps" that is mapped to the Salesforce Lead object. I'm using CMB2 to create these custom fields: First Name, Last Name, Company, Lead ID, and Post Status. Each is mapped to its corresponding field on the Lead object with Salesforce to WordPress as its direction. Post Status in Salesforce has a default value of "publish" The Lead ID field has Prematch checked. Triggers checked are Salesforce create, Salesforce update, Salesforce delete. I cleared the plugin cache after adding the post status and lead ID fields, as I was previously matching on the company field.

When I create a new lead in Salesforce, I get this log:

Success: Upsert WordPress app with ID of 306 (Salesforce Lead Id of 00QW0000007I9oyMAC)

When I update that same lead in Salesforce, changing the values for first name, last name, and company, I get this log:

Success: Update WordPress app with ID of 306 (Salesforce Lead Id of 00QW0000007I9oyMAC)

I can try with a custom Salesforce object. I don't foresee that making a difference, but it's worth a shot. Do you see any other differences?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jonathanstegall]

The direction for all my fields is Salesforce to WordPress. I do not have Salesforce Key checked, but I do have Prematch checked. As you mentioned earlier from the docs, Salesforce Key doesn't do anything on pull operations.

[nodakjones]

Yes, I was just making sure.  I have the same settings but it always creating the new wp post instead of editing.

On October 8, 2018 at 2:36:37 PM, Jonathan Stegall (notifications@github.com) wrote:

The direction for all my fields is Salesforce to WordPress. I do not have Salesforce Key checked, but I do have Prematch checked. As you mentioned earlier from the docs, Salesforce Key doesn't do anything on pull operations.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[nodakjones]

I tried with the Lead object and received the same result.  The only other thing that I can think of that would be different is that I’m using ACF instead of CMB2 for the post meta.  Both are interacting with the post meta in the same way so I can’t imagine that would be the difference.

On October 8, 2018 at 2:36:37 PM, Jonathan Stegall (notifications@github.com) wrote:

The direction for all my fields is Salesforce to WordPress. I do not have Salesforce Key checked, but I do have Prematch checked. As you mentioned earlier from the docs, Salesforce Key doesn't do anything on pull operations.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jonathanstegall]

I made an ACF version on a test site with a new SF object.

Duplex object in SF:

1. Status field with value of publish
2. Duplex Name field

Duplex object in WordPress:

1. Field group called Duplex Settings
2. A Name field (I tried this in case it made a difference to use a custom field instead of the post title)
3. A Salesforce ID field

Fieldmap:

1. name <- Duplex Name
2. salesforce_id <- Record ID
3. post_status <- Status

All of these are direction Salesforce to WordPress. The prematch is on salesforce_id. Triggers are Salesforce create, Salesforce update, Salesforce delete.

When I create a duplex record in this way, I get:

Success: Upsert WordPress duplex with ID of 340 (Salesforce Duplex__c Id of a0YW00000033vE8MAI)

When I update the record in Salesforce, I get:

Success: Update WordPress duplex with ID of 340 (Salesforce Duplex__c Id of a0YW00000033vE8MAI)

[nodakjones]

Wow, I really can’t see what would be different from your setup.  I don’t have a lot going on in terms of plugins, but I’m going to do the same thing with a clean install and see if I can get this to work. 

On October 9, 2018 at 6:25:29 AM, Jonathan Stegall (notifications@github.com) wrote:

I made an ACF version on a test site with a new SF object.

Duplex object in SF:

Status field with value of publish Duplex Name field Duplex object in WordPress:

Field group called Duplex Settings A Name field (I tried this in case it made a difference to use a custom field instead of the post title) A Salesforce ID field Fieldmap:

name <- Duplex Name salesforce_id <- Record ID post_status <- Status All of these are direction Salesforce to WordPress. The prematch is on salesforce_id. Triggers are Salesforce create, Salesforce update, Salesforce delete.

When I create a duplex record in this way, I get:

Success: Upsert WordPress duplex with ID of 340 (Salesforce Duplex__c Id of a0YW00000033vE8MAI)

When I update the record in Salesforce, I get:

Success: Update WordPress duplex with ID of 340 (Salesforce Duplex__c Id of a0YW00000033vE8MAI)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.