WordPress 7.1 expands Unicode handling for email addresses and account-related values on compatible utf8mb4 sites. A value can be accepted by WordPress but normalized, rejected, or matched differently by WooCommerce, a form plugin, CRM, mail provider, analytics pipeline, login flow, or support search.
Use this for WordPress membership, WooCommerce, forms, CRM, authentication, email, analytics, and support teams that need one customer identity across systems.
Quick answer
Build synthetic email pairs that differ by Unicode normalization, case, whitespace, internationalized domains, combining characters, and visually confusable characters. Follow each pair through registration, checkout, order lookup, forms, CRM, mail delivery, analytics hashing, login, password reset, export, and support search. Record the raw value, normalized value, stable user or customer ID, collision decision, and owner. Do not merge real accounts automatically until identity ownership is proven.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Canonical equivalent | Composed and decomposed characters | One documented identity result |
| Internationalized domain | Unicode and ASCII form | Stable lookup contract |
| Visual confusable | Different code points | No automatic merge |
| Legacy CRM | ASCII-only validation | Explicit hold or mapping |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Define the accepted Unicode forms and identity-normalization contract. | Confirm database and relevant tables use utf8mb4, then record versions and normalization rules for every downstream system. | Equivalent synthetic values produce the documented stable identity across required systems. |
| Map every system boundary with synthetic equivalent and confusable fixtures. | Create synthetic pairs for composed and decomposed characters, case, whitespace, internationalized domains, plus addressing, and confusables. | Confusable but distinct values do not merge without proof. |
| Stop automatic merging where ownership or normalization differs. | Capture browser validation, WordPress validation and sanitization, storage bytes, user lookup, duplicate checks, and account creation. | Checkout, CRM, mail, login, password reset, export, and support lookup reconcile. |
| Repair duplicate creation at the earliest boundary that loses the stable ID. | Run checkout, order lookup, form entry, CRM sync, analytics hashing, login, password reset, receipt, export, and support search. | Collision evidence is redacted, owned, and retained only for the approved period. |
What to check first
- Confirm database and relevant tables use utf8mb4, then record versions and normalization rules for every downstream system.
- Create synthetic pairs for composed and decomposed characters, case, whitespace, internationalized domains, plus addressing, and confusables.
- Capture browser validation, WordPress validation and sanitization, storage bytes, user lookup, duplicate checks, and account creation.
- Run checkout, order lookup, form entry, CRM sync, analytics hashing, login, password reset, receipt, export, and support search.
- Classify exact match, normalized match, legitimate separate identity, collision risk, and unresolved ownership without exposing raw personal data.
Field notes
- Use only controlled synthetic addresses and domains.
- Share fixture IDs and hashes instead of raw addresses.
- Treat account merging as an identity-security action, not a cleanup shortcut.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture,raw_form,wp_user,order,crm_contact,login,collision_class,decision
UE-11,composed,118,WC-9041,C-771,pass,normalized-match,keep-one
UE-12,decomposed,118,WC-9042,C-772,pass,duplicate-downstream,review
UE-13,confusable,119,WC-9043,C-773,pass,separate-codepoints,do-not-merge
Why this usually happens
- Validation, normalization, storage, transport, and identity matching are separate boundaries.
- Systems can lowercase or convert domains while preserving local parts differently.
- Visually identical strings can contain different code-point sequences.
- A downstream contact may be created after WordPress has already accepted the account or order.
Decision rule
Merge or block a duplicate only when the normalization contract, account ownership, order history, CRM identity, and recovery path all agree. Keep ambiguous or confusable identities separate for manual review.
Production verification checklist
- Equivalent synthetic values produce the documented stable identity across required systems.
- Confusable but distinct values do not merge without proof.
- Checkout, CRM, mail, login, password reset, export, and support lookup reconcile.
- Collision evidence is redacted, owned, and retained only for the approved period.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Define the accepted Unicode forms and identity-normalization contract.
- Map every system boundary with synthetic equivalent and confusable fixtures.
- Stop automatic merging where ownership or normalization differs.
- Repair duplicate creation at the earliest boundary that loses the stable ID.
- Retest registration, checkout, CRM, login, recovery, and support before rollout.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful browser screen as proof that queues, caches, providers, reports, roles, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, consent states, networks, and failure paths real users have.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache-policy changes, and schema work on staging first. Promote only the smallest measured change with a current rollback point.
What evidence should the report keep?
Keep exact component versions, UTC timestamps, stable synthetic IDs, expected and actual results, queue or provider identifiers, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, message content, addresses, and private infrastructure details before sharing evidence.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context. Record any observation window that remains instead of calling a quiet test a permanent fix.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, root cause or current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window is still open.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, audit WordPress account identity handling.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references