So, I have spent a number of hours debugging the code to find the exact moment of when the user ID changes.
TLDR; If you're using the plugin smart User Slug Hider, update to latest version, go into it's settings and enable the setting "Activate Future Safe Mode".
longer explanation:
WPLMS passed a user ID to Buddypress to send a message to the user about their new assignment results. Buddypress has a few verifications that it goes through with the passed in "recipient" as it allows passing in of ids and usernames. Its goal is to change all recipients from usernames to ids and verify that the recipients passed in actually exist before doing any work.
So buddypress checks the username first, which passes through a wordpress function which "smart user slug hider" has a hook on that filter to run it's code. Smart User slug hider then runs the input (this being a user_id at this stage) through it's "decrypt" code and uses the php function mcrypt_decrypt which has been deprecated in PHP 7.1.0 and removed in 7.2.0 (
http://php.net/manual/en/function.mcrypt-decrypt.php). when User_ids were passed into this bit of code, it would "Decrypt" or do whatever it does and just pump out another number which had the same amount of numbers (in this case 3 digit number) which is why we had some users receiving feedback and others not. When the number that is pumped out of the decrypt function did not exist as a user then the buddypress would continue it's code and check the normal user id... or something like that.
So. if anybody uses the plugin "smart User Slug Hider" to protect their users privacy, it is highly recommended they enable the setting "Activate Future Safe Mode" as not to have strange things happen on their site.
WPLMS maybe you want to make an announcement to your users about this?
FYI, I did not find that caching caused any of the issues here
.
