protected function isAdmin() : bool {
    $check = current_user_can('administrator');
    return $check; 
    // returns false as I am logged in as superadmin, refreshing the page for xdebug to run
  }

$check also evaluates to false when using current_user_can('delete_site');

My wordpress install is hosted on my local machine, Lubuntu 18.04 with apache2. Php 7.2. I can access the site by navigating to http://localhost/folderName in Google Chrome.

I have cookie auth enabled and see my user cookie is present with the EditThisCookie Chrome extension.

In the xdebug console (of Phpstorm 2019.2) I also get a false response:

current_user_can('delete_site');
false

‌‌current_user_can('administrator');
‌false

I have no issues navigating around the front or back end of the wordpress site as an Admin. I feel like this might be an environment issue due to the discrepency betwen the Chrome experience and what the plugin and Xdebug are catching.

Does anyone know why I am running into this issue?

  protected function isAdmin() : bool {
    $check = current_user_can('administrator');
    return $check; 
    // returns false as I am logged in as superadmin, refreshing the page for xdebug to run
  }

$check also evaluates to false when using current_user_can('delete_site');

My wordpress install is hosted on my local machine, Lubuntu 18.04 with apache2. Php 7.2. I can access the site by navigating to http://localhost/folderName in Google Chrome.

I have cookie auth enabled and see my user cookie is present with the EditThisCookie Chrome extension.

In the xdebug console (of Phpstorm 2019.2) I also get a false response:

current_user_can('delete_site');
false

‌‌current_user_can('administrator');
‌false

I have no issues navigating around the front or back end of the wordpress site as an Admin. I feel like this might be an environment issue due to the discrepency betwen the Chrome experience and what the plugin and Xdebug are catching.

Does anyone know why I am running into this issue?

• rest-api
• authentication

• Where are you running this code? If you’re running it too early the current user won’t be set. – Jacob Peattie Commented Sep 2, 2019 at 3:34
• @JacobPeattie It is being run in a rest api request handler callback. The admin user clicks on a delete icon next to a table row which executes the request. the request handler is hooked as an action to rest_api_init – Sean D Commented Sep 2, 2019 at 11:25
• 1 You need to send a nonce with REST requests for the current user to be recognised: developer.wordpress/rest-api/using-the-rest-api/… – Jacob Peattie Commented Sep 2, 2019 at 15:12
• @JacobPeattie the nonce solution turned out to be the right one, thank you – Sean D Commented Sep 2, 2019 at 15:22

1 Answer 1

Normally for checking for administration privileges you have to check the “manage_options” capability, such as:

current_user_can('manage_options')

Alternatively, you want to list the roles with wp_get_current_user()->roles and ensure the “Administrator” role is in that array.

The capabilities you are checking for do not exist in a vanilla install of wp.