If you using a plugin to implement a CAPTCHA on the WordPress login form (the backend login, wp-login.php), you will find that this is not always compatible with the WP-Members front end login.
WP-Members includes WP’s native hooks such as login_form for broad compatibility with plugins that may add additional authentication to the login. But these are not always compatible with WP-Members or with front-end logins in general.
If the third party plugin does not load its scripts on the front end, it will not be compatible. If you are getting failed logins with strange error messages (such as “human verification incorrect” or something like that), then the issue is likely that a third party CAPTCHA is being used, but cannot authenticate on the front end of the site.
What happens is that in order to implement the CAPTCHA, the plugin must remove the function wp_authenticate_username_password from the authenticate process with remove_filter. This allows the plugin to implement its own authentication that includes not only username and password, but also will validate the CAPTCHA.
This creates a problem since WP-Members also uses WP’s authentication to log a user in. Because the WP-Members form will only be passing two parameters, username and password, and the authentication is now requiring the addition of a third parameter (the CAPTCHA) that is not included in that form, the login will fail.
There are ways to work around this.
Obviously, one solution is to not use the CAPTCHA plugin in the first place (or if it is a plugin that does more, disable the login CAPTCHA). CAPTCHAs were never intended to be used for logins anyway and in my opinion it makes for a bad user experience while providing a very limited amount of “security.” But I understand that is an opinion and there is room for other opinions of a differing view. If you must have a CAPTCHA on the login, then the solution for this is to turn the original WordPress process back on using add_filter to apply the original WP authenticate function; a process I will describe below.
Most CAPTCHA plugins apply their filter at a priority later than the default (10). If we set our add_filter later on down the line (99 in this example), we will add the filter back after the CAPTCHA plugin has removed it (if you add it back before the CAPTCHA plugin removes it, this wouldn’t work).
But that alone isn’t really enough. Just adding the filter back in is the equivalent of turning off the CAPTCHA plugin for the wp-login.php form. What’s the point of that, since the plugin has a setting to turn that process off anyway?
We still want the CAPTCHA to function on wp-login.php but not interfere with the front side WP-Members login. To do that, we can add a condition to the process. If we check to see if “wp-submit” is not set, we would know that the login is not coming from wp-login.php, and thus we would want to add the filter back in:
/**
* This snippet returns the authentication to its WP native
* state if there is no $_POST['wp-submit'] (which is the
* native WP login submission button).
*
* Note: The priority (99 in the example) may have to be adjusted
* to a later priority (i.e. higher number) depending on
* when the third party plugin fires its custom authenticate
* filter function. If the plugin fires at a higher priority
* number, you'll need to adjust this to a value higher than
* that. For example, if the plugin runs at priority 1000,
* then your reapplication of WP's authentication needs to
* run at 1001 or higher.
*/
if ( ! isset( $_POST['wp-submit'] ) ) {
add_filter( 'authenticate', 'wp_authenticate_username_password', 99, 3 );
}Like most other filters, you can add this code snippet to your theme’s functions.php file or a custom functions plugin file. There is information on this site on how to use code snippets.
Using this method, you can have a CAPTCHA on your wp-login.php form and still have WP-Members login front side login forms remain functional.