New current_user_has_role function to work for roles like current_user_can does for caps

[sc0ttkclark]

current_user_can( 'capability' ) is great, but it would save some code and be more reliable if we had something like this for roles as a global function that's easy to get at:

current_user_role( 'editor' ) would return true if the user has the editor role, false if they weren't.

I'll work on a patch for this when I get a moment, this is just here to remind me and let others know what I'm thinking.

[SergeyBiryukov]

current_user_can( 'editor' ) also works.

According to PHPDocs, the parameter is either a capability or a role name:
​http://core.trac.wordpress.org/browser/tags/3.4.2/wp-includes/capabilities.php#L1194

However, there's some inconsistency (also mentioned in #20824).

On single site, current_user_can( 'editor' ) returns false for administrator, only current_user_can( 'administrator' ) returns true.

On Multisite, current_user_can( 'editor' ) returns true for super admin.

[sc0ttkclark]

Right, in the case of Multisite, this function would return true only if the use was that specific role.

But via the WP codex itself: ​http://codex.wordpress.org/Function_Reference/current_user_can

Do not pass a role name to current_user_can(), as this is not guaranteed to work correctly.

This would also mean if a capability is added that matches the role, there won't be confusion within the code as this function would only look at the actual roles.

[sc0ttkclark]

And maybe this function should be named current_user_has_role to make more sense.

[SergeyBiryukov]

Replying to sc0ttkclark:

Right, in the case of Multisite, this function would return true only if the user was that specific role.

From my testing, it's vice versa, that's only the case on single site.

Do not pass a role name to current_user_can(), as this is not guaranteed to work correctly.

Looking at the page history, seems that the sentence was also added because of #20824.

[knutsp]

-1

Plugins should check for capabilities, not roles. Roles are arbitrary names for collections of capabilities that happen to be on the site. Sites uses custom roles for their users will suffer if and when role checking becomes more common that it already is.

To save some code lines, or elements of logical expressions, is not a use case.

[sc0ttkclark]

Capabilities are great, but when/if roles get beefed up (multiple roles per user), this is going to be more handy for developers of sites. You're right though, plugins generally don't have a huge use for this on their own, it would be specific to each site, but still useful.

[nacin]

I think we need to draw a line in the sand here.

• Roles are merely a grouping of capabilities that can be assigned to a user. Only capabilities should be checked, not roles. If you need to know specifically what role a user has, there are a number of ways using the existing API.

• A new function like this is ripe for abuse. We need people to check for capabilities, not roles, and having a current_user_has_role() function is just asking for them to do things wrong. We still haven't gotten people to stop checking for user levels, let's not go in this direction.

[SergeyBiryukov]

Going to close per comment:10. Here's a simple function I would use to get a user role:

function get_user_role( $user_id = 0 ) {
	$user = ( $user_id ) ? get_userdata( $user_id ) : wp_get_current_user();
	return current( $user->roles );
}