Hook during approval while activation key is valid

The biggest detail here is that we don’t prevent users from being able to go through the activation process. The work our plugin does comes afterwards, where until they’re approved, they can’t access the BuddyPress/bbPress areas of the website. However, they can do everything else around, like comment on blog posts, make purchases if you have an ecommerce setup, etc.

Depending on the settings you choose, they can either read but not interact, or if you go restrictive enough, they can only access their own BuddyPress profile.

Sorry, I’m not fully understanding. You say that your plugin doesn’t prevent users from being able to go through the activation process, but once I approve a user through your plugin their activation key becomes invalid? Are you saying that behavior is actually a bug?

I just did a clean wordpress install. Installed Buddypress and BP Registrations options as only plugins. Turned on allowing users to register in wordpress settings, and set all users must be approved in BPRO settings. Registered a new user through the frontend form, approved them through BP Registration Options, then tried to use their activation key and I got “Invalid Activation Key” and the user does not have any site roles defined.

Is this the expected behavior?

• This reply was modified 5 years, 4 months ago by atmojones.

If I comment out line 274 of admin.php from your plugin

bp_core_process_spammer_status( $user_id, 'ham' );

then approve a user, the activation key from the email still works and the user is assigned a Role.

It seems that during the activation process user_status is checked and if it is already set then the error “Invalid Activation Key” is returned.

What I’m saying is that Joe Smith goes to your site, clicks your register link, they fill out the form, they hit submit, they check their email that has their activation key/link, they click that, they get activated overall in terms of WordPress. What we do is we assign some user meta to their newly created user, and check against that value to see if they should be able to see BuddyPress and/or bbPress areas, and to what level they should see. There’s no dealing with the activation key from our plugin’s code, because it’s already been utilized and is no longer valid cause of no need to be.

Line 274 above is not utilized and run until you’re using our UI to approve the given user, and with the line we’re just helping make sure that BuddyPress isn’t still considering them as a possible spam user as well. Still well after the activation key has been utilized.

I agree that, in your scenario, everything works perfectly. The issue I’m encountering occurs when users do not activate their account immediately (either they don’t get the email right away, or get distracted, w/e) and the administrator approves their account through your UI. At that point the whole user activation process breaks. If your solution is that no user should ever be approved by an admin before the user has activated their account then I don’t think the user should appear in the “Member Requests” list of your UI until they have activated their account.

Ahh, you present what i’ll call a race condition for lack of better word, that we have probably under-considered.

This does have me wondering which occurs first, user activation through the activation link, or the user_register WordPress core hook. We tap into that hook to set our meta data and get the provided user ready for our moderation.

Perhaps we need to check if they have activated or not before we consider listing them. I don’t know the functions off the top of my head, but I have to believe there are BuddyPress functions we could use to check activation status.

That said though, how much need is there for them to click through the activation code, if you’ve already approved them. Not asking to get out of updating our plugin to better match, but just general UX. The idea of sending an extra email saying “you’ve already been approved, you can disregard activation” would be an option.

The problems with just sending another email saying “you’re approved, don’t worry about activating” is that 1) we don’t actually know if that is a valid email [they could have a typo during reg, it could be a fake email made by a bot] 2) The user is not assigned the default role that wordpress settings give to new users [the problem i’m experiencing that initiated this thread] 3) The user is not ever removed from the “Pending” list of the user section.

Issue 2 seems like the biggest problem and I will try to clearly track the issue through the code:

In your admin.php file on line 274 you call:

bp_core_process_spammer_status( $user_id, 'ham' );

That function can be found https://github.com/buddypress/BuddyPress/blob/master/src/bp-members/bp-members-functions.php. On line 650 it uses ‘ham’ to set $is_spam:

$is_spam = ( 'spam' == $status );

So, it gets the value 0, then on line 680 updates the wp_users table:

$wpdb->update( $wpdb->users, array( 'user_status' => $is_spam ), array( 'ID' => $user_id ) );

wp_users.user_status is now 0 and your user approval process finishes the rest of it’s code.

Then, the activation link in the email is used, eventually calling bp_core_activate_signup, which on line 1859 tries to update user_status to be 0:

if ( ! $wpdb->query( $wpdb->prepare( "UPDATE {$wpdb->users} SET user_status = 0 WHERE ID = %d", $user_id ) ) ) {

Because user_status is already 0, no rows are updated and the query returns 0 and the function returns:

return new WP_Error( 'invalid_key', __( 'Invalid activation key.', 'buddypress' ) );

Therefore line 1981 is never called:

do_action( 'bp_core_activated_user', $user_id, $key, $user );

which has attached to it:

bp_members_add_role_after_activation

So the user is never given a site role.

That is where the activation process conflicts with your plugins approval process. I am not thoroughly acquainted with buddypress or your code, so I don’t know the best solution here without potentially breaking something else, but without investigating or testing it seems like there are a couple possible solutions:

1) You could attach your code to a hook at the end of the buddypress activation process so admins aren’t notified about a user needing moderation and the user won’t appear in the moderation list until they have activated their account. But this might allow users to use the site without being moderated yet.

2) Add a column on the approval UI that displays if the user is activated. I think this could be checked by seeing if their user id has the activation_key meta key set in wp_usermeta. I believe once a user activates this meta key is deleted. This doesn’t really solve the problem so much as allow a competent admin to not cause the problem.

3) You could call the buddypress activation functions when a user is moderated as approved before calling the bp_core_process_spammer_status function. This has the problem of approving well crafted spam users and users that entered the wrong email. Although, I have only ever encountered 1 spam user that was not obvious.

4) You could just not call bp_core_process_spammer_status( $user_id, ‘ham’ );. Unless there is somewhere else in your code that would specifically mark a user as spam until this is called I feel like removing this and letting the user be marked as ham when buddypress/wordpress normally would might be a very simple solution.

I hope this is helpful, and I don’t mind doing some more investigation or testing if you need additional information. This is an issue that is occurring for me very often, I assume because activation emails are going to spam or because much of my user base is older and doesn’t understand the importance of activation.

• This reply was modified 5 years, 4 months ago by atmojones.
• This reply was modified 5 years, 4 months ago by atmojones.
• This reply was modified 5 years, 4 months ago by atmojones.

Taking all this into advisement and will mull over how to possibly help address this bit of an edge case.

Definitely appreciate all the brainstorming and ideas to help address the issue as well.

https://github.com/WebDevStudios/BuddyPress-Registration-Options/issues/178