When developing WordPress sites, especially front-end account areas and custom user workflows, we inevitably have to work with user data and user permissions. To keep those actions secure, we need a reliable way to determine what a user is allowed to do.
WordPress includes several helper functions that make it easy to check login state, roles, and capabilities. This article groups the most useful ones together.
Check whether a user is logged in with is_user_logged_in
This function is extremely simple and focused: it only checks whether the current visitor is logged in. It takes no parameters. If the user is logged in, it returns true; otherwise it returns false.
Check whether a user is a super admin with is_super_admin
This function can accept a user ID as a parameter. If no parameter is provided, it uses the current logged-in user ID by default.
On a single-site installation, the function effectively checks whether the user is an administrator.
If the checked user is a super admin or administrator, it returns true; otherwise it returns false.
Check what a specific user can do with user_can
This function takes two parameters. The first is a user ID or user object, and the second is a capability name or role name. If the user has that capability or role, it returns true; otherwise it returns false.
Check what the current user can do with current_user_can
This function is essentially a shorter and more convenient version of user_can. It removes the need to pass the current user ID explicitly, and it also includes an optional object_id parameter that can be used when checking object-specific capabilities.
Check what the current user can do on a specific multisite site with current_user_can_for_blog
This function is the multisite-oriented counterpart of current_user_can. It checks whether a user has a given role or capability on a particular site in a multisite network. The first parameter is the blog ID and the second is the capability or role name.
Check what the author of a post can do with author_can
This function is similar to user_can, but its first parameter is a post ID or post object instead of a user. That saves you the extra step of retrieving the author manually. The second parameter is still the capability or role name you want to test.
Where all of these user checks come from in WordPress
Looking at so many separate helper functions, it is easy to think WordPress makes capability checks more complicated than necessary. But if you inspect the source code, you find that these helpers all end up calling the same underlying capability logic: WP_User::has_cap.
In other words, these functions are mostly convenience wrappers added by the WordPress team so developers can use more readable and situation-specific helper functions.
