Thanks, the debugging tips that you provided were very helpful and I was able to pinpoint the issue on our server. The clue was in “/wp-content/plugins/wp-2fa/includes/classes/bacon/bacon-qr-code/src/Renderer/Image/SvgImageBackEnd.php” (lines 39-41) as it was looking for the XMLWriter class. The version of PHP on our local mirror was not built with –enable-xmlwriter. This became obvious when I created a test user and then couldn’t see the QR code to setup 2FA for it (as it needs XMLWriter to generate the image).
This has never been a problem as we haven’t needed to scan the QR code on this local server before – it is usually done on the live server and therefore already configured by time it is mirrored. However, I rebuilt PHP with –enable-xmlwriter and the problem is resolved.
Although I chose to keep the legacy UI, something must have changed as even though I didn’t have XMLWriter, it didn’t affect the login flow before. I don’t expect it will be a common issue but I hope this information is helpful. Edit: I tried to paste the error that I saw below for completeness but I don’t think it came through (it simply said “WP-2FA: Please contact the administrator for further assistance! Invalid provider.”).
Thank you for your quick reply. Here are my answers to your questions.
Which type of Passkey provider are you using (e.g. platform passkey such as Windows Hello, Touch ID, Face ID, or a security key such as YubiKey)?
We don’t currently use Passkeys.
Could you open your browser’s Developer Tools (F12), reproduce the issue, and share any errors shown in the Console tab?
All I see in the console is “/wp-login.php?action=validate_2fa 500 (Internal Server Error)”.
Are you using the native WordPress login page, or a custom login form/page? If it’s a custom login, does the same issue occur on the default WordPress login page as well?
Are you using a 2FA method along with the passkeys or just passkeys alone? Can you elaborate on the method used if that’s the case etc.
We only use the 6-digit 2FA method.
Finally, can you confirm which WP 2FA version you upgraded from before testing 4.0.0?
3.1.1.2
Some further information. The way that I have been reproducing the problem is to select the option to stick with the current UI that pops up after the initial upgrade. Whilst still logged into the dashboard, I tried changing to the new UI from the plugin settings then I no longer get “invalid provider”, but I am not prompted for a 2FA code either. Also, I can’t re-enter the WP-2FA settings page after doing this (it just redirects to my user profile settings). The only way that I can successfully select the new UI is when I do it from the initial popup.
Thanks for your reply, I don’t think the plugin is supported anymore but I just mentioned it for context (i.e. that our website produces quotes, not orders). I was really looking for a hook or something in your plugin that I can override myself to dissalow that order state.
Good idea about the time but I just checked and confirmed that they are in sync. However, I decided to give it another try and to my surprise the 2FA code worked this morning. It did seem to be a bit intermittent though and only worked on one of our mirrors. This could be our problem and I’m satisfied that it works enough for what we need from our mirror.
We use the Members plugin to define our own roles and have more control over their capabilities.
The bbp_participant role is created by the bbPress plugin (https://wordpress.org/plugins/bbpress/). The Members plugin is not directly related to the problem but I mentioned it just becuase it highlights this role as being a special role and won’t allow it to be edited. I assumed that was the same reason that your plugin doesn’t recognise this role but that is just my guess.
Thanks, I’ve just tried this and couldn’t find the wp_2fa_secret_key setting in wp_options. However, I couldn’t find it in the live database either. Just to confirm, I am searching for it in the option_name field in wp_options.
Thanks for the suggestion, I thought that might solve it as we don’t mirror wp-config.php but I just tried updating the key and it still gives the following error:
ERROR: Invalid verification code.
I think I’ll stick to my current strategy of renaming the folder for now.
Sorry for the delay in responding but I just got a chance to return to this. Looking at the logs in the Search Console, it appears that this is no longer being reported as an issue (although we did not change anything). We have just updated to the latest release of Yoast SEO so will keep an eye on it. I think you can close this issue now.
