Signing up with a blog makes it impossible for the user to log in

[imath]

WordPress Multisite, blog and user signups on.
Register, activate. Then try to log in: it's impossible.

Problem is:
When the user registers he defines a password, we hash it into the signups table meta field. So we can't use wp_update_user(), else password would be hashed 2 times. So we're running an Update query to set the password.

It appears for this particular case that when xprofile_sync_wp_profile() hooks to bp_core_activated_user() the wp_update_user() function is using the cached user and the password WordPress generated automatically.

In the attached patch, i've also remove a wp_update_user() call (just before the query to update the password) as it's not necessary precisely because of xprofile_sync_wp_profile().

As i'm a bit lost with what milestone to put this ticket in, i leave you choose. But imho we should fix this asap.

[r-a-y]

Wow! Nice catch, imath! I wonder how long this has been like this?

I say commit to trunk and we'll let the lead devs decide if this should go to 2.6.x.

[imath]

@r-a-y yeah i wonder myself! I think it's been a pretty long time :(

I'll commit it to trunk asap :)

[DJPaul]

If we're breaking core WordPress functionality, it's a priority to fix, no matter how long it took for us to notice.

[imath]

In 10938:

Make sure the password is set to what user chose when signing up with a blog

When signing up, users choose their password and we are hashing them into the meta field of the signups table.
When users activate their accounts, we directly run a query to replace the password automatically generated by WordPress to what the users chose. For the "signup with a blog" case, it appears this is not taking in account because the created users is cached and the xprofile_sync_wp_profile() function is reseting the password to the cached version.
To avoid this, as soon as we run the direct query, we are cleaning the cached object of the created user.

See #7173

[imath]

@DJPaul we're not breaking core WordPress, but BuddyPress Core for the specific case of signing up with a blog.

The password is set to the generated WordPress one. So the user trying to log with the password he chose gets a wrong password error and needs to reset his password to being able to log.

If you think 2.6.2 is still the right choice, i'll commit to the 2.6 branch.

For now it's in trunk, but i left the ticket open for this eventuality :)

[imath]

Update @dcavins thinks we should commit it to 2.6.2 too. So i'll commit it in a few minutes ;)

[imath]

In 10939:

Make sure the password is set to what user chose when signing up with a blog

When signing up, users choose their password and we are hashing them into the meta field of the signups table.
When users activate their accounts, we directly run a query to replace the password automatically generated by WordPress to what the users chose. For the "signup with a blog" case, it appears this is not taking in account because the created users is cached and the xprofile_sync_wp_profile() function is reseting the password to the cached version.
To avoid this, as soon as we run the direct query, we are cleaning the cached object of the created user.

Fixes #7173 (2.6 branch)