I did take a look at this and can trace where the problem is. That being said, I do not have much of a solution for you at this time.
WP Cerber removes several native WP functions that run hooked to WP’s authenticate
filter hook and replaced them with it’s own custom function. Part of the problem with providing an immediate simple solution is that WP Cerber does this by using an anonymous function. If they did it using a named function hooked to authenticate
, you could probably bypass the issue by using remove_filter
, but because it is an anonymous function, you can’t do that.
Ultimately, the problem is the WP Cerber’s custom function results in the user object being received by WP-Members’ check_activated()
function as null
. WP-Members runs this function hooked to WP’s authenticate
filter when moderated registration is enabled. The function essentially checks to see if the user is activated before allowing login to proceed. During that process, it validates the password given using wp_check_password()
. Because the user object passed is null when using WP Cerber, this results in a failure of wp_check_password()
because the WP-Members function gets the user’s password hash from the user object passed through authenticate
. Without that required value, wp_check_password()
fails because the password hash is a required argument for the function.
I’ve noted this function for review and will consider a possible change. A change is likely an improvement because authenticate
can return a null user object – it’s just that in an install that uses WP’s native authentication functions, it doesn’t get to the WP-Members function as null. However, because of the nature of the function (i.e. it handles allowing/disallowing login), any change must be thoroughly tested and I need to be confident that it is correct. So I can’t guarantee that I’ll be making a change here (although I can’t guarantee that I won’t, either).
In the meantime, if you want a hack workaround (which I don’t generally recommend – but in this instance, it’s your only immediate solution), you can change the method check_activated()
in includes/class-wp-members-user.php to the following:
redacted code because the change doesn’t properly validate the user activation (allows a non-activated user to log in). I’ll post something below as a new post if/when I can solve that
That should solve the problem of not being able to log in. You’d still get an error if the user puts in an invalid username, but at least users would be able to log in.
-
This reply was modified 3 years, 2 months ago by
Chad Butler.