WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there any conditional tag which will allow me to display the certain content only if the user is NOT a subscriber?

share|improve this question
up vote 7 down vote accepted
global $current_user; // Use global
get_currentuserinfo(); // Make sure global is set, if not set it.
if ( ! user_can( $current_user, "subscriber" ) ) // Check user object has not got subscriber role
    echo 'User is a not Subscriber';
    echo 'User is a Subscriber';
share|improve this answer

An even more simple way, than @Brady showed you is the using current_user_can:

if ( current_user_can( 'subscriber' ) )
    echo "Hi, dear subscriber! Glad seeing you again!";


There's also an equivalent for MU installations, named current_user_can_for_blog:

global $blog_id;
if ( current_user_can_for_blog( $blog_id 'subscriber' ) )
    echo "Hi, dear subscriber! Glad seeing you again on this blog!";

Behind the curtain

When looking at the source of the functions for single or MU installations, then you'll see, that both basically rely on wp_get_current_user() and then do a check for has_cap. Now if you want to see, where the cap comes from, then WP_User class/object comes into the game.

Other members of this set

Then there's also author_can( $GLOBALS['post'], 'capability' );. All those functions are inside ~/wp-includes/capabilities right below each other.

When to use what?

Now, where's the difference between current_user_can(_FOR_BLOG) and user_can?

  • user_can() is the newer one (since 3.1), but needs the user as object. So you can use it in cases, where you don't want to target the current user, but some users.
  • current_user_can_*() is obvious.
  • author_can() allows you to check capabilities against a post object. This object is only available for posts, that are already in the DB. So it's mainly for allowing/denying the access to specific post features.
share|improve this answer
This I feel needs to be updated, because: Do not pass a role name to current_user_can(), as this is not guaranteed to work correctly (see #22624). from the current_user_can() codex page AFAIK hasn't changed. – ialocin Aug 4 '14 at 21:59
@ialocin You can update that if you want (it's 2years+ old). You are basically right. On the other hand a role gets added as capability as well ;) – kaiser Aug 4 '14 at 23:47
I guess this should actually be enough for a remark/update, besides I'm lazy...too ;) – ialocin Aug 5 '14 at 8:41

Is this what you mean?

global $userdata;
if ( $userdata->user_level != 0 )//check user level by level ID
  echo 'User is a not Subscriber';
  echo 'User is a Subscriber';

More details on the ID's for different levels: http://codex.wordpress.org/Roles_and_Capabilities#User_Levels

There is also the current_user_can() function, which lets you denote specific capabilities for more flexibility. http://codex.wordpress.org/Function_Reference/current_user_can

share|improve this answer
Don't use user levels... Here is what codex says about it: To maintain backwards compatibility with plugins that still use the user levels system (although this is very much discouraged), the default Roles in WordPress also include Capabilities that correspond to these levels. User Levels were finally deprecated in version 3.0. – Brady Jul 31 '12 at 8:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.