update_usermeta and delete_usermeta do not update or destroy cache

[mark8barnes]

User meta data is stored in the $current_user variable, which is created as GLOBAL by get_currentuserinfo. However, when update_usermeta and delete_usermeta are called, this variable remains unchanged.

Subsequent calls to get_currentuserinfo just return the existing global variable, and therefore return out of data meta information.

The solution is to check for the existence of the global variable $current_user within the update_usermeta and delete_usermeta functions and either update it or destroy it. Updating it might be more useful, and could be done without needing to recreate the whole variable.

The change could theoretically break plugins if they assumed the existence of the metadata in $current_userinfo, but I can't imagine why anyone would, and it would hardly be good practice if they did.

[nacin]

The *_usermeta functions are now deprecated. I imagine this applies to _user_meta as well though.

[nacin]

Patch looks like a good approach. We only need the call to setup_userdata() as that will handle creating a new WP_User object if necessary.

I think I agree with not using set_current_user/wp_set_current_user here, as I don't think we should be triggering the set_current_user action there. Unless that's used as part of caching?

Calling setup_userdata() in update_user_meta() and delete_user_meta(), right after the calls to update_metadata() and delete_metadata(), should complete this for the non-deprecated functions.

[nacin]

It's been pointed out (thanks hawy) that setup_userdata() is incorrect. Proper approach would be $GLOBALS['current_user'] = new WP_User($id, $name);

We shouldn't need to call setup_userdata() at all, as that doesn't set up any meta in the back compat globals it maintains.

[hawy.php]

Replying to nacin:

It's been pointed out (thanks hawy) that setup_userdata() is incorrect. Proper approach would be $GLOBALS['current_user'] = new WP_User($id, $name);

We shouldn't need to call setup_userdata() at all, as that doesn't set up any meta in the back compat globals it maintains.

we need setup_userdata() cause it fills the old global variable ( $userdata ) with user's metadata

so if we didn't call it
and assume we have meta_key = "somemeta" and it's value was "old_value"
and some one made

update_usermeta( 1, "somemeta","new_value");

then
var_dump($userdata);

we still get old_value

[nacin]

Stand corrected again... $userdata is populated with meta keys by _fill_user().

[hawy.php]

so the only edit here could be using super global $GLBALS as (nacin) wrote above instead of global $current_user;

[nacin]

We need to do this to _user_meta too. Questioning whether we should side-step wp_set_current_user (the sole purpose of which would be to prevent the action from firing) or not...

[nacin]

Assigning to ryan.

[ryan]

We'll probably want to fix this in clean_user_cache(). Since this is a long-standing bug, postponing to 3.1. Now that get_user_option() doesn't reference $current_user this is a lesser issue.

[ryan]

See #15559 and [16562]

[cronco]

Wouldn't adding wp_cache_delete($id,'user_meta'); in clean_user_cache take care of this and also clean up the code for *_usermeta a bit?

[ryan]

User and usermeta caching was fixed in 3.3.

[duck_]

Replying to ryan:

User and usermeta caching was fixed in 3.3.

Marking as fixed.