fix(checkout): send 'set your password' email on auto-generated password signup

[superdav42]

Summary

Customers who check out via the simple checkout form (or any checkout form with auto_generate_password enabled on the password field) were never receiving the standard WordPress "set your password" email. They ended up with a 16-character random password they did not know, with no way back into their account other than guessing they should use the lost-password flow.

Root Cause

Checkout::maybe_create_customer() generated the random password locally and then passed it into wu_create_customer(). Because the password was non-empty, wu_create_customer() (in inc/functions/customer.php) routed user creation through wpmu_create_user(), which silently suppresses the user notification email. The other branch — register_new_user() — would have triggered wp_send_new_user_notifications($user_id, 'both'), the exact flow WordPress uses when an admin adds a user without a password from wp-admin/user-new.php.

Fix

When auto_generate_password is set, keep the generated password local to the checkout method and pass an empty value to wu_create_customer(). That sends user creation through register_new_user(), so the customer receives the standard "set your password" email with a reset link.

After the customer record is saved, apply the generated password to the user via wp_set_password(). This preserves the existing same-request auto-login behaviour in login_customer_after_checkout() and keeps any code that needs a known credential working for the rest of the request. The reset-password link in the dispatched email is keyed on a fresh activation key (not the stored password hash), so it remains valid even after wp_set_password() runs.

User-Visible Behaviour

• Before: simple-form checkout → no email → customer is auto-logged in but cannot return after logout without using the lost-password flow.
• After: simple-form checkout → standard WordPress "set your password" email is sent → customer is still auto-logged in for the rest of this request → after logout they can click the email link to set a real password.

This matches the behaviour of WordPress's own wp-admin/user-new.php when an administrator adds a user without supplying a password.

Verification

• New regression test test_maybe_create_customer_auto_generate_password_sends_notification asserts the register_new_user action fires for the new user and that the user record ends up with a non-empty password hash.
• All 8 existing test_maybe_create_customer_* tests still pass (15 assertions).
• Full Checkout_Test class passes (217 tests, 362 assertions, 1 pre-existing skip).
• PHPCS clean on both modified files within my changed line ranges.
• PHPStan clean.

Files Changed

• inc/checkout/class-checkout.php — route auto_generate_password flow through register_new_user(), then apply generated password via wp_set_password().
• tests/WP_Ultimo/Checkout/Checkout_Test.php — regression test for the notification email path.

---

aidevops.sh v3.14.91 plugin for OpenCode v1.14.40 with claude-opus-4-7 spent 32m and 34,394 tokens on this with the user in an interactive session.

[coderabbitai]

Warning

Rate limit exceeded

@superdav42 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 16 minutes and 1 second before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 06f8a7ef-3ad3-46a2-8d5c-2e74c3cba654

📥 Commits

Reviewing files that changed from the base of the PR and between 3042894 and 1bf315f.

📒 Files selected for processing (2)

• inc/checkout/class-checkout.php
• tests/WP_Ultimo/Checkout/Checkout_Test.php

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/checkout-auto-password-notification

---

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 9c33ec4 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	871.50 ms	169.00 ms	1079.50 ms (-58.00 ms / -5% )	2044.00 ms (-92.00 ms / -5% )	1950.40 ms (-93.30 ms / -5% )	93.45 ms
1	56	49.12 MB	958.50 ms (-20.50 ms / -2% )	152.50 ms	1112.50 ms	2100.00 ms (-68.00 ms / -3% )	2017.35 ms (-63.25 ms / -3% )	84.20 ms

[superdav42]

Summary

Customers who check out via the simple checkout form (or any checkout form with auto_generate_password enabled on the password field) were never receiving the standard WordPress "set your password" email. They ended up with a 16-character random password they did not know, with no way back into their account other than guessing they should use the lost-password flow.

Root Cause

Checkout::maybe_create_customer() generated the random password locally and then passed it into wu_create_customer(). Because the password was non-empty, wu_create_customer() (in inc/functions/customer.php) routed user creation through wpmu_create_user(), which silently suppresses the user notification email. The other branch — register_new_user() — would have triggered wp_send_new_user_notifications($user_id, 'both'), the exact flow WordPress uses when an admin adds a user without a password from wp-admin/user-new.php.

Fix

