Проверка является ли пользователь администратором по ID

Я лишь дополню ответ @Rarst.

Технически вы можете передавать имя роли в эти функции, так что current_user_can( 'administrator' ) или user_can( $user_id, 'administrator' ) также будут работать, но это не рекомендуется.

Хотя проверка конкретных ролей вместо возможностей частично поддерживается, такая практика не рекомендуется, так как может давать ненадежные результаты.

Примечание: Всегда будет возвращать true, если текущий пользователь является суперадмином, если только это явно не запрещено.

Вы можете проверить роль, не полагаясь на эти функции (поскольку они ненадежны), но, как сказал @Rarst, правильнее проверять возможности, а не роли.

Одно из главных преимуществ использования возможностей вместо ролей заключается в следующем.

Предположим, у вас на сайте несколько администраторов. Допустим, вы хотите, чтобы ваш клиент был администратором, и вы также администратор сайта.

Логично, что ваш клиент имеет административные привилегии над своим сайтом, но вы, возможно, не хотите, чтобы он мог устанавливать плагины на сайте. Это уже ваша задача как веб-мастера.

Так что, если вы проверяете роли, вы ограничены включением/отключением функциональности для всех пользователей с этой ролью.

Если же вы используете возможности, у вас будет больше гибкости в предоставлении/ограничении пользователей для выполнения конкретных действий.

Возвращаясь к моему сценарию, если вы хотите дать вашему клиенту права администратора, но без возможности устанавливать плагины, это будет так же просто, как:

add_filter( 'user_has_cap', 'client_admin_cap_filter', 10, 3 );
function client_admin_cap_filter( $allcaps, $cap, $args ){

  // запрашиваемая возможность и ID нашего клиента
  if ( 'install_plugins' == $args[0] && $args[1] == 2 ) 
    $allcaps[ $cap[0] ] = false;
  
  return $allcaps;
}

Мы могли бы передать массив различных возможностей, которые хотим ограничить, например, update_core, manage_options, install_plugins, install_themes и т.д.

Наша функция все равно останется довольно простой:

add_filter( 'user_has_cap', 'client_admin_cap_filter', 10, 3 );
function client_admin_cap_filter( $allcaps, $cap, $args ){

  $restricted_cap = array( 
    'update_core',
    'manage_options',
    'install_plugins',
    'install_themes',
     // и т.д.
  );

  foreach( $restricted_cap as $r_cap ){

    // запрашиваемая возможность и ID нашего клиента
    if ( $r_cap == $args[0] && $args[1] == 2 ) 
      $allcaps[ $cap[0] ] = false;

  } 
  
  return $allcaps;
}

Как видите, это довольно эффективно, не требует специальной роли, не добавляет дополнительных запросов к БД, выполняется во время выполнения и легко масштабируется и поддерживается.

Если ваша логика зависит от роли, удачи вам в нацеливании на конкретных пользователей, сценарии и прочее без вырывания волос или создания миллиона ролей, чтобы угнаться за всеми возможными случаями использования.

Загляните в кодекс для получения дополнительной информации о фильтре user_has_cap.

Вы можете использовать get_userdata() или get_user_by(), передавая идентификатор пользователя, чтобы получить объект пользователя. Из него можно получить роль.

$user = get_userdata( $user_id );
if(!empty( $user ) && $user){
   $user->roles // здесь содержатся роли, проверьте нужную вам роль
}

Для получения дополнительной информации вы можете посмотреть этот ответ