Validate contact_id stored in WP Fusion

[pety-dc]

Problem: WP Fusion doesn't follow mautic contact merges

Solution: Validate contact_id stored in WP Fusion and if the contact_id is invalid, consider it as if no contact_id value was stored before and continue on requesting contact_id from the CRM (search by email)

tl;dr Mautic sometimes performs contact merges. This may happen for example if a user visits the page from a different device and after a few tracked pageviews (Mautic tracking must be active) the user logs in the user gets identified by email and mautic merges the current anonym tracked contact with the contact that was already stored with email. If the former contact came out from the merge as winner (mautic keeps the winner's contact_id) it would cause inconsistency with the contact_id that is stored in WP Fusion.

It seems to me that WP Fusion doesn't handle if a contact_id stored in WP Fusion to a user does not exists anymore. This case simply causes update errors.

To solve this validate_contact_id is added to the common get_contact_id function to check whether the contact_id stored in WP Fusion is still exists in Mautic. If the contact_id happens to be invalid the validate_contact_id return false which results in the same situation as if there was never a stored contact_id. The get_contact_id continues on requesting contact_id from the crm by email.

[verygoodplugins]

Hey @pety-dc ,

Thanks for chipping in!

So... this one is trickier. We can't do a remote API call to check the contact ID every time get_contact_id() is run, because it can happen multiple times on a normal page load, and it would be a serious performance bottleneck.

Since with most of our supported CRMs, merging and de-duping is a manual process, we recommend to people to run a Resync Contact IDs & Tags operation from the Advanced tab in the WPF settings after any merges, to fix the contact IDs.

Since that happens automatically with Mautic it's a bit different. What really needs to be done is to check the API responses from update_contact(), apply_tags() and remove_tags() in WPF_Mautic. If the response indicates the contact has been merged (I believe it's an HTTP 204), then the new ID should be loaded.

So... how that should be done is that if update_contact() or the other methods finds that the record has been merged / no longer exists, it returns an alternate error type, for example

return new WP_Error( 'not_found', $body->errors[0]->message );

Then in WPF_User it checks the response. If the response is a WP_Error of type not-found then it runs $this->get_contact_id( $user_id, $force = true ) , and if it finds a valid contact ID it re-runs the API call. If not it fails gracefully with an error message.

We just hadn't gotten around to that yet because it should really be updated for all the CRMs. But I've made a note to give it a try for Mautic for the next release. If you'd like to open a PR and take a stab at it as well you're quite welcome.

[Tamas-Toth-ebola]

Dear VeryGoodPlugins!

Thanks for your explanation, where the possibly performance issue is absolutely true. As I sadly did not read your whole comment just the start of it (sorry) we (with @pety-dc) made an instant and quick verbal brainstorming about the situation where our simple result was the same what you wrote (just I had read it later) that in this case just need to verify the Mautic response of the update request.

If you could fix this in the near future would be very welcomed as we try to use your paid product but currently these Mautic problems make us it a little bit 'hard' or uncompleted.

Lot of thanks for your honest response and really hope in the fix.

[verygoodplugins]

@ebola-dc @pety-dc , Yes, we've made that change today. WPF will check for a "Not found" message in the response from the update_contact() call, and if the contact isn't found it will force-check the contact ID and run the API call again if a new contact ID is found.

[pety-dc]

Thanks, @verygoodplugins

[Tamas-Toth-ebola]

Thanks again!

If this is the real situation I think the issue/PR could be closed now.

Thanks again!