amddtim

I’m realizing that $synced_object[‘mapping_object’] is empty when a WordPress post has been created for the first time (as opposed to being updated), which sort of defeats my purpose for attempting to publish the WordPress post on this successful pull filter. Does that sound correct?

Great. Let me take a peek and let you know.

Right, but I’m not trying to do an actual sync to Salesforce, I just want to pull. So if Salesforce creates a post in WordPress, and then I delete that post, you’re saying the plugin won’t ever recreate that post when the object gets updated in Salesforce?

How do I reset the mapping/connection?

• This reply was modified 8 years, 5 months ago by amddtim.

Sorry, maybe I wasn’t clear (or I’m not understanding what you’re saying), but I deleted the posts on the WordPress side, not the Salesforce side. Basically, I wanted to start with a new import, but the original Salesforce objects didn’t change. But having deleted the WordPress posts, it seems like Salesforce, having mapped to the ids with a key, doesn’t realize the WordPress posts don’t exist.

Hmm, maybe I need to go about this another way. Instead of using that field to determine whether a WordPress post should exist, can I publish or unpublish the post depending on the Salesforce value? I noticed that when creating a new post in WordPress, it’s set to ‘draft’ by default. At the very least, I need new posts to be published so that I don’t need to manually publish them.

Thanks, I saw this too. The sticky part is I need access to a variable that’s getting set with javascript, which is then filtering the alm instance. So I can’t set a session variable in the parent page template file and just be okay. If I’m using sessions, I have to set a session variable each time a button is clicked that toggles the filter. Does that make sense?

How is it that you have 4 variables available in the repeater templates and no more? Couldn’t I conceivably edit the plugin to pass something else along? I tried looking through the plugin files and couldn’t find where I might do that.

Thanks for the quick reply.

Yeah, I have mapped some ACF fields and saw at least half success. The thing that worried me is that normally saving an ACF field in the backend also creates a corresponding underscored field with the ACF field_key. It seems like that would be integral to ACF, which is why I wanted to go the update_field() route.

I guess I’ll try adding my own function, like reorder_params_update_field(). Remind me which hook would be the best place to add that function for each mapped field…?

Do you know if the responsive extension would suffer the same problem? If I can’t get the fixed column to work, a backup option would be to just have a responsive scroll.