I did try using the plugin Front End Users but this clashes with something as it prevents access to some front end pages. So I need to manually just set it so that anyone who isn't one of two usernames (or roles) can't access wp-admin.

6 Answers 6



It's basically just a user capability check, followed by a redirect in an exit call. It then redirects to the site the request came from.

! defined( 'ABSPATH' ) AND exit;
/* Plugin Name: (#66093) »kaiser« Deny Admin-UI access for certain roles */

function wpse66093_no_admin_access()
    // Do not run if the user is logged in and trying to log out
    // This might need one or two more checks.
    // Especially if you have custom login/logout/reset password/etc rules and routes set up.
    if ( 
        ! is_admin()
        || (
            && isset( $GLOBALS['pagenow'] ) AND 'wp-login.php' === $GLOBALS['pagenow']
    ) {

    $redirect = isset( $_SERVER['HTTP_REFERER'] ) ? $_SERVER['HTTP_REFERER'] : home_url( '/' );
    if ( 
        current_user_can( 'CAPABILITY_NAME_HERE' )
        OR current_user_can( 'CAPABILITY_NAME_HERE' )
        exit( wp_redirect( $redirect ) );
add_action( 'admin_init', 'wpse66093_no_admin_access', 100 );

Keep in mind that should only work with defaults (see comments in code). Custom login, logout, register, password reset logic might breaks this.

Roles vs. Capabilities: As role names can change and as roles are just groups of capabilities, it's best to check against a capability, not a role name. You can find a list of built in roles and capabilities here. Just look at what the most restrictive access is and search for a matching capability. Then assign it above. That's easier to maintain, in case a role name changes. Yes, you can use a role name as well, which will work in WordPress, but it's a concept that will bring along a hard to track down bug when a role name changes.

Note: Do not think about roles in a hierarchical manner. Think about the accountant whose email address you enter in some SaaS backend to receive the invoice. Most developers will not have access to billing details and neither will the accountant have access to deployment settings or security credentials. They have differently named roles with equally "high" capabilities, but for completely different parts. Keep this example in mind, when you write capability checks or add custom capabilities to a system.

  • so I put this at the top of my functions.php file?
    – Claire
    Sep 24, 2012 at 12:54
  • 1
    Either somewhere in your functions.php, or in your plugin or mu-plugins folder. As this isn't something about displaying stuff, it belongs imho in a plugin, hence the plugin header. This has the benfit that this functionality doesn't get lost, when you're changing your theme. Just change the user role names, upload it and you're done.
    – kaiser
    Sep 24, 2012 at 12:59
  • It doesn't work. I changed the user role names to my two roles than can access it. Then I changed it to a capability e.g. Add users and I am still able to access the backend as another user role
    – Claire
    Sep 24, 2012 at 15:28
  • 1
    @Nicola There's a huge difference between a label in the UI (for e.g.: "Add users") and a real Role or Capability - in your case add_users.
    – kaiser
    Sep 24, 2012 at 17:07
  • 3
    Remember to check for defined('DOING_AJAX') if you have AJAX calls in frontend, or they will be blocked!
    – Ste_95
    Aug 19, 2020 at 6:46

Just revisited that answer as it wasn't updated in a long time. Year is 2021.

The accepted answer is checking whether the current page is a wp-login.php page OR an admin page WHILE using an admin_init hook, this is nonsense.

admin_init fires as an admin screen or script is being initialized. It does NOT just run on user-facing admin screens. It runs on admin-ajax.php and admin-post.php as well.

In no cases whatsoever will it fire on a wp-login.php as it is NOT an admin screen. Tho it will indeed fire upon an ajax request, therefore that case should be handle. wp_doing_ajax() determines whether the current request is a WordPress Ajax request.

In the following example I'm using the delete_posts user capability to allow admin, editor and author access to the Wordpress backend. Refer to the Capability vs. Role Table for a more restrictive approach.

As a reminder here are the default Wordpress roles (Summary of Roles):

super admin admin editor author contributor subscriber.

With a single site WordPress installation, Administrators are, in effect, Super Admins.

I've chosen to use wp_die() instead of blindly redirecting users. wp_die() offer some kind of user onboarding as it kills Wordpress execution and displays an HTML page with an error message. The same approach could be done with redirecting users to a 404 page. Anything that explain the situation is better than a blind home page redirect.

add_action( 'admin_init', 'restrict_wpadmin_access' );
if ( ! function_exists( 'restrict_wpadmin_access' ) ) {
    function restrict_wpadmin_access() {
        if ( wp_doing_ajax() || current_user_can( 'delete_posts' ) ) {
        } else {
            header( 'Refresh: 2; ' . esc_url( home_url() ) );
            $args = array(
                'back_link' => true,
            wp_die( 'Restricted access.', 'Error', $args );

To prevent the default redirection to the wp-admin.php upon login I'm using the login_redirect hook filter which Filters the login redirect URL. I'm redirecting them to their own profile page using get_author_posts_url(), but you can easily redirect to whatever page you would like. You could also conditionally redirect based on the user role (eg: admin to the admin page, rest to profile), everything is explained on the CODEX page example section.

add_filter( 'login_redirect', 'redirect_user_to_profile_on_login', 10, 3 );
if ( ! function_exists( 'redirect_user_to_profile_on_login' ) ) {
    function redirect_user_to_profile_on_login( $redirect_to, $requested_redirect_to, $user ) {
        if ( $user && is_object( $user ) && is_a( $user, 'WP_User' ) ) {
            $redirect_to = esc_url( get_author_posts_url( $user->ID ) );
        return $redirect_to;

The accepted answer mentions User Role but actually uses the function for User Capability

Here's the solution for User Roles

 function wpse66094_no_admin_access() {
    $redirect = isset( $_SERVER['HTTP_REFERER'] ) ? $_SERVER['HTTP_REFERER'] : home_url( '/' );
    global $current_user;
    $user_roles = $current_user->roles;
    $user_role = array_shift($user_roles);
    if($user_role === 'YOUR_USER_ROLE_HERE'){
        exit( wp_redirect( $redirect ) );

add_action( 'admin_init', 'wpse66094_no_admin_access', 100 );

Based on the answer provided by @kaiser (thank you btw), this is my working code, just in any case someone needs it. It is placed in functions.php file.

The condition used is, if the user can't manage_options or edit_posts.

function wpse66093_no_admin_access() {
    $redirect = home_url( '/' );
    if ( ! ( current_user_can( 'manage_options' ) || current_user_can( 'edit_posts' ) ) )
        exit( wp_redirect( $redirect ) );
add_action( 'admin_init', 'wpse66093_no_admin_access', 100 );

With @kaiser's answer I found you'll need to utilize admin_menu hook over admin_init as it fires before the !user_can_access_admin_page() check in wp-admin/includes/menu.php otherwise if the user doesn't have 'read' access to the dashboard they'll just get the 'You do not have sufficient permissions to access this page.' page rather than being redirected.


If you remove the read Capability from the Role the user will not be able to access the dashboard. They will get the following error:

You do not have sufficient permissions to access this admin page.

Reason: The current user doesn't have the "read" capability that is required to access the "Dashboard" menu item.

Ref: https://codex.wordpress.org/Roles_and_Capabilities#read

  • maybe worth noting that a user with no capabilities can still log in successfully and the admin bar is displayed.
    – kubi
    May 20, 2020 at 13:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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