XML-RPC: wp.getUsers, wp.getUser, wp.getProfile, wp.editProfile

[nprasath002]

By default only 50 users are returned. We can filter users by roles

[maxcutler]

Is there a reason that this method returns only a subset of the fields of the wp.getUser method in #18427?

Would it be easier to maintain if this method delegates to the singular version, as seen in the wp_getMediaLibrary method?

[nprasath002]

wp_getUser and wp_getUsers are simply wrappers for function get_user_data and get_users.
So these methods returns the same results of the functions used.

wp_getUser returns more info and costly.
There is a need to return only a subset of information for sites
having large number of users. If we use a singular version retrieving information
about 50 users would be costly

Alternatively we can have three methods like
wp_getUser
wp_getUsers
wp_getUserList

[maxcutler]

Going to use this ticket as the work ticket for #18424 (wp.newUser), #18425 (wp.editUser), #18426 (wp.deleteUser), #18427 (wp.getUser), and #18428 (wp.getUsers).

I've attached a combo patch with those five methods plus wp.getUserInfo (to replace blogger.getUserInfo). Also attached are unit tests for 4/6 methods.

With regards to field names, I chose to deviate from the WP_User names. To an outsider, the WP_User names are terribly inconsistent in format, and I wanted to avoid unnecessary pain. Feedback would be appreciated.

[zimbelp]

Have played with your plugin a little bit and had an additional question/request:

Is there any chance of being able to supply multiple roles to the call (i.e. I want to fetch admins and authors)? Or perhaps return the role names in the response so you can filter the results yourself?

It looked like the call was only expecting a single role name, but maybe I am missing something.

[maxcutler]

Multiple roles might be hard since the API this uses (get_users/WP_User_Query) only supports filtering to a single role.

There is a difference between my plugin and the combo patch, in that the combo patch includes a 'roles' field so that it's easier to filter the response on the client-side. I'll update my plugin at some point in the not-too-distant future.

[nacin]

get_users() does provide for 'who' => 'authors' which is going to be more useful to expose than just 'role'.

[maxcutler]

Replying to nacin:

get_users() does provide for 'who' => 'authors' which is going to be more useful to expose than just 'role'.

Perhaps you can shed more light on what exactly the who argument is supposed to do? As far as I can tell, the only value it accepts is author, which does user_level != 0.

Maybe it'd be better to let wp.getUsers' role take authors as a value (in addition to author and other individual roles) and convert that to who?

[mdawaffe]

We should be checking

current_user_can( 'edit_user', $user_id )

instead of

current_user_can( 'edit_users' )

where appropriate. The same goes for delete_user.

I also think we should be explicitly casting all input:

$username       = (string) $args[1];
// ...
$user_data['display_name'] = (string) $content_struct['display_name'];

but that's a general issue with all our XML-RPC methods.

It's strange that wp.editUser accepts user_contacts input, but wp.newUser does not.

The post endpoints provide post meta get/set. It'd be cool if the user endpoints provided user meta get/set as well.

[nprasath002]

Replying to mdawaffe:

We should be checking

current_user_can( 'edit_user', $user_id )

instead of

current_user_can( 'edit_users' )

where appropriate. The same goes for delete_user.

I also think we should be explicitly casting all input:

$username       = (string) $args[1];
// ...
$user_data['display_name'] = (string) $content_struct['display_name'];

but that's a general issue with all our XML-RPC methods.

It's strange that wp.editUser accepts user_contacts input, but wp.newUser does not.

To mimic wp-admin we dropped to support user_contacts when creating a new user. ideally the a user will be created by admin and after that that user will update his contact info.

The post endpoints provide post meta get/set. It'd be cool if the user endpoints provided user meta get/set as well.

[maxcutler]

I refreshed the patch and the unit tests to align with trunk and the refactored test suite.

As discussed in IRC last week, I'd like to replace user_contacts with meta/custom_fields, but ran into a number of questions regarding what APIs to use (get_metadata doesn't return meta_ids, so can't match API of wp.getPost) and which caps to check (no equivalent to edit_post_meta that I could see). I'll keep trying to flag down core devs in IRC to talk this through.

[maxcutler]

I've attached a new patch that covers a revised feature set for the 3.5 release as discussed in IRC (9/5/12 dev chat). Namely, wp.newUser and wp.deleteUser have been removed, and wp.editUser has been changed to wp.editUserInfo, which allows a user to edit his/her own profile fields, not including their password or email address.

[maxcutler]

Refreshed the new patch after a #wcbalt code-review with nacin:

• Renamed wp.getUserInfo to wp.getProfile and wp.editUserInfo to wp.editProfile.
• Fixed some doccomment mistakes.
• Remove overloaded 'role' parameter to wp.getUsers and instead exposed core's who => authors feature.
• Use list_users cap instead of edit_users cap for wp.getUsers.
• Removed user_level and capabilities from _prepare_user.

[nacin]

If a goal for wp.getUsers is to effectively replace wp.getAuthors, we'll need to allow for fields = 'authors' that matches wp.getAuthor's return values (but paginated, this time) and sticks to an edit_posts cap check, rather than list_users.

[nacin]

In [21824]:

XML-RPC: Introduce wp.getUsers, wp.getUser, wp.getProfile, wp.editProfile.

props maxcutler.
props nprasath002 for earlier patches.

see #18428.

[nacin]

​[UT1016]

[koke]

What do you think about adding a filter for $user_fields in _prepare_user? It feels like it could be useful to retrieve other custom user meta added by plugins

[maxcutler]

While writing docs for the codex, I found an inconsistency between what _prepare_user returns and what wp.editProfile accepts (url vs. website). I've attached a patch which resolves this.

[nacin]

In [21959]:

XML-RPC: Accept 'url', not 'website' in wp.editProfile. props maxcutler. see #18428.

[nacin]

Replying to nacin:

If a goal for wp.getUsers is to effectively replace wp.getAuthors, we'll need to allow for fields = 'authors' that matches wp.getAuthor's return values (but paginated, this time) and sticks to an edit_posts cap check, rather than list_users.

This still needs to be dealt with.

[markoheijnen]

Added get_userdata() to wp.getUsers so it can return all fields like wp.getUser

[markoheijnen]

I just added a patch what adds get_userdata() to wp.getUsers since it can't return things like firstname/lastname. I'm not sure if there is a better way to handle it.

I also added the field option 'authors' but didn't change the cap check. I do was wondering if wp.getAuthors isn't broken since there isn't really a check if the returned users are really authors

[nacin]

In [22134]:

Request WP_User objects when caling get_users() in XML-RPC's wp.getUsers method. see #18428.

[nacin]

What's left here?

[markoheijnen]

Is fine for me. Don't think we need fields = authors support

[nacin]

Closing as fixed for 3.5, then.