Getting a warning when trying to log.

The root-cause (what ultimately started the failure) is not in WordFence, but in the User-Blocker plugin. Poor coding can cause User-Blocker to at times pass on values that should not exist in the authentication path.

@solwininfotech’s answer from earlier of simply passing you on to the next layer in the filter chain was wrong. They did not actually look at the problem before throwing it “over the fence” to WordFence.

Their code has an obvious flaw. 2 minutes or less of looking at their code should tell them where it can go haywire.

You have hit one of the unfortunate side-effects of having multiple plugins trying to manipulate the same thing.

That said, I would suggest a tiny future improvement in WordFence, where it validates whether other plugins might pass them unexpected/invalid values. That would prevent the PHP errors from being reported in WordFence.
That would not fix the root-flaw, though. That must come from User-Blocker.

Tell the User Blocker folks this:

Look at the very first line in their filter:

$user = get_user_by('login', $username);

get_user_by() can return ‘false’.

Which first makes their next line of code
$user_id = $user->ID;
wrong, because they assume that they will always receive a WP-User and try to get a UserID from a boolean (not an Object).

Second, it also makes their subsequent return value of ‘return $user;’ wrong, because that means they are passing an invalid value downstream to the next plugin, in this case WordFence.

As @wfalaa stated, only WP_User or a WP_User_Error objects are valid. No booleans allowed.

@solwininfotech,

Your plugin has been changed, yes. But not entirely for the better.

Your new code now has multiple new problems.

Putting a big

if (!is_wp_error($user) && is_object($user)) {

bracket around all your code and totally eliminating the get_user_by() (never actually translating the $username string) call might seem like a good idea, but not in reality.

All that bracket does is to protect YOURSELF from getting into the situation WordFence was in. That someone upstream passes YOU values that are not what you think. But it adds new issues.

Problem 1. The Authentication process starts by WordPress sending

(null, $username, $userpassword)

NULL.. As in, the first filter function will not have a WP_User at all as a parameter, but a ‘null’. The filter is responsible for filtering on $username/$userpassword and checking or looking up the username, when no $user structure has been found yet.
Or in the case, that the $username is for example a banned/illegal name, a filter might not try to look up the $username at all, but will simply return WP_User_Error.

A WP_User object is not found until the first filter translates the $username into a WP_User object. Then if the user and $userpassword is accepted by that particular filter, the filter passes a WP_User (rather than a WP_User_Error/WP_Error) as a return value.

Given that you are bracketing your entire function, that simply means that if you are first to be called from wp_authenticate(), you become a pass-though. Doing nothing at all. You never look up or otherwise check the $username.

This particular issue you are somewhat protected from, since WordPress initially inserts 3-4 internal ‘authenticate’ filters, which most likely would have translated $username before you ever get called. Why it might have appeared to work, when you tested it. But that is not an assumption that is really safe to make, since you are supposed to be able to handle NULL.

Problem 2. You are now returning NULL.

If there is a next filter in the chain AFTER you, like here WordFence, they might save the overall filter-result from your return value, because they are also responsible for accepting NULL as a first parameter. The next filter might then translate/validate/invalidate $username and return a correct value. But if you are alone or last in a filter-chain, you would be returning NULL to wp_authenticate() as the final filtering result..

NULL is not a valid return value from any ‘authenticate’ filter. No more valid than the earlier value of ‘false’.

wp_authenticate() in fact checks for NULL explicitly, and considers it a failure of the filter process that should not happen. It reacts by failing the whole login process, and declaring the login invalid.