Add support for /.well-known/change-password

[romainmrhenry]

[Chrome Feature](​https://www.chromestatus.com/feature/6256768407568384)
[Editors Draft](​https://wicg.github.io/change-password-url/)

This already landed in Safari

Would it be possible to add support for /.well-known/change-password into WordPress?

This might redirect to wp_login_url()

[johnbillion]

Note: Some hosts handle routing for the .well-known path internally, meaning that such requests might not ever reach the web server that WordPress is running on. I know for example that SiteGround does this.

[romainmrhenry]

Yes, also read some anecdotes of either hosts or proxies handling all .well-known paths. I personally think this is a bad practice, but unfortunately the [spec](​https://tools.ietf.org/html/rfc5785) does not prohibit this.

[ayeshrajans]

+1 from me. I think it's a really nice addition. I'm not sure redirecting to the login page is the correct approach though. Shouldn't we send the user to wp-admin/profile.php, where the new password field is located? WordPress will take care to redirect the user to the login page with redirect_to parameter set back to wp-admin/profile.php in case the user is not logged in.

[romainmrhenry]

I though about redirecting to wp-admin/profile.php and still consider it a good option.

wp_login_url() might offer more options to theme builders, especially those with custom user flows (ecommerce).

It might need to be a separate thing altogether with a dedicated filter.

[ayeshrajans]

This URL is intended to be used when the user tries to change the password, as in a password manager helping to automatically or semi-automatically change the password. I think a redirect to the profile page is fine, because any custom workflows for user profile would redirect the user from profile page to any custom page anyway.

[pfefferle]

Maybe we should also consider to use the autocomplete attributes:

<input type="password" autocomplete="new-password">

or:

<input type="password" autocomplete="current-password">

for the password field(s).

See: ​https://adactio.com/journal/17794

[johnbillion]

Great point @pfefferle , can you open a separate ticket for this please?

[pfefferle]

Sure!

[pfefferle]

@johnbillion I found this old ticket: https://core.trac.wordpress.org/ticket/49608

Should we re-open it, or should I write a new one with the fokus on autocomplete="current-password"?

[romainmrhenry]

This is now also supported in 1Password and Chrome.
Would be great if we could move forward with this :)

[romainmrhenry]

The specification for this has reached First Public Working Draft : ​https://www.w3.org/TR/2022/WD-change-password-url-20220927/

Who on the WordPress core team can champion this feature?

Fixes https://core.trac.wordpress.org/ticket/51173

## What

Adds a redirect from /.well-known/change-password to wp-admin/profile.php inside the existing wp_redirect_admin_locations() function in canonical.php. This follows the ​W3C Well-Known Change Password URL spec.

## Why

Browsers (Chrome, Safari, Firefox) and password managers use /.well-known/change-password to automatically navigate users to the password-change page. Without this redirect, WordPress sites return a 404 for this URL, breaking password manager integrations.

## How

• Adds /.well-known/change-password detection to wp_redirect_admin_locations(), mirroring the existing pattern for /login and /admin aliases.
• Redirects to admin_url( 'profile.php' ) — the profile page handles unauthenticated users by redirecting them to the login page with redirect_to set back to the profile page.
• A wp_change_password_url filter allows sites with custom user flows (membership plugins, WooCommerce accounts) to override the redirect target.
• Only fires when pretty permalinks are enabled (same guard as the rest of the function).

## Tests

Adds tests/phpunit/tests/canonical/changePassword.php covering:

• Redirect fires for /.well-known/change-password
• Trailing-slash variant does not redirect (consistent with untrailingslashit behavior elsewhere)
• No redirect when pretty permalinks are disabled
• wp_change_password_url filter is respected

[hasnainashfaq]

I've opened a pull request for this: ​https://github.com/WordPress/wordpress-develop/pull/12621

The implementation adds the redirect inside wp_redirect_admin_locations() in canonical.php, mirroring the existing pattern for /login and /admin. It redirects to admin_url( 'profile.php' ) with a wp_change_password_url filter for custom user flows, and covers subdirectory installs by also matching the root-relative path. Unit tests included.

@HasnainAshfaq i've come across the PR. could you please check the open copilot feedback and fix/resolve all open comments - if valid? i'd like to check this and see if it could be helpful to push this further.

Thanks for the review @masteradhoc! I've gone through all the open Copilot comments:

• @since 7.2.0 — applied per your suggestion.
• Subdirectory URL matching — removed the home_url()/site_url() relative variants; per the W3C spec the well-known URL is always at the origin root (/.well-known/change-password), so only that literal path is matched now.
• Exception-based redirect interception — already in place from an earlier revision; the wp_redirect filter throws a RuntimeException caught in try/catch/finally, so exit is never reached in tests.
• assertNotNull() before string assertions — already added.
• tear_down() restoring only when set — already handled via $request_uri_was_set.
• Targeted filter removal — already using specific callback references, not remove_all_filters().
• Arrow function for filter callback — fn() => $custom_url does not need explicit parameter acceptance.
• Trailing slash — untrailingslashit() strips it before comparison, so /.well-known/change-password/ correctly redirects (consistent with the /login and /admin behavior); tests updated to reflect this.

[masteradhoc]

Adding this to the WP 7.2 milestone so this can be picked up and tested.