fix: use checkout domain for email verification URLs

[superdav42]

Summary

• Store the checkout site's blog ID on the customer during registration so email verification links point back to the same domain the customer used — not always the main site
• Fixes cross-domain checkout where the customer's auth cookie is set for example2.com but the verification email links to example.com, causing an authentication failure when clicking the link

Problem

When a checkout form lives on a domain other than the main site (e.g. example2.com), the verification email always linked to the main site (example.com). The customer's auth cookie was set for the checkout domain during login_customer_after_checkout(), so clicking the verification link on the main site hit the is_user_logged_in() guard in maybe_verify_email_address() and died with a login prompt — on the wrong domain.

Changes

inc/models/class-customer.php

• Add META_CHECKOUT_BLOG_ID constant (wu_checkout_blog_id)
• Add get_checkout_blog_id() / set_checkout_blog_id() methods using existing meta system
• Modify get_verification_url() to use get_home_url($blog_id) with the stored checkout blog ID, falling back to wu_get_main_site_id() for existing customers without the meta
• Add wu_customer_verification_base_url filter for full override control

inc/checkout/class-checkout.php

• In maybe_create_customer(), store get_current_blog_id() on the customer before the verification email is triggered

Backward Compatibility

Existing customers without the meta key get 0 from get_checkout_blog_id(), which is falsy, so the fallback to wu_get_main_site_id() preserves the old behavior. No database migration needed.

---

aidevops.sh v3.13.3 plugin for OpenCode v1.3.17 with claude-opus-4-6 spent 15m and 23,186 tokens on this with the user in an interactive session.

Summary by CodeRabbit

• Bug Fixes
  • Fixed verification email URLs to reference the correct checkout domain in multisite setups, instead of defaulting to the main site.

[coderabbitai]

Caution

Review failed

Pull request was closed or merged during review

📝 Walkthrough

Walkthrough

The changes persist the current WordPress blog ID to newly created customers during checkout. Customer verification URLs now derive their base URL from this stored blog ID instead of always defaulting to the main site, enabling verification emails to reference the originating checkout domain.

Changes

Cohort / File(s)	Summary
Checkout Customer Creation inc/checkout/class-checkout.php	Adds persistence of the current blog ID (set_checkout_blog_id(get_current_blog_id())) when creating or retrieving a customer in maybe_create_customer().
Customer Verification URL Generation inc/models/class-customer.php	Introduces get_checkout_blog_id() / set_checkout_blog_id() getter/setter methods and META_CHECKOUT_BLOG_ID constant. Refactors get_verification_url() to read the stored checkout blog ID, fall back to main site if unset, and construct verification URLs using get_home_url($blog_id). Adds wu_customer_verification_base_url filter for extensibility.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• fix: prevent duplicate WP users on checkout retry #911: Also modifies maybe_create_customer() logic in checkout, affecting how customers are created and linked with blog-related data.

Suggested labels

origin:worker

Poem

🐰 A blog ID carried through the mail,
Verification links no longer fail,
Customers know their checkout home,
From domain to domain they'll roam! 🌐

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: storing checkout domain information for email verification URLs instead of always using the main site.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/cross-domain-verification-email

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

🔨 Build Complete - Ready for Testing!

📦 Download Build Artifact (Recommended)

Download the zip build, upload to WordPress and test:

• Build: ultimate-multisite
• ⬇️ Download from GitHub Actions
• ⬇️ Download without Github Account (nightly.link)

🌐 Test in WordPress Playground (Very Experimental)

Click the link below to instantly test this PR in your browser - no installation needed!
Playground support for multisite is very limitied, hopefully it will get better in the future.

🚀 Launch in Playground

Login credentials: admin / password

[github-actions]

Performance Test Results

Performance test results for 479e051 are in 🛎️!

Note: the numbers in parentheses show the difference to the previous (baseline) test run. Differences below 2% or 0.5 in absolute values are not shown.

URL: /

Run	DB Queries	Memory	Before Template	Template	WP Total	LCP	TTFB	LCP - TTFB
0	41	37.78 MB	818.00 ms	150.00 ms (+4.00 ms / +3% )	1050.50 ms	1984.00 ms	1898.80 ms	88.80 ms
1	56	49.03 MB	941.00 ms	142.00 ms (+3.50 ms / +2% )	1084.00 ms (+23.00 ms / +2% )	2098.00 ms (+56.00 ms / +3% )	2014.45 ms (+50.70 ms / +3% )	78.20 ms (-2.50 ms / -3% )