Numeric Nicename sends PM's to the wrong user on large sites

[DennisSmolek]

I'm not using numeric ID's like in #4305 but instead using numeric nicenames.

I do this to get something like:
mysite.com/members/123456
where 123456 is their ID number from a totally different system.

So because of this, it passes that as their "Username" with compatibility mode and because of the patch in #4305 it's doing a check if the value is numeric. It IS so it then checks if that user exists in the system. Well our system is massive, so there IS a wordpress user with the ID 123456.

When it does this, it then switches the recipient from the intended user, to the one with the wordpress user id (in this example 123456) this is a big error as we use the PM system as internal communication and for all sorts of alerts...

So when we let 1000 people know they got paid, 1000 different people got the alert.

What I did is simplify RAY's code, I dont have a patchable tree so I'm just pasting my code:
Starting at line 75 of bp-messages-functions.php (1.8.1)

		if ( bp_is_username_compatibility_mode() )
				$recipient_id = bp_core_get_userid( $recipient );
			else
				$recipient_id = bp_core_get_userid_from_nicename( $recipient );
			if ( is_numeric( $recipient ) && !$recipient_id ) {
				// do a check against the user ID column 
				if ( bp_core_get_core_userdata( (int) $recipient ) )
					$recipient_id = (int) $recipient;		
			}

Sorry, it's tabbing out oddly, but basically I reversed his code to check if there is a username or nicename FIRST, then do a user ID check. If the username fails then the ID check is performed.

I've tested this and it's working on our site but Robl987 might want to test it too. I marked this major as without this fix at least 2 of my clients can't go beyond the modified versions of 1.8.1 I have them on now.

-D

[r-a-y]

Hi Dennis,

Thanks for the bug report. This makes sense.

Reversing the order will add a few DB queries, but this will fix this bug.

Tentatively moving to 1.8.2.

[r-a-y]

In 7462:

Check username column first before sending a PM to a recipient.

Previously, when sending a private message, a check was made against the
user ID column first to determine who the recipient is.

The problem with that is if:

1. A site uses numeric user_login / user_nicenames only; and if
2. A site has a large userbase

That the recipient might be calculated incorrectly because of the check
against the ID column first leading to unintended private messages being
sent to the wrong user(s).

This commit fixes this issue by reversing the look up so the user_login /
user_nicename DB column is checked first, followed by the ID column being
checked as a fallback if there is no initial match.

Fixes #5151.

Props DennisSmolek.