search

MinnPost / object-sync-for-salesforce

WordPress plugin that maps and syncs data between Salesforce objects and WordPress objects.
https://wordpress.org/plugins/object-sync-for-salesforce/
GNU General Public License v2.0
95 stars 52 forks source link

WordPress Post Type in Fieldmapping Not Creating Correct WordPress Post Type in 2.x #418

Closed timnolte closed 3 years ago

timnolte commented 3 years ago

Describe the bug After upgrading to the 2.x version of the plugin I have found that specifically in the case where I have multiple mappings for a Salesforce Object to a WordPress Object, because of multiple Salesforce record Types, that when those records from Salesforce are being processed the resulting WordPress Post Type ends up being set as post, when logs and debug processing indicate that it should have created a Custom Post Type (e.g. sf_industry_location). I verified that reverting back to the 1.9.9 version of the plugin restored the proper WordPress Post Type is created.

To Reproduce Steps to reproduce the behavior:

  1. Setup 2 or more Fieldmappings to the same WordPress Custom Post Type against a Salesforce Object with multiple record Types. (1 mapping per record type.)
  2. Modify or create one of those records in Salesforce.
  3. Wait for the WordPress instance to pull the Salesforce change.
  4. Observe that a standard WordPress post is created and not the Custom Post Type specified in the Fieldmapping.

Expected behavior Post Types in WordPress should be create with the Post Type specified in the Fieldmapping as indicated and not fallback to a generic post.

Environment (please complete the following information):

Additional context I'm not sure if this has anything to do with #394

timnolte commented 3 years ago

I'm not sure if #414 is also related to this issue or not.

jonathanstegall commented 3 years ago

Maybe it's different though, since you specify that it's when the record type field is different.

jonathanstegall commented 3 years ago

So in your original thread, @timnolte, you were doing this with a filter. Are you saying the filter doesn't work anymore?

timnolte commented 3 years ago

@jonathanstegall so the filter I am using is the object_sync_for_salesforce_push_object_allowed. So it's on the push side of things where I was ensuring that the wrong field mapping didn't get triggered. This issue is when pulling records from Salesforce, and is new as of the 2.x version of the plugin.

jonathanstegall commented 3 years ago

Okay. Well, I am going to do some work on how option keys get generated to hopefully deal with #414, but I don't know that that will be related to this. I can say that #394 is not happening until there's a bigger interface update, which I'm not sure about.

In any case, I don't know of anything that should have changed how this works in 2.0 (or higher) compared to 1.10.x, but I'm still a little surprised that this ever worked. Would appreciate if you are able to track down what the breaking change was, since it is a thing that has worked for you.

timnolte commented 3 years ago

@jonathanstegall OK, so perhaps this happened before 2.x as I didn't even realize there was a 1.10.x version. I. Your tags history there was an older incorrectly tagged 1.18 version, which I think was supposed to be 1.1.8, and since we install plugins via Composer this was constantly causing issues with getting the plugin stuck on an old version. The newest version of the plugin that we've been running was 1.9.9. So all I can confirm is that this issue starts happening after 1.9.9.

jonathanstegall commented 3 years ago

Since 1.10 was very small and 2.0.0 was very large, I think it's very unlikely it was not in 2.0.0, but who knows. Whatever version it was, if you're able to identify what the breaking change was, that would be super helpful.

jonathanstegall commented 3 years ago

Actually, @timnolte, I think I've got a fix for this, if you could test it, in #419.