[wp-trac] [WordPress Trac] #16841: Manually created user roles not showing in author dropdown regardless of assigned capabilities

[WordPress Trac]

#16841: Manually created user roles not showing in author dropdown regardless of
assigned capabilities
-----------------------------+------------------------------
 Reporter:  10sexyapples     |       Owner:
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Role/Capability  |     Version:  3.1
 Severity:  normal           |  Resolution:
 Keywords:  2nd-opinion      |     Focuses:
-----------------------------+------------------------------
Changes (by lgladdy):

 * keywords:   => 2nd-opinion


Comment:

 This is going to be harder than I originally thought.

 As earlier in the post, the code at fault here is at
 https://core.trac.wordpress.org/browser/trunk/src/wp-
 includes/user.php#L714

 If you provide a 'who'=>'authors' key to a get_users command it will
 return all users with a level greater than 0 using a meta query.

 There is no nice way (that I can see) within WP_User_Query::prepare_query
 for us to do anything smart with capabilities, so i'm thinking there maybe
 4 ways to try and fix this.

 1) Not use the 'who'=>'authors' key at all, and do a get_users() query to
 get all the users and then loop through to check their capability. This
 probably has the potential to be seriously slow on sites with many users?

 2) Loop over all the roles, figure out which have edit_posts cap on them
 and then do a get_users/WP_User_Query query, either using the role option
 (it currently only supports one role per query, so maybe that could be
 expanded to support an array of roles? or multiple queries and merge).

 3) Add a new capability option into WP_User_Query. This would basically be
 number 2 anyway - we'd just need to get the wp_user_roles option to figure
 out the list of roles, and then run that as a query similar to a multiple
 role search, but someone more familiar with core coding standards, the
 WP_User_Query class or the Role/Capability component maintainer(s) should
 be able to say if this is a good idea.

 4) Do something inside WP_Roles::add_cap or, more likely,
 WP_User::update_user_level_from_caps - We could also check if the user has
 edit_posts and if so, set their default level_* to 1, rather than 0. This
 seems a bit evil because it's a workaround to legacy/deprecated level_*
 syntax, and we probably don't want to introduce new code that touches that
 if the end goal is it not existing at all?

 I think 3 actually is a the best idea, depending on how acceptable it
 would be to use get_option inside WP_User_Query. It would solve the
 problem, and give developers more functionality.

 Thoughts?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/16841#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform