current_user_can capabilities in the admin not working as expected

admin管理员组

文章数量:1130349

I'm trying to block admin dashboard access using wp_redirect().

But the results of using current_user_can('edit_post') are unexpected.

See my complete function below...

/**
 * user constructor method.
 */
public function __construct()
{

    // block admin dashboard access
    add_action( 'admin_init', array( $this , 'block_admin_access' ) );

}

/**
 * block admin dashboard access to users who cant edit posts
 */
public function block_admin_access () {

    // if users cannot edit posts
    if( ! current_user_can('edit_post') ) {

        // redirect user to home page
        wp_redirect( get_home_url() );

    }

}

When I am logged in as an administrator user, this code above blocks me from the dashboard. Administrators can definately edit posts, so why does this code above redirect me away from the dashboard?

When I am using current_user_can('edit_post') on the front end, the behaviour is normal.

Does anyone know why this could be?

I'm trying to block admin dashboard access using wp_redirect().

But the results of using current_user_can('edit_post') are unexpected.

See my complete function below...

/**
 * user constructor method.
 */
public function __construct()
{

    // block admin dashboard access
    add_action( 'admin_init', array( $this , 'block_admin_access' ) );

}

/**
 * block admin dashboard access to users who cant edit posts
 */
public function block_admin_access () {

    // if users cannot edit posts
    if( ! current_user_can('edit_post') ) {

        // redirect user to home page
        wp_redirect( get_home_url() );

    }

}

When I am logged in as an administrator user, this code above blocks me from the dashboard. Administrators can definately edit posts, so why does this code above redirect me away from the dashboard?

When I am using current_user_can('edit_post') on the front end, the behaviour is normal.

Does anyone know why this could be?

• capabilities

Share Improve this question edited Dec 18, 2018 at 18:27 joshmoto asked Dec 18, 2018 at 18:20 joshmotojoshmoto 46766 silver badges1919 bronze badges 7

• which user as you logged in ? – user147874 Commented Dec 18, 2018 at 18:25
• As a administrator – joshmoto Commented Dec 18, 2018 at 18:27
• is redirect to the home url or not ? – user147874 Commented Dec 18, 2018 at 18:28
• Yes, it is the wp_redirect that its hitting – joshmoto Commented Dec 18, 2018 at 18:30
• 5 Have you tried checking against edit_posts plural? – WebElaine Commented Dec 18, 2018 at 18:31

 |  Show 2 more comments

1 Answer 1

Sorted by: Reset to default 3

With you current_user_can call everything is just fine. The problem lies elsewhere...

If you'll take a look at Roles and Capabilities, you'll see that there is no capability like edit_post. So your code is working correctly - admin can't edit_post, because there is no such capability (unless it's a custom capability registered by your code elsewhere).

But my gut tells me that you wanted to check if current user can edit_posts ;)

I'm trying to block admin dashboard access using wp_redirect().

But the results of using current_user_can('edit_post') are unexpected.

See my complete function below...

/**
 * user constructor method.
 */
public function __construct()
{

    // block admin dashboard access
    add_action( 'admin_init', array( $this , 'block_admin_access' ) );

}

/**
 * block admin dashboard access to users who cant edit posts
 */
public function block_admin_access () {

    // if users cannot edit posts
    if( ! current_user_can('edit_post') ) {

        // redirect user to home page
        wp_redirect( get_home_url() );

    }

}

When I am logged in as an administrator user, this code above blocks me from the dashboard. Administrators can definately edit posts, so why does this code above redirect me away from the dashboard?

When I am using current_user_can('edit_post') on the front end, the behaviour is normal.

Does anyone know why this could be?

I'm trying to block admin dashboard access using wp_redirect().

But the results of using current_user_can('edit_post') are unexpected.

See my complete function below...

/**
 * user constructor method.
 */
public function __construct()
{

    // block admin dashboard access
    add_action( 'admin_init', array( $this , 'block_admin_access' ) );

}

/**
 * block admin dashboard access to users who cant edit posts
 */
public function block_admin_access () {

    // if users cannot edit posts
    if( ! current_user_can('edit_post') ) {

        // redirect user to home page
        wp_redirect( get_home_url() );

    }

}

When I am logged in as an administrator user, this code above blocks me from the dashboard. Administrators can definately edit posts, so why does this code above redirect me away from the dashboard?

When I am using current_user_can('edit_post') on the front end, the behaviour is normal.

Does anyone know why this could be?

• capabilities

Share Improve this question edited Dec 18, 2018 at 18:27 joshmoto asked Dec 18, 2018 at 18:20 joshmotojoshmoto 46766 silver badges1919 bronze badges 7

• which user as you logged in ? – user147874 Commented Dec 18, 2018 at 18:25
• As a administrator – joshmoto Commented Dec 18, 2018 at 18:27
• is redirect to the home url or not ? – user147874 Commented Dec 18, 2018 at 18:28
• Yes, it is the wp_redirect that its hitting – joshmoto Commented Dec 18, 2018 at 18:30
• 5 Have you tried checking against edit_posts plural? – WebElaine Commented Dec 18, 2018 at 18:31

 |  Show 2 more comments

1 Answer 1

Sorted by: Reset to default 3

With you current_user_can call everything is just fine. The problem lies elsewhere...

If you'll take a look at Roles and Capabilities, you'll see that there is no capability like edit_post. So your code is working correctly - admin can't edit_post, because there is no such capability (unless it's a custom capability registered by your code elsewhere).

But my gut tells me that you wanted to check if current user can edit_posts ;)

本文标签： currentusercan capabilities in the admin not working as expected