Answers.Body: <p>Is it possible that you upgraded at the same time as you switched to WordPress?  Specifically, <strong>in 4.4 and earlier</strong>, events would match participants on <strong>email address only</strong> unless you checked the box to allow multiple registrations with the same email.  This was <strong>regardless of any dedupe rules</strong> you might have set up.</p>
  
  <p><strong>In 4.5 and later</strong>, an event will default to matching on the <strong>unsupervised dedupe rule</strong>, and you can choose an alternative rule on a per-event basis.  My suspicion is that your rule allows for false positive matches, and you haven't noticed the issue until the events started actually using the rule.</p>
  
  <p>You might create a brand new individual unsupervised rule with the email address field, leave length blank, 10 as the weight, and a threshold of 10.  This will replicate the original situation of matching on email only.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-01T17:08:36.770Z
Answers.Text: I was using 4.6 when I upgraded, so I don't think that was it. Regardless, I have changed the dedupe rule and am now using one with much more strict rules.
Answers.UserDisplayName: osarusan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-18T14:39:40.340Z
Answers.LastActivityDate: 2015-11-18T14:39:40.340Z
Answers.UserDisplayName: Andie Hunt
Body: <p>I am using a Civi install that was originally part of a Drupal installation. A month ago I switched over to using Wordpress and migrared the Civi install to Wordpress.</p>
  
  <p>Since then, something weird has been happening with event registrations in CiviCRM.</p>
  
  <p>Previously, under Drupal, if two people registered using the same email, it would create separate contacts for each person. Or, if someone registered using an email that was already in the database, it would do the dedupe search and either count it as the person if the first name, last name, and email matched, or else it would make a new contact if they didn't match perfectly.</p>
  
  <p>Now, however, it automatically overwrites any previous entries when someone registers using an email that is already in the database. This is fine when it's clearly the same person, but for some reason, it is now overwriting even when a single part of the name is the same. So, for example, Bob Smith smith@company.com registers. Then Mike Smith mike@college.edu registers. Looking at the registrations, I now have 2 registrations for Mike Smith, and there is no registration for Bob Smith. Even just the same last name has caused the first name and email to be overwritten.</p>
  
  <p>I am using the same default dedupe rule, but for some reason it is acting differently now. Does anyone understand what is going on, or how I can fix this so it behaves the way it used to?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-11-18T09:49:35.073Z
Comments.Text: Probably needs a bit of investigation, I would try creating a new de-dupe rule with the criteria you set and use that during the registration process, see if that works. Should give some indication of where the problem is.
Comments.UserDisplayName: Parvez Saleh
Tags: <civievent><contacts>
Title: CiviEvent Overwriting Contact Info
ThreadText: # CiviEvent Overwriting Contact Info
  
  (Asked by: username_0 on 2015-11-17)
  
  I am using a Civi install that was originally part of a Drupal installation. A month ago I switched over to using Wordpress and migrared the Civi install to Wordpress.
  
  Since then, something weird has been happening with event registrations in CiviCRM.
  
  Previously, under Drupal, if two people registered using the same email, it would create separate contacts for each person. Or, if someone registered using an email that was already in the database, it would do the dedupe search and either count it as the person if the first name, last name, and email matched, or else it would make a new contact if they didn't match perfectly.
  
  Now, however, it automatically overwrites any previous entries when someone registers using an email that is already in the database. This is fine when it's clearly the same person, but for some reason, it is now overwriting even when a single part of the name is the same. So, for example, Bob Smith smith@company.com registers. Then Mike Smith mike@college.edu registers. Looking at the registrations, I now have 2 registrations for Mike Smith, and there is no registration for Bob Smith. Even just the same last name has caused the first name and email to be overwritten.
  
  I am using the same default dedupe rule, but for some reason it is acting differently now. Does anyone understand what is going on, or how I can fix this so it behaves the way it used to?
  
  **Tags:** civievent, contacts
  
  > **Comments:**
  > **username_1**: Probably needs a bit of investigation, I would try creating a new de-dupe rule with the criteria you set and use that during the registration process, see if that works. Should give some indication of where the problem is.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2015-11-18. Score: 4
  
  Is it possible that you upgraded at the same time as you switched to WordPress? Specifically, **in 4.4 and earlier**, events would match participants on **email address only** unless you checked the box to allow multiple registrations with the same email. This was **regardless of any dedupe rules** you might have set up.
  
  **In 4.5 and later**, an event will default to matching on the **unsupervised dedupe rule**, and you can choose an alternative rule on a per-event basis. My suspicion is that your rule allows for false positive matches, and you haven't noticed the issue until the events started actually using the rule.
  
  You might create a brand new individual unsupervised rule with the email address field, leave length blank, 10 as the weight, and a threshold of 10. This will replicate the original situation of matching on email only.
  
  > **Comments:**
  > **username_0**: I was using 4.6 when I upgraded, so I don't think that was it. Regardless, I have changed the dedupe rule and am now using one with much more strict rules.  
  
  ---
  
  