#22624 closed feature request (wontfix)
New current_user_has_role function to work for roles like current_user_can does for caps
Reported by: | sc0ttkclark | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Users | Keywords: | |
Focuses: | Cc: |
Description
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.
Change History (12)
#2
follow-up:
↓ 4
@
12 years ago
Right, in the case of Multisite, this function would return true only if the user 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.
#3
@
12 years ago
- Summary changed from New current_user_role function to work for roles like current_user_can does for caps to New current_user_has_role function to work for roles like current_user_can does for caps
And maybe this function should be named current_user_has_role to make more sense.
#4
in reply to:
↑ 2
@
12 years ago
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.
#8
@
11 years ago
-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.
#9
@
11 years ago
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.
#10
@
11 years ago
- Keywords close added
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.
#11
@
11 years ago
- Keywords close removed
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
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 ); }
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, onlycurrent_user_can( 'administrator' )
returns true.On Multisite,
current_user_can( 'editor' )
returns true for super admin.