Kaspars

Can you please elaborate on the two-factor methods you have access to and what you mean by “i have not managed to switch from the app to email”? Secondly, which of the two-factor methods are enabled for your WP user?

The following statements seem to contradict each other:

• I have lost all my devices
• I logged in to the website using an authentication app
• i have access to my email account again

To disable the two-factor requirement for your account, you should connect to the database and delete the _two_factor_enabled_providers user meta for your user ID in the wp_usermeta table as that’s storing the enabled two-factor methods.

Thanks for sharing! Looks like the plugin still needs a settings page or a filter to supply SMS gateway parameters, right?

Login over APIs (REST and XML-RPC) doesn’t support the second factor so you need to effectively disable the second factor for all those logins with application passwords using the two_factor_user_api_login_enable filter.

The standard login_redirect filter should still work as expected. Plugins that rely on wp_login action might not work because of this issue.

The two_factor_user_authenticated action is correct but your code sample is using it as a filter (which technically should still work).

The error could be due to writing to a write-protected directory with ABSPATH . 'wp-content/two_factor_validations.log' which is also public (I would personally recommend not doing that).

Try something like this:

add_action( 
    'two_factor_user_authenticated', 
    function( $is_authenticated, $user, $provider ) { 
        if ( ! $user instanceof WP_User ) {
            return;
        }

        syslog(
            LOG_INFO,
            sprintf( 
                '%s 2FA (%s) login for user ID: %d (username: %s)', 
                $is_authenticated ? 'Successful' : 'Failed',
                $provider::class,
                $user->ID, 
                $username 
            )
        );
    }, 
    10, 
    3 
);

To enable logins over APIs (XML-RPC or REST) you would need to enable the two_factor_user_api_login_enable filter (which unfortunately isn’t documented). Here is the logic that disables API login based on this conditional.

Importantly, this disables the two factor check for any API login so be aware of the risk factors.

I personally haven’t verified that the WP apps work with this plugin enabled. Here is the WP core logic that enables application password login during API requests.

The plugin doesn’t support this feature by default but you could create a custom two-factor provider following similar to the built-in providers.

The plugin doesn’t support this feature.

However, you could add it using custom code that sends the two-factor codes to multiple addresses (maybe provide a UI in the user profile for this) using the wp_mail filter. You could use the did_filter( 'two_factor_token_email_message' ) conditional to update the recipients with the extra email address.

Version 0.10.0 is out now. It should both fix the issue and also add the option to control the native WordPress shortcode support from the “Controls” settings.

Thanks for confirming the exact setting you were using to notice the difference in behaviour. I’ve been able to replicate the problem.

Turns out it is a race condition with the Shortcode Enabler plugin which is also using the wpcf7_form_elements filter to enable the shortcodes at priority 10. In version 9.0.0 of Controls for CF7, the filter registration was moved to plugins_loaded which is after all other plugins are loaded, which made it reset the form output to the default version without the autop applied.

I’m working on a patch now. I will also bring the native WordPress shortcode toggle feature to the plugin since it might be useful for others without having to install another plugin.

I just added a QR shortcode to a form using the latest versions of the plugins you mentioned and it is rendering correctly:

Please share the exact setup, including all your individual form configurations (at least the relevant bits) to allow replicating the issue.

Can you please confirm which plugin version exactly were you using before and which broke the shortcode functionality? In order to replicate the issue, please provide all the relevant information such as the exact name and version of the shortcode plugin and its configuration. Please also provide the relevant form setup on the CF7 side.

Between versions 0.8.2 and 0.9.0 there we no changes in how the form processing works. Could it be that one of the latest Contact Form 7 upgrades broke the processing instead?

Version 0.8.2 did remove support for WPCF7_ShortcodeManager which has been removed from Contact Form 7 since 2016 per this documentation.

• This reply was modified 2 months ago by Kaspars.

According to Javascript events in CF7 and the Javascript logic of the Controls for CF7 plugin, the Error event is sent when CF7 triggers wpcf7mailfailed and Spam event is sent on wpcf7spam (if spam check is enabled with Akismet).

However, if you’re using a form submission storage plugin or have working email delivery, then most of the form submissions shouldn’t trigger those events.

What would be the steps to replicate this? Are you expecting “Error” or “Spam” submissions somewhere? Technically, the Javascript logic that triggers these events is shared so it should work exactly the same if the error/spam events are triggered.

This should now be fixed in version 0.8.2!