Add get_user() function that maps to get_user_by()

[sc0ttkclark]

<?php
/**
 * Retrieve user info by user ID.
 *
 * @since 4.5
 *
 * @param int $user_id User ID
 *
 * @return WP_User|false WP_User object on success, false on failure.
 */
function get_user( $user_id ) {
        return get_user_by( 'id', $user_id );
}

Works like get_userdata but meets the standards of get_{object_type} we've put forth in get_post( $id ) / get_term( $id ) / get_comment( $id ) to make it easier for new developers coming into WordPress.

I imagine at some point we could deprecate get_userdata calls, but not sure that should be done in the same release this is introduced.

[SergeyBiryukov]

Previously suggested in comment:24:ticket:21120.

[joedolson]

This really makes sense; it may be a fairly minor change, but it enhances the understandability of the code base.

[kushang78]

Added patch for this ticket.

[kushang78]

I’ve added the latest patch.

Patch includes below changes:

• Added get_user() - that maps to get_user_by() in the replace of get_userdata().
• There are plenty of files that contains get_userdata() function. Successfully Replaced with New get_user() function.
• The root file of this function - src/wp-includes/pluggable.php

[sc0ttkclark]

Renaming the usage everywhere seems ok to me but not required IMO.

The renaming the function itself should be changed, keep the old function in place but have it call get_user() and then bring the logic into the new function with new phpdoc @since for 6.5.

[joedolson]

We can't just remove a function that simply; get_userdata is extremely widely used, and this change would create a lot of breakage. We can alias it, but removing it is not so ideal.

The big question here is whether we might want to deprecate get_userdata when we add get_user. It's a simpler construction, more predictable, matches more other existing function naming patterns.

I'm not sure this will be ready for 6.5; I haven't had time for it, but I'm going to re-milestone to 6.6.

[kushang78]

Added patch for this ticket.

[kushang78]

@sc0ttkclark ,

As per your feedback, I’ve made the changes accordingly in the attached latest patch.

The changes:

• Pointing the new get_user function under get_userdata without touching the entire core functions.

@sc0ttkclark @joedolson,

Can you please check my latest patch and drop your feedback on it.

[oglekler]

I believe we need a decision if we are doing this or not, and do whatever will be decided. We have like 2 weeks until Beta 1, so, this is the time. New function is an enhancement.

[oglekler]

We have 2 days before Beta 1 and no concrete decision, so, I am moving this ticket to the next milestone for further consideration.

[peterwilsoncc]

I think adding an alias is the most that can safely be done with this. The functionality would need to remain in get_userdata() as it's a pluggable function so there's no way of knowing whether the function is Core's or a plugin's.

If an alias is added, it doesn't need to be pluggable and can be placed among the standard user functions. That will ensure that plugins continue to plug the correct code.

I do like the idea, it's a much nicer name and inevitably what I reach for when trying to get a user only to discover that it's not there.