When building a WordPress website, it’s often useful to provide content or functionality based on a user’s role or capabilities. For example, you may want to display some special content on your site – but only for administrators. That’s just one of many possibilities.
It’s quite handy that WordPress has a built-in function to help. The
current_user_can() function allows you to check the permissions of logged-in users. Based on that information, you can provide them with whatever special goodies you like. Conversely, you can also turn off certain items as well.
Keeping with the previously mentioned special content example, we’ll dive into a few basic snippets that let us add this functionality.
Example 1: Administrators Only
In this example, we’ll check to see if the logged in user visiting our page is a site administrator. If they are, a little welcome message will be displayed.
Before we go into the code, it’s worth noting that there is more than one way to check a user’s permissions. The WordPress Codex states that we can provide an existing user role inside the
current_user_can() function, however, it’s not recommended. There could be inaccuracies that lead to the wrong thing taking place.
Instead, we can use the capabilities of that particular user role. There’s a complete list of what capabilities each user role has in the Codex. So, rather than check if the user is an administrator, we can check if they have a specific capability, such as activating plugins.
Now, let’s see some code. The following would appear within the theme template of your choice.
<?php if ( current_user_can( 'activate_plugins' ) ): // check for a capability that only admins have ?> <p>Howdy, Administrator!</p> <?php endif; // end of user capability check ?>
In this case, we’re checking to see if the user is able to activate plugins – something only administrators (and, on multisite installs, super administrators) have the ability to do.
Example 2: Let’s Get Personal with Members
While the first example displayed a generic message, we can also create a more personalized experience. This is especially important if you’re running a membership site. It helps to build that extra sense of community.
Here, we’ll add a personal message including the user’s first name. We can tap into this information via the
get_current_user() function. We’ll also assume that our members are assigned the role of subscriber within WordPress.
<?php $current_user = wp_get_current_user(); // grab user info from the database if ( current_user_can( 'read' ) ): // 'read' is the lowest level capability ?> <p>Howdy, <?php echo $current_user->user_firstname; ?>! Thanks for being a part of our community.</p> <?php endif; // end of user capability check ?>
Incidentally, the ability to read a post is the lowest level capability within WordPress. Therefore, it applies to every user level – not just subscribers. This just ensures that we haven’t left anybody out.
Beyond checking for the read capability, we’re also displaying the user’s first name in the message. However, there are more possibilities with regards to user data that could be added to the mix.
Example 3: A Custom Header, Based on User Capabilities
For our last example, let’s do something a little more dramatic. We’re going to serve up different theme headers, depending on what capabilities a user has.
get_header() function, WordPress allows for the use of multiple header files. And displaying them based on user conditions can be very useful. For instance, a site’s member might benefit from a header that is highly-personalized. Non-members could then see something more generic.
In our code, we’ll again check to see if our users have read capabilities. And we’ll also add an extra check to ensure that they are logged in, via
is_user_logged_in() – just for good measure.
If you’re using this code in a project, it would replace
<?php get_header(); ?> throughout your templates.
<?php if ( current_user_can( 'read' ) && (is_user_logged_in) ): // the user can both read posts and is logged in ?> <?php get_header( 'members' ); // load header-members.php for site members ?> <?php else: ?> <?php get_header(); // the default header.php, for non-members ?> <?php endif; // end of custom header conditional ?>
Above, we’re checking to see if the user has the right capabilities and that they are indeed logged in. If both items return as true, a custom header file is shown. Otherwise, our theme’s default header will be displayed.
An Opportunity to Do More for Users
The examples above are just little ways that we can improve the user experience. But there is also the potential to do so much more. Really, the only limitation is your own imagination!
So, the next time you build a WordPress site, look for ways to provide users with features based on their roles and capabilities. They’ll appreciate the effort and you’ll have built a more complete website.
- The WordPress header.php Template File: Do’s and Don’ts of Good Header Design
- Unraveling the Secrets of WordPress’ comments.php
- How to Remove PHP out of WordPress Template Files and Placing it in Dynamic Pages and Posts
- An Early Look at Full Site Editing in WordPress
- The Challenge of Switching from a Page Builder to the WordPress Gutenberg Block Editor
- When Do You Need a Custom WordPress Gutenberg Block?
- How to Update WordPress Themes and Plugins with a ZIP File
- Signs Your WordPress Website Has Outgrown Its Hosting