Make WordPress Core

Opened 16 years ago

Closed 11 years ago

#8911 closed feature request (duplicate)

Use $WP_User as the standard unit of user information

Reported by: jeremyclarke's profile jeremyclarke Owned by: jeremyclarke's profile jeremyclarke
Milestone: Priority: normal
Severity: normal Version:
Component: Users Keywords: needs-patch
Focuses: Cc:

Description

Right now much of the core code and most plugins use the old get_userdata() function to fetch information about users. This works okay for most cases but fails to take advantage of the new $WP_User object type. Using the objects makes the user information much more powerful because you can immediately call methods like $user->has_cap('edit_posts') without messing around. It also just makes sense, and not using the pretty object is silly.

In some places, like edit-user.php, where more functionality is needed there are functions like get_user_to_edit() that make use of the $WP_User object. I think that WP should clearly move towards always using the modeled object version rather than the straight db version in all places, and encourage plugin authors to do the same.

Luckily the $WP_User wrapper uses get_userinfo to fetch its data and rewrites all the elements into its first level, so effectively the resulting object from $WP_User has all the same data as get_userinfo() and thus deprecates perfectly in all situations.

My proposal would be to create a new wrapper function to be used instead of get_userinfo():

get_user($id, $name = '')

This would just initiate the object and return it, similar to get_post. It's also fits much better in the overall naming conventions of wp with friends like get_term.

If possible, it might also be good to move the actual database sql from the get_userdata() function into the $WP_User object definition somewhere, that way its all in one place. Looking at it now it also seems like the whole _fill_user() function thing could be done more elegantly to explain itself and the cache better. [problem: pluggable.php has get_userdata(), which complicates things]

Finally, since get_userdata() currently calls _fill_user() every time then fetches all meta_value/key's for the user, wouldn't it be faster to make just one db call that fetches the row from wp_users AND the values from the usermeta table? If you are checking 30 users on your page for some reason (say, a twitter style list of your authors in the sidebar) that would save 30 database connections, which makes a difference no matter what!

[probably should be in another ticket, but it would also be great to have access to a global function get_users() that fetched a set of users (say, active ones or a specific role) all at once based on criteria like get_terms() or get_posts(), it would save time if you are getting many users and if it added them all to the cache after fetching it would probably be a lot faster than checking each user individually]

I'm very interested in feedback. I'll try to work on a patch at some point soon (mental note: before 2.8 feature freeze)

Change History (7)

#1 @jeremyclarke
16 years ago

Note: get_userdatabylogin() seems like it could be improved during the process.

#2 @ryan
16 years ago

  • Component changed from General to Users

#3 @Denis-de-Bernardy
16 years ago

  • Keywords needs-patch added
  • Milestone changed from 2.8 to Future Release
  • Type changed from defect (bug) to feature request

further note:

get_user() should accept a single arg, numeric (user_id) or string (user_login or user_email).

#4 @ptahdunbar
15 years ago

  • Cc ptahdunbar added

#5 @F J Kaiser
15 years ago

  • Cc 24-7@… added

I made a plugin some time ago to get a better oversight on this: http://wordpress.org/extend/plugins/your-friendly-current-user-deamon/stats/ It's only halfway finished, but from my insights so far, i can only aggree: +1

#6 @scribu
14 years ago

+1 on the idea.

Related: #15458

#7 @nacin
11 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed

I went down this rabbit hole in #21120. Keeping a function is helpful for performance.

Note: See TracTickets for help on using tickets.