Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11To remove “Lost your password?” from a WordPress login page, filter the link with lost_password_html_link. That only hides the link. To block password-reset requests as well, use the separate allow_password_reset filter. Anyone who can reach the direct wp-login.php?action=lostpassword endpoint may still request a reset unless reset processing is disabled.
Choose whether to hide the link or block password resets
WordPress handles the login-page link and the reset process separately. The wp-login.php page supports lost-password and retrieve-password actions, so removing the visible link changes the interface but does not enforce a restriction.
- Hide the link: Use this if you only want to remove the “Lost your password?” prompt from the login page.
- Block reset requests: Use this if users must not be able to start a password reset, including through a direct URL.
- Do both: Apply both filters if you want the link gone and reset processing disabled.
WordPress documents lost_password_html_link as a filter for the link that lets a user reset a lost password. The core login page applies that filter when it renders the link. For reset enforcement, WordPress provides allow_password_reset.
Remove the visible “Lost your password?” link
Add this code using a small site-specific plugin or a code-snippet tool that safely manages PHP snippets:
#1 Best Overall
add_filter( 'lost_password_html_link', '__return_empty_string' );
This tells WordPress to return an empty string in place of the link. It is an interface-only change: the lost-password action remains available at the login endpoint unless you also block reset processing.
Disable password-reset processing
To deny reset requests handled by WordPress, add this filter:
Rank #2
add_filter( 'allow_password_reset', '__return_false' );
This example is deliberately site-wide: it returns false for every user, including administrators. WordPress documents the filter as receiving the current allowance value and a user ID; its default is to allow resets. Use those arguments to limit the restriction when some accounts need to retain reset access.
Restrict selected users instead of everyone
If the policy applies only to particular accounts, use a callback and decide based on the supplied user ID. For example, this pattern allows reset processing for one designated recovery account and denies it for other users:
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →function itg_allow_password_reset_for_recovery_user( $allow, $user_id ) {
$recovery_user_id = 123;
return (int) $user_id === $recovery_user_id;
}
add_filter( 'allow_password_reset', 'itg_allow_password_reset_for_recovery_user', 10, 2 );
Replace 123 with the intended account’s actual user ID and adapt the condition to your access policy. This example returns only the selected account’s decision; test it with the accounts and login flows your site uses before deploying.
Install the code safely and verify the result
- Choose where the code lives. A site-specific plugin keeps the behavior tied to the site rather than its theme. A managed snippet tool is another option; avoid editing a parent theme because a theme update can overwrite changes.
- Test on staging first. Confirm ordinary login still works, then visit
wp-login.php?action=lostpassworddirectly. Check whether the form appears, whether a reset email is sent, and whether the selected user scope behaves as intended. - Keep an administrator recovery route. Before enabling a site-wide block, document how an authorized administrator can restore access, such as by removing or changing the snippet through the hosting file manager or another already-tested site recovery method.
- Deploy and monitor. Recheck after deployment, and verify behavior with any multisite configuration or login-related plugin used on the site. Keep a rollback procedure that can disable the snippet without relying on the blocked reset flow.
How the alternatives compare
| Approach | What it changes | What it does not establish |
|---|---|---|
lost_password_html_link filter |
Removes the rendered “Lost your password?” link from the login page. | Does not block direct lost-password requests. |
allow_password_reset filter |
Allows or denies password-reset processing; the callback can use the user ID to scope its decision. | A broad callback can also block administrator recovery. |
| “Disable Lost Your Password” or another directory plugin | Potentially changes password-reset behavior; check the plugin’s description and settings for its actual scope. | The directory listing alone does not establish maintenance status, compatibility, or exact behavior. |
| WPS Hide Login | Changes the login URL and blocks access to the default login path, according to its WordPress.org listing. | Its listing says registration and lost-password forms continue to work, so changing the login URL is not proof that password reset is disabled. |
| Fuerte-WP password controls | Provides password-policy and reset-notification controls described by the plugin. | Those related hardening features do not necessarily remove or disable the reset option. |
For plugins, verify current maintenance, compatibility, and the exact behavior you need before installation. See the WordPress.org listings for Disable Lost Your Password, WPS Hide Login, and Fuerte-WP.
Quick Recap
Best Value
Rank #4
What to check if the option still appears
- If the link remains visible, confirm the snippet is active and that no other login customization is replacing the link after the filter runs.
- If a direct reset URL still works, hiding the link is not enough; check that the
allow_password_resetcallback is active and returnsfalsefor the user being tested. - If only some users should be blocked, verify the callback’s user-ID condition and test both a restricted account and an account that must retain recovery access.
- If the site uses multisite or a login plugin, test the actual login and reset flows in that configuration rather than assuming the standard login page is the only route.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

