get_userdata returning full user object, not data like it used to

[anmari]

as per ​http://codex.wordpress.org/Function_Reference/get_userdata

get_userdata used to return the data part of the user object in 3.2.1

in latest nightly build it is returning the full user object.

If this is intentional, it could cause all sorts of plugins to break (including mine :) )

[ocean90]

Already mentioned in #18427.

[scribu]

get_userdata used to return the data part of the user object in 3.2.1

That is incorrect. In 3.2 and before, get_userdata() returned all the user fields mixed with user metadata.

Please describe the exact problem you're having in 3.3.

[scribu]

Also see #15458 for why this was done.

[anmari]

Hi re problem:
just that in nightly build if one calls get_userdata one gets a userobject, with amongst other bits $user->data.
$user->data is what used to be returned directly in 3.2.1 if one called get_userdata.

So I have added a little wrapping function so that my code will work in both 3.2.1 and in nightly build.

function amr_get_userdata($id){
	$data = get_userdata($id);    
	if (!empty($data->data)) return($data->data);
	else return ($data);
};

[scribu]

The WP_User object has ​magic methods that make it behave like in 3.2.

So, my question is this: did you actually test your plugins with the latest nightly build? If so, what errors did you encounter?

[scribu]

The idea being that you shouldn't have to change any plugin code to make it compatible with WP 3.3.

[dd32]

get_userdata used to return the data part of the user object in 3.2.1

That is incorrect. In 3.2 and before, get_userdata() returned all the user fields mixed with user metadata

Just to clarify that, Yes, The return value has changed, a WP_User object is returned instead of a dumb object. However, through the usage of magic methods, data fields (such as the meta key rich_editing), get_userdata(1)->rich_editing will map to get_userdata(1)->data->rich_editing, even though in a var_dump() or similar will not show these extra fields.. So you shouldn't need to use the code in comment:4 as it should just work (Side note: The code in comment:4 will actually break, in the sense that it will not include the meta fields, it'll only contain the user row data)

[anmari]

Hi all,
Thank you for taking the time to explain.

On $user_info->user_login I was getting

Notice: Trying to get property of non-object in..

and then when I var_dumped and saw what I saw, I thought that was the reason. However on digging deeper I realised the call was in a loop however I was only getting the notice once . IE there was a data problem which resulted in the code having a userid for a user that was not there!

So anyway I learnt something - one cannot always trust a var_dump! (and to add more checks in the code!)

I have made a note in the Codex in case anyone else manages to confuse themselves. ​http://codex.wordpress.org/Function_Reference/get_userdata#Notes

[anmari]

Sorry for re-open - just wanted to make the note for others who end up here that it appears one can then NOT 'iterate' (eg: with foreach) through the user data like one used to.

get_userdata will not actually fetch all the meta data - it will only fetch by magic method when specifically called.

So if one wanted to fetch ALL metadata whatever was there for whatever reason, one must find another means. Looks like get_user_metavalues($ids).

[scribu]

Yes, unfortunately foreach ( (array) $user as $key => $value ) doesn't work anymore, but it was a bad practice anyway. You're almost always only interested in the metadata.

[scribu]

To get all the metadata you can use get_user_meta( $user_id ).

[beezeee]

FWIW foreach ((array) $user as $key => $value) is a bad practice ASSUMING you only want the meta data. Assuming is bad practice too, especially when making assumptions about the way developers are using one of the most widely adopted platforms in this sphere.

I personally was doing exactly this to aggregate user data agnostically, so that we can render disparate elements for a collection of users with the minimum queries required. Fortunately this only took a wrapper function and a few lines of code to detect version and format an array accordingly if needed.

Going forward, I think it is crucial for WP development to maintain backwards compatibility.

While I agree that lazy loading meta is generally a great practice, it makes far more sense to introduce a new function that provides this lighter response, rather than overwriting existing ones potentially breaking code built to work on top of those existing functions.

Let's please consider the developers using the platform before pulling the rug out from under with a hasty modification like this, no matter how justifiable the intentions are.