As @knireis points out, it’s not related to the update – it’s any version of the plugin.
The problem with this is that these types of plugins use WP’s authenticate
filter hook to add a third value to the login that needs to be validated. But this isn’t compatible with WP-Member’s own login form (side note: this login isn’t required for using WP-Members; an authenticated user is recognized by the plugin whether the WP-Members form is used or not, it’s just that it’s easy to implement and obviously is the default).
Because the filter these plugins use is global to the authentication process, if a 2 argument login is submitted, it will fail because there is no third argument to validate.
The possibilities to avoid this are multiple:
First, you could not use whatever plugin is adding a captcha to the WP login (more than just Jetpack Protect do this). There are varying opinions on this, but I’m of the opinion that captchas are not overly effective, so it’s not going to stop a brute force attack and there are better ways of doing so without degrading the UX/UI. But I know there are other opinions so this isn’t the only solution.
Another possibility is to not use WP-Member’s login form. For this general answer I can’t detail the ways to handle this because there isn’t a single answer for this. But basically, WP-Members has filters that could be used to return the WP login form instead of WP-Members’ form, or you could use another plugin or self-built solution that adds the WP login form to the front end. These login captcha plugins are hooking into the form itself to add the captcha to the form, so if the WP form is called front end, that would have the captcha included and you could still have it enabled.
Lastly, you could apply a filter to override what the captcha plugin is doing. Essentially, the captcha is hooking to the authenticate
filter to apply it’s own process to authentication. If you add a filter hook with a later priority that reapplies WP’s own authentication function (wp_authenticate_username_password()
), you’ll essentially override it. If this method is taken, I’d go a step farther an look to see if the form submission is coming from the WP native form; something that can be done by checking if ‘wp-submit’ is posted with the form, and then only apply the filter if that isn’t the case. This second step would allow you to have the backend retain the captcha while still allowing the WP-Members form to function on the front end. That would look like this:
if( ! isset( $_POST['wp-submit'] ) ) {
add_filter('authenticate','wp_authenticate_username_password',99,3);
}
I know that looks like a lot in the way of explanation, and unfortunately, that’s really just an overview of what is happening and how to work with it based on what your desired outcome is. Hopefully you can find something in there that is worthwhile.