wp_update_user breaks when passed WP_User instance

[rmccue]

Supposedly fixed in #21429. (Tangential to #28019)

If you pass a WP_User instance to wp_update_user, it first calls WP_User::to_array, which returns the user data from the DB. This is then treated as the input data.

The problem then is that $userdata['user_pass'] is always set, as it's always included in $userdata. This then gets double-hashed by wp_update_user. (wp_update_user will then update the cookies, so the user won't notice until they're logged out)

To reproduce:

<?php
$testuserid = 1;

$user = get_userdata( $testuserid );

echo 'Before: ' . $user->user_pass;

wp_update_user( $user );

// Reload the data
$user = get_userdata( $testuserid );

echo 'After: ' . $user->user_pass;

Current output:

Before: $P$BDqB8PmujqwtUNqnDW/aiQKuAEvm741
After: $P$BsqV0Lkka4QIWE9RaveZ49wvOMnHD//

This operation should have been a no-op, but isn't.

(Ticket previously stated this happens with wp_insert_user; this is incorrect, as wp_insert_user doesn't hash the password for updates.)

[tbcorr]

.diff file for ticket 28435

[tbcorr]

Contribution made during WordCamp Philly 2014 during contributor day.

[salcode]

Unit test

[tbcorr]

Updated path of diff file so it can be applied from the root directory. (my first patch...)

[wonderboymusic]

In 35116:

Users: when passing a WP_User instance to wp_update_user(), ensure that the user password is not accidentally double-hashed. This is terrifying.

Adds unit tests.

Props tbcorr, salcode.
Fixes #28435.

[danielhomer]

Shouldn't this be considered for 4.3.2? We use wp_update_user() in an author migration script and I nearly blatted over a hundred user passwords because of this bug, not to mention the spam from the email notifications.

[SergeyBiryukov]

In 35732:

Users: Move the tests added in [35116] and [35618] to a more appropriate place and give them a better name.

See #28435, #29880.