Make WordPress Core

Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#18551 closed defect (bug) (invalid)

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

Reported by: anmari's profile anmari Owned by: markjaquith's profile markjaquith
Milestone: Priority: normal
Severity: major Version: 3.3
Component: Users Keywords:
Focuses: Cc:

Description

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 :) )

Change History (17)

#1 @ocean90
13 years ago

  • Milestone changed from Awaiting Review to 3.3
  • Summary changed from Nightly Build - get_userdata returning full user object, not data like it used to - Is this intentional? to get_userdata returning full user object, not data like it used to

Already mentioned in #18427.

#2 @scribu
13 years ago

  • Keywords reporter-feedback added

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 mix of the user fields along with user metadata.

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

Version 0, edited 13 years ago by scribu (next)

#3 @scribu
13 years ago

Also see #15458 for why this was done.

#4 @anmari
13 years ago

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);
};

#5 @scribu
13 years ago

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?

#6 @scribu
13 years ago

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

#7 @dd32
13 years ago

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)

#8 @anmari
13 years ago

  • Resolution set to invalid
  • Status changed from new to closed

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

#9 @anmari
13 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

#10 @anmari
13 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

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).

#11 @scribu
13 years ago

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.

Last edited 13 years ago by scribu (previous) (diff)

#12 @scribu
13 years ago

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

Last edited 13 years ago by scribu (previous) (diff)

#13 @markjaquith
12 years ago

  • Owner set to markjaquith
  • Resolution changed from invalid to fixed
Last edited 12 years ago by markjaquith (previous) (diff)

#14 @markjaquith
12 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#15 @markjaquith
12 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

#16 @ocean90
12 years ago

  • Keywords reporter-feedback removed
  • Milestone 3.3 deleted

#17 @beezeee
12 years ago

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.

Note: See TracTickets for help on using tickets.