2

I have recently migrated a CiviCRM instance from Joomla to Wordpress, everything went smoothly.

The installation is using CiviCRM 5.7.2 and PHP 7.2.

We're now seeing a peculiar problem where, when users are making general use of CiviCRM, literally 100s of duplicate contacts are created of whichever user is working.

The duplicates accumulate very quickly. In about 10 minutes of experimentation with CiviMail today, I managed to create 249 duplicate contacts of myself.

In testing for this question, I created 25 contacts simply by searching for 'contacts created today' in advanced search.

Just about any action appears to create these duplicates.

When deleting them, CiviCRM will warn me that 'you are currently logged in as' one of the duplicates and therefore it cannot be deleted. Obviously my user account should not be associated with a just-created contact.

My guess is that this may be caused by something like a missing database constraint, but I'm at a bit of a loss as to where to start looking.

Any ideas?

2 Answers 2

7

I have seen this when the uf_match table does not have the proper values for WP Id (uf_id), Contact ID (contact_id) and email (uf_name).

I don't know why this occurs, I've not been able to track it down, but I suspect it is when the uf_id and contact_id do not have the email in use by WP.

You can user API Explorer /wp-admin/admin.php?page=CiviCRM&q=civicrm/api to display the records or do a query on the civicrm_uf_match table.

To fix, I have deleted the 'bad contacts (merging if data needs to be retained) and then updating the uf_match records so this does not re-occur.

2
  • 1
    That will be it. I did not update the contact IDs in that table when I moved to Wordpress, so the IDs refer to Joomla user IDs, not Wordpress Users. Seems obvious now that I should have done that, but I don't believe it was in the instructions I followed. Thank you!
    – fred2
    Commented Dec 15, 2018 at 17:56
  • 1
    @fred2 It is mentioned here: docs.civicrm.org/sysadmin/en/latest/misc/switch-cms/… but if you can improve the documentation, please submit a change.
    – Aidan
    Commented Dec 17, 2018 at 8:48
1

A ticket describing this bad behavior now exists at https://lab.civicrm.org/dev/core/-/issues/4500 , which describes the technical causes of the bad behavior, mentions another set of actions that can lead to this problem, and provides an alternative workaround (manually updating the values in civicrm_uf_match via SQL).

Hopefully it will also serve as a focal point for moving toward a fix and/or standardized "best practices" to avoid or resolve this issue if/when it arises.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.