4

I have a WordPress website with large CiviCRM database. For some reason, CiviCRM is reading one of my Administrators as a contact name (not matching his name) and every time I try to delete him and make him a new user, it matches him to another contact (not his). How can I find a fix for this issue?

  • not sure about WP but with a drupal set up there is a uf_match table that joins the civi contact to the cms user. if you can access that table you may be able to correct the miswiring of the Admin – petednz - fuzion Jun 8 '18 at 20:43
4

Every WordPress (or other CMS) user gets a CiviCRM contact, even though not every contact corresponds to a user. The only tool CiviCRM has for making these matches is the email address. Once CiviCRM is installed, whenever a new WordPress user is added, CiviCRM will find or create an individual contact with that email address.

If you have a lot of contacts with this person's email address and/or if his contact has a different email address, you may run into issues. You also may have another user already connected to his contact record. Pete's suggestion about the civicrm_uf_match table is a good one: that's the table that connects the user to the contact.

Assuming you have a user account that is good and a contact that is good (and an Individual, not a Household or Organization), you can use the API Explorer to fix the problem.

  1. Get the IDs of the WordPress user and the CiviCRM contact you want to connect. Also, get the email address that is on the WordPress user record.

  2. Go to Support > Developer > API Explorer

  3. For Entity, pick UFMatch and for Action, pick get.

  4. In the Parameter drop-down, pick CiviCRM Contact ID, leave the operator as =, and in the Value field, enter the Contact ID.

  5. Click Chain API Call, and in the line the appears, select UFMatch as the Entity and delete in the second column, and leave the third column as {}.

  6. Hit Execute. This will delete any records connecting the good contact to any WordPress user.

  7. Now, modify the first parameter and change it to CMS ID, leave the =, and change the value to the WordPress user ID of the user you want to connect.

  8. Hit Execute. This will delete any records connecting the good user to any CiviCRM contact.

  9. Now, go to the Action drop-down and select create. This should clear out the old parameters and set up three for CMS ID, CMS Unique Identifier, and CiviCRM Contact ID.

  10. Fill those values: enter the WordPress user ID as CMS ID, the WordPress user's email address as the CMS Unique Identifier, and enter the CiviCRM contact ID as CiviCRM Contact ID.

  11. Hit Execute. This will explicitly connect the WordPress user to the CiviCRM contact. You can verify this by going to the contact record and seeing the user ID there next to the contact ID.

  • Thanks for the help to find a fix, It worked. But I want to know what is the reason that this issue is happening. The wordpress user I created does not have anything to do with the contact that it took on CiviCRM. Also, it only fixes the issue for this one user not for any other users I create. For example, the current user I created and fixed is named TEST. If I go and create another user after it TEST2 (with an email that is not on the database), it doesn't create a new contact record for it, it matches it with a contact that does not have the same email or name. – Ali A Jun 11 '18 at 19:30
  • That's really crazy, and unfortunately, I can't help you with that. It's definitely not the appropriate behavior, but I can't tell you whether it's a bug in CiviCRM, WordPress, or another of your plugins that may be interfering. – Andrew Hunt Jun 11 '18 at 19:35
  • 1
    You may need to edit your original question and detail your Dedupe/Merge rules – petednz - fuzion Jun 11 '18 at 21:39
  • Pete's on to something. I had always assumed it just matched on email (because nothing else is necessarily available), but it looks like it sends the $_POST array to the duplicate contact finder and then only looks for contacts based upon email if none matches based on the Unsupervised dedupe rule. Two possibilities: either your Unsupervised dedupe rule is too loose, matching people somewhat at random, or your page request is posting values that the dedupe finder is interpreting to create funny matches. – Andrew Hunt Jun 11 '18 at 22:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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