When auto_generate_password is set, keep the generated password local to the checkout method and pass an empty value to wu_create_customer(). That sends user creation through register_new_user(), so the customer receives the standard "set your password" email with a reset link.
After the customer record is saved, apply the generated password to the user via wp_set_password(). This preserves the existing same-request auto-login behaviour in login_customer_after_checkout() and keeps any code that needs a known credential working for the rest of the request. The reset-password link in the dispatched email is keyed on a fresh activation key (not the stored password hash), so it remains valid even after wp_set_password() runs.

User-Visible Behaviour

• Before: simple-form checkout → no email → customer is auto-logged in but cannot return after logout without using the lost-password flow.
• After: simple-form checkout → standard WordPress "set your password" email is sent → customer is still auto-logged in for the rest of this request → after logout they can click the email link to set a real password.
  This matches the behaviour of WordPress's own wp-admin/user-new.php when an administrator adds a user without supplying a password.

Verification

• New regression test test_maybe_create_customer_auto_generate_password_sends_notification asserts the register_new_user action fires for the new user and that the user record ends up with a non-empty password hash.
• All 8 existing test_maybe_create_customer_* tests still pass (15 assertions).
• Full Checkout_Test class passes (217 tests, 362 assertions, 1 pre-existing skip).
• PHPCS clean on both modified files within my changed line ranges.
• PHPStan clean.

Files Changed

• inc/checkout/class-checkout.php — route auto_generate_password flow through register_new_user(), then apply generated password via wp_set_password().
• tests/WP_Ultimo/Checkout/Checkout_Test.php — regression test for the notification email path.

---

aidevops.sh v3.14.91 plugin for OpenCode v1.14.40 with claude-opus-4-7 spent 32m and 34,394 tokens on this with the user in an interactive session.

---

Merged via PR #1157 to main.
Merged by deterministic merge pass (pulse-wrapper.sh).

[superdav42]

Summary

Customers who check out via the simple checkout form (or any checkout form with auto_generate_password enabled on the password field) were never receiving the standard WordPress "set your password" email. They ended up with a 16-character random password they did not know, with no way back into their account other than guessing they should use the lost-password flow.

Root Cause

Checkout::maybe_create_customer() generated the random password locally and then passed it into wu_create_customer(). Because the password was non-empty, wu_create_customer() (in inc/functions/customer.php) routed user creation through wpmu_create_user(), which silently suppresses the user notification email. The other branch — register_new_user() — would have triggered wp_send_new_user_notifications($user_id, 'both'), the exact flow WordPress uses when an admin adds a user without a password from wp-admin/user-new.php.

Fix

When auto_generate_password is set, keep the generated password local to the checkout method and pass an empty value to wu_create_customer(). That sends user creation through register_new_user(), so the customer receives the standard "set your password" email with a reset link.
After the customer record is saved, apply the generated password to the user via wp_set_password(). This preserves the existing same-request auto-login behaviour in login_customer_after_checkout() and keeps any code that needs a known credential working for the rest of the request. The reset-password link in the dispatched email is keyed on a fresh activation key (not the stored password hash), so it remains valid even after wp_set_password() runs.

User-Visible Behaviour

• Before: simple-form checkout → no email → customer is auto-logged in but cannot return after logout without using the lost-password flow.
• After: simple-form checkout → standard WordPress "set your password" email is sent → customer is still auto-logged in for the rest of this request → after logout they can click the email link to set a real password.
  This matches the behaviour of WordPress's own wp-admin/user-new.php when an administrator adds a user without supplying a password.

Verification

• New regression test test_maybe_create_customer_auto_generate_password_sends_notification asserts the register_new_user action fires for the new user and that the user record ends up with a non-empty password hash.
• All 8 existing test_maybe_create_customer_* tests still pass (15 assertions).
• Full Checkout_Test class passes (217 tests, 362 assertions, 1 pre-existing skip).
• PHPCS clean on both modified files within my changed line ranges.
• PHPStan clean.

Files Changed

• inc/checkout/class-checkout.php — route auto_generate_password flow through register_new_user(), then apply generated password via wp_set_password().
• tests/WP_Ultimo/Checkout/Checkout_Test.php — regression test for the notification email path.

---

aidevops.sh v3.14.91 plugin for OpenCode v1.14.40 with claude-opus-4-7 spent 32m and 34,394 tokens on this with the user in an interactive session.

---

Merged via PR #1157 to main.
Merged by deterministic merge pass (pulse-wrapper.sh).