Repository navigation
Misleading notice #855
Description
Describe the bug
We are using the two_factor_providers filter to remove certain providers, including Two_Factor_Backup_Codes. However, we are still seeing the following notice, which in this case is misleading. As far as I can tell, there doesn’t appear to be a straightforward way to remove or suppress it.
'To prevent being locked out of your account, consider enabling a backup method like Recovery Codes in case you lose access to your primary authentication method.'
Steps to Reproduce
Use the two_factor_providers filter to remove certain providers. We got the above notice that is misleading and there isn't any easy way to remove it.
Here is an example of the providers we have removed:
add_filter( 'two_factor_providers', function( $providers ) {
unset( $providers['Two_Factor_FIDO_U2F'] );
unset( $providers['Two_Factor_Backup_Codes'] );
unset( $providers['Two_Factor_Dummy'] );
return $providers;
});
Screenshots, screen recording, code snippet
Environment information
No response
Please confirm that you have searched existing issues in this repository.
Yes
Please confirm that you have tested with all plugins deactivated except Two-Factor.
Yes
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
- Status
Activity
masteradhoc commentedon Mar 28, 2026
Thanks @christofervas! Good point — this could definitely be optimized. We’re open to PRs, but we’ll also look into it on our end!
fix misleading notice WordPress#855
masteradhoc commentedon Mar 28, 2026
Hey @christofervas
i just prepared PR #858 to fix your issue. Could you give it a try as well please?
Thanks!
christofervas commentedon Mar 29, 2026
Hi @masteradhoc, thanks for the quick turnaround and for addressing this.
I had a look at the PR, but I’m not sure this is the ideal approach. It feels quite specific to a single provider, while the underlying issue is more general. The notice can still become misleading depending on how providers are configured via the two_factor_providers filter.
More broadly, I’m not entirely sure who this notice is intended for. In many real-world setups:
Because of this, the notice can easily create confusion or unnecessary concern, especially when backup methods are intentionally disabled.
It might be better to either:
This would give more flexibility and avoid edge cases where the message becomes inaccurate.
Happy to help test further if needed.
masteradhoc commentedon Mar 29, 2026
Just to clarify the intent: the notice is there to encourage users to have at least two authentication methods enabled, so they always have a fallback if one becomes unavailable. Whether the user is an admin or a regular user doesn't really change that risk — losing access to your only 2FA method means being locked out regardless of your role. Not every admin might be that technical to know the steps needed to regain access. we'll have to work/document/improve that properly in #621
That said, your point about the filter is valid — a two_factor_show_backup_notice filter would still make sense for cases where developers want to suppress the notice accordingly. or a similar filter to adjust the text.
In my opinion the PR would be sufficient - maybe with adding a filter to change the text as devs want. @georgestephanis @kasparsd any feedback from your side?
dknauss commentedon Apr 13, 2026
@masteradhoc There is another, related, and also hard-coded notice in the profile/settings UI in
class-two-factor-core.phpline 2241 that probably should be handled too. It also makes the same incorrect assumption thatTwo_Factor_Backup_Codesis always available and recommends Recovery Codes as a fallback, even when that provider has been removed with thetwo_factor_providersfilter:The root problem is fixed by changing both messages to more generic wording — drop the specific provider name ("consider enabling a backup method" without naming one). Then both messages are always accurate.
A further enhancement is dynamic wording: only mention Recovery Codes when
Two_Factor_Backup_Codesis in the registered providers array.Either way, both messages should be updated together.
Merge pull request #858 from masteradhoc/855-optimize-notice
Merge pull request #923 from dknauss/pr-858-tests