Fix two activation bugs in bp_core_activate_signup()#4899
Open
GaryJones wants to merge 1 commit intobuddyboss:releasefrom
Open
Fix two activation bugs in bp_core_activate_signup()#4899GaryJones wants to merge 1 commit intobuddyboss:releasefrom
GaryJones wants to merge 1 commit intobuddyboss:releasefrom
Conversation
1. Move xprofile data persistence before the $user_already_created early return, ensuring profile field data from signup meta is saved even when the user was pre-created by BP_Signup::add_backcompat(). 2. Stop treating zero affected rows from the user_status UPDATE as an activation failure. When wp_update_user() runs during registration it can reset user_status to 0 before activation, making the UPDATE a no-op. Since the activation key has already been validated, zero affected rows is not an error.
|
Thanks for your pull request. It looks like this may be your first contribution to the BuddyBoss Platform open source project. Please note that this project and all contributions to it are public and bounded by the GPL v2.0 license, and that a record of the contribution (including all personal information you submit with it, including your full name and email address) is maintained indefinitely and may be redistributed with this project. If you are not okay with these terms, please close this pull request. Alternatively, you can let us know about your concerns by adding a comment to this pull request. |
chetansatasiya
approved these changes
Mar 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
bp_core_activate_signup()inbp-members/bp-members-functions.phphas two related bugs that cause activation failures and data loss during user registration.1. Xprofile data lost for backcompat-created users
When a user is pre-created by
BP_Signup::add_backcompat(), the$user_already_createdflag is set and the function returns early. The xprofile data persistence block sits after this early return, so profile field data from signup meta is silently discarded. Users complete registration with all their custom profile fields, but the data never makes it into the xprofile tables.The fix moves the xprofile data block to before the
$user_already_createdearly return, so the data is saved regardless of how the user was created.2. False activation failure when user_status is already 0
The function treats zero affected rows from
UPDATE ... SET user_status = 0as an activation error and returnsWP_Error('invalid_key'). However,wp_update_user()can run during registration and resetuser_statusto 0 before activation occurs. When this happens, theUPDATEis a no-op (the value is already 0),$wpdb->query()returns 0, and the user receives an "Invalid activation key" error despite having a perfectly valid key.Since the activation key has already been validated by this point in the function, zero affected rows is not an error — the user is legitimate either way. The fix removes the return-value check from the query.
Test plan
user_statusis already 0 (e.g. because a plugin calledwp_update_user()during registration) — should succeed instead of returning "Invalid activation key"user_statusis non-zero) still works correctly