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

[timnolte]

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):

• WordPress Version: 5.8
• Object Sync for Salesforce: 2.x
• PHP Version: 7.4

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

[timnolte]

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

[jonathanstegall]

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

[jonathanstegall]

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

[timnolte]

@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]

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]

@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]

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]

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