Buddypress should set user meta for single sites in bp_core_signup_user

[StijnDeWitt]

I am working on a website on which users from different sources will be logging in. Some are existing users that I will perform custom authentication on and from code will be creating WordPress / BuddyPress accounts for (using function bp_core_signup_user). Others will register themselves in the regular way.

I want to prevent sending activation emails only for those users that are already registered (and activated if you will) in the external system. I looked into this subject and came to the conclusion that I should implement a filter hook for 'bp_core_signup_send_activation_key', returning false to prevent BuddyPress from sending an activation mail. The problem I am facing is that inside the filter hook I have no idea where the user came from originally. I can get access to the current user, but because BuddyPress only just created that user there is nothing on it that helps me differentiate.

Before calling bp_core_signup_user, the user does not exist yet, so I cannot update_user_meta on it... By the time the call to bp_core_signup_user has completed, my bp_core_signup_send_activation_key hook has already been called and it's too late.

The solution might be simple. I see that bp_core_signup_user accepts an argument $usermeta. For multi-sites it just passes this argument on to wpmu_signup_user which adds it to the user account. However, for single sites it does something spiffy with it for xprofile, but further ignores it. If it would add the user meta that remains after updating the user's xprofile, before calling the action hook, I could just pass on the user's account type in the $usermeta argument to bp_core_signup_user and then in my bp_core_signup_send_activation_key hook check this meta. Alternatively, you could pass on the $usermeta parameter to the bp_core_signup_send_activation_key directly when calling apply_filters. In any case I think having access to this meta in the filter hook would be really useful for other BuddyPress users as well.

The way it is now, I see no other alternative than to either change the BuddyPress core function, or instead of calling it, copy it to my code and change it there (which is what I intend on doing).

I consider the fact that BuddyPress attaches the meta for WPMU sites but not for single sites as a bug. Sorry if I'm wrong about that.

Disclaimer: I'm pretty new to WordPress / BuddyPress so I could be overseeing some really simple/elegant solution. Don't hesitate to close this bug if that is the case.

[boonebgorges]

Hi StijnDeWitt - Thanks for the report and the thorough background research.

I consider the fact that BuddyPress attaches the meta for WPMU sites but not for single sites as a bug. Sorry if I'm wrong about that.

You are wrong :) In non-MS, we create a user (with user_status = 2) immediately at registration time (ie, pre-activation), because non-MS WP does not have the concept of a "signup". Because we have a real user at that time, we are able to add the necessary xprofile data right there in bp_core_signup_user(). On Multisite, the WP user is only created at activation, so we do the same thing with xprofile data only at activation: ​https://buddypress.trac.wordpress.org/browser/branches/1.9/bp-members/bp-members-functions.php#L1341. So, we really do use the $usermeta in more or less the same way on MS vs non-MS - just at different times in the process.

A big fat caveat to the above explanation: this is all changed for BP 2.0. In the future, even non-MS sites will use wp_signups. So it'll be much more consistent and transparent for intrepid explorers like you :) See #4651.

So anyway, back to your issue.

If it would add the user meta that remains after updating the user's xprofile, before calling the action hook, I could just pass on the user's account type in the $usermeta argument to bp_core_signup_user and then in my bp_core_signup_send_activation_key hook check this meta

This is a clever idea, but I think it needs some more research before we implement anything like it. It's possible that people are putting any manner of weird payload into this usermeta (via plugins, etc), so we shouldn't be assuming it's safe or wise to insert into wp_usermeta.

Alternatively, you could pass on the $usermeta parameter to the bp_core_signup_send_activation_key directly when calling apply_filters.

Yes. I'm surprised we don't do this already. I'm going to make this fix right away. Please let me know if it's enough for your purposes.

[boonebgorges]

In 8186:

Pass additional data along to bp_core_signup_send_activation_key filter

See #5481

Props StijnDeWitt

[StijnDeWitt]

Wow thanks Boone! It should definitely be enough for me if you pass it on in apply filters.
Should I close this issue? Knowing it will eventually be possible to do this in a clean way is enough for me.

I am not sure I understand your explanation about multisite. Not contesting that I'm wrong though :) But I saw that in case of multisite it was passing on the $usermeta to wpmu_signup_user and the ​WordPress Codex suggests that it's then stored in the database. Whereas for single site I don't see how the $usermeta could make it's way into the database. I did not read the actual code for wpmu_signup_user though, and the info in the Codex is quitte scarce, so I'm not sure. I guess I have some reading up to do if I really want to understand the WordPress / BuddyPress user registration process.

[boonebgorges]

At the moment, it is easier to delete all associated comments when a post is trashed than worrying about re-recording the activity stream items in their rightful slot for post comments when a post is untrashed. Let me know if this is a dealbreaker.

This is more or less correct. On MS, the data is stored in the wp_signups table so that it can be used after activation. (This is necessitated by the fact that no user yet exists, so you can't use usermeta.) On non-MS, BP uses the $usermeta values *right away*, so there's no need to store them. So, there is a disparity between how the two are handled, but functionally $usermeta does the same thing in both cases.

At the moment, it is easier to delete all associated comments when a post is trashed than worrying about re-recording the activity stream items in their rightful slot for post comments when a post is untrashed. Let me know if this is a dealbreaker.

Oy :) If you find a good resource, let me know. Everything I know I have learned from years of reading the source :)

Thanks again for the report!

[StijnDeWitt]

Hi Boone, I can work now and do what I need. I will just do the same change on the current version of BP that we have and refer to this ticket.

At the risk of nagging, I want to respond once more on the difference/similarity of handling the $usermeta paramater to the bp_core_signup_user function.

You say:
"On MS, the data is stored in the wp_signups table so that it can be used after activation."

And yes, I see this happening as $usermeta is passed on to the call to wpmu_signup_user. This happens unconditionally, it does not matter whether you use xprofile or not, and it uses all values from $usermeta.

"On non-MS, BP uses the $usermeta values *right away*"

And here is what I don't get. If this line in bp_core_signup_user returns false:
if ( bp_is_active( 'xprofile' ) ) {
then how are the $usermeta values ever used?

In my mind, in MS sites, $usermeta is always used, completely. In non-ms sites, it is only used if you use xprofile, and even in that case only the usermeta for key profile_field_ids.

Probably I am completely confused, but it sounds to me like your description of what is happening in non-MS mode is exactly the opposite from what is happening in reality... If I'm wrong, then can you tell me by what mechanism the $usermeta is used in non-MS sites when xprofile is not used or there are no values in $usermeta with key profile_field_ids? I can't find how they would ever make their way into the created user's meta?

[boonebgorges]

In my mind, in MS sites, $usermeta is always used, completely.

This is not true. I think the variable name $usermeta is confusing you. It doesn't have anything to do with the wp_usermeta table. It's just a generic bucket for data that is provided at signup but cannot be used until after the user is created. On MS - without BP installed - it's used to store the registrant's chosed blog URL, blog name, and the privacy setting of the newly created blog. See wpmu_create_blog(). It is never inserted into wp_usermeta.

BuddyPress uses this generic bucket to store xprofile data provided by the user at registration. When the user account is activated (immediately on non-MS, after the activation link is clicked on MS), we take any xprofile data from that bucket and store it in our xprofile db tables. If xprofile is not active, there is nothing to do.

One bit that you are correct about is that, in the case of non-MS, the value of $usermeta is not stored in the database. It's "faked" by BP just to match MS's default behavior, and once it's used, it's immediately discarded. (There's no blog URL, etc to store anyway.) But, again, note that this will change in BP 2.0, when all signups are treated in the way that MS treats them currently.

To reemphasize: the $usermeta values here are *never* stored to wp_usermeta. It's a confusing naming convention.

[StijnDeWitt]

Yes you nailed it. Indeed the naming was what was confusing me and the WordPress Codex does nothing to reduce this confusion. Now I get your explanation.

Thanks for taking the time and patience to spell it out for me. I am a person that wants to know everything up to the lowest level, *and* I am very stubborn. It's a combination that can be very annoying to others :)