WordPress использует механизм Ролей пользователей, суть которого заключается в том, чтобы дать возможность контроля, что другие пользователи сайта могут или не могут делать в админке, например публиковать свои посты, создавать страницы, устанавливать плагины, темы, редактировать других пользователей и так далее.
У каждой роли есть свой набор прав, о которых мы поговорим чуть ниже, к примеру «Администраторы» — это группа пользователей, а switch_themes (возможность смены темы оформления) уже относится к правам этой группы.
И конечно не могу не порекомендовать свой видеокурс по созданию темы WordPress с нуля на основе готовой HTML-вёрстки, который поможет классно прокачать ваши навыки в WP.
В WordPress по умолчанию уже существует 6 групп (ролей) пользователей:
А если у вас стоит плагин для интернет-магазинов WooCommerce, то у вас будет ещё две дополнительные роли, о них я рассказываю в отдельном уроке.
Сразу после установки WordPress автоматически создается пользователь-администратор.
Также вы можете установить, какую роль нужно присваивать только что зарегистрированному пользователю. Это настраивается в «Настройки > Общие».
Изменить роль пользователя можно на странице его профиля или же на странице со всеми пользователями:
Чуть дальше я покажу, как можно удалить эти роли, да и вообще, создать собственные.
Но сначала давайте чуть подробнее остановимся на стандартных ролях пользователей.
Вот так выглядит админка администраторов (рекомендую обратить внимание именно на меню слева).
Если мы не говорим о сети сайтов WordPress Мультисайт, то администраторы могут всё – устанавливать плагины и темы, редактировать весь контент и настройки, создавать и удалять пользователей, сбрасывать пароли и так далее. Полный список их прав в таблице ниже.
Редакторы – это такие ребята, которые не имеют доступ к настройкам и плагинам сайта, зато имеют полный доступ к любому контенту и могут создавать и редакторивать как свои посты, так и чужие. А также модерировать комментарии и редактировать категории и метки.
Авторы могут публиковать и редактировать только свои собственные посты типа «Записи». И удалять кстати тоже. То есть у них уже нет доступа к Страницам. И не могут создавать новые рубрики и метки.
Что-то типо облегчённой версии роли автора. Могут писать и редактировать посты в виде черновиков, но при публикации посты должны пройти одобрение администраторами или редакторами. Кроме того, не могут изменить свои же, уже опубликованные посты и загружать медиафайлы.
Ну и последняя стандартная роль WordPress – подписчик, который не может ровным счётом ничего 😁 Ну окей, они могут изменять информацию в своём профиле и читать посты, на этом всё.
Вы наверное подумали: «Так, а где роль суперадмина?» Почему я не рассказал про неё в самом начале? А это даже и не совсем роль – это роль администратора с возможностью управления сетью WordPress Мультисайт.
У него появляется доступ в отдельную консоль для мультисайта.
Для того, чтобы вам было удобнее ориентироваться в огромном количестве прав пользователей, сделал для вас таблицу. Не забывайте кликать на ссылку-название определённого права, чтобы почитать про него подробнее, так как для некоторых прав существуют различные условия, когда они работают по-другому.
Также напоминаю про свой видеокурс по натяжке готовой вёрстки на WordPress.
Сейчас пришло время рассказать вам о важном моменте, связанном с правами пользователя. Я также упоминал о нём, когда описывал функцию register_post_type().
Чтобы понять, как это работает, лучше всего обратиться к примеру.
Предположим, что у нас есть какое-то право, допустим это edit_posts. И мы например можем проверить функцией current_user_can(), может ли текущий пользователь в принципе редактировать посты или нет. Это примитивное право, под него попадают все возможные посты. Это можно проверить:
if( current_user_can( 'edit_posts' ) ) { }
Но как вы знаете, у нас есть например роль Авторы, которые могут редактировать только свои посты. Как проверить, что они это могут делать? При помощи мета-права!
if( current_user_can( 'edit_post', $post->ID ) ) { }
Мета-права создаются «на лету» динамически, например алгоритм такой, что WordPress чекает, может ли пользователь редактировать чужие посты примитивным правом edit_others_posts
, если нет, то он проверяет, является ли пользователь автором проверяемого поста $post->ID
. И вот так это и работает.
<script>
) в контенте записей, страниц, комментариев и виджетов.unfiltered_html
.А вообще кстати мы можем изменять список разрешённых HTML-тегов в постах и комментариях.
С версии 2.3.
Право unfiltered_upload
очень похоже на unfiltered_html. Если у пользователя присутствует это право, он(а) сможет загружать файлы, которые НЕ находятся в белом списке WordPress:
В итоге, если у пользователя нет данного разрешения, то попытки загрузить любые файлы, который не находятся в этом списке, приведут к ошибке «Извините, этот тип файла недопустим по соображениям безопасности»:
По умолчанию этого права нет ни у кого, но его можно включить, добавив в wp-config.php
следующую строчку:
define( 'ALLOW_UNFILTERED_UPLOADS', true );
На обычной установке WordPress это право можно добавить для кого угодно, а на мультисайт-установке – только для супер-админов.
Для того, чтобы в коде проверить, имеет ли пользователь сайта определённую роль или же только определённое право, мы можем воспользоваться одной из двух функций:
Проверим, что текущий пользователь администратор:
if( current_user_can( 'administrator' ) ) { // выполняем какие-либо действия }
Или:
if( user_can( get_current_user_id(), 'administrator' ) ) { // выполняем какие-либо действия }
Таким же образом вместо названия роли пользователя мы можем передать и название определённого права. Например проверим, что пользователь может переключать темы:
if( current_user_can( 'switch_themes' ) ) { // выполняем какие-либо действия }
И ещё кое-что, так как супер-администратор не является полноценной ролью, то его лучше проверять по-другому, функцией is_super_admin() или правом setup_network.
if( is_super_admin() ) { // или if( current_user_can( 'setup_network' ) ) { // в параметры также можем передать ID определённого пользователя }
Функция заносит данные в базу, поэтому лучше всего её использовать только один раз, например при активации плагина или темы.
/* * допустим я добавлю этот код в файл плагина и сделаю так, чтобы он запускался при активации этого самого плагина */ register_activation_hook( __FILE__, 'true_new_role_plugin_activate' ); function true_new_role_plugin_activate() { $new_role = add_role( 'comm_moderator', // название роли __( 'Comment Moderator' ), // отображаемое название роли (модератор комментариев) array( // массив возможностей, true - разрешено, false - запрещено 'read' => true, // ну это понятно 'moderate_comments'=> true // разрешим модерировать комментарии ) ); if ( null !== $result ) { // смотрим результат // роль успешно создана } else { // если null, то значит роль уже существует } }
Также, как и add_role()
, функция изменяет содержимое базы данных — а значит не нужно просто тупо вставлять её в functions.php
.
В примере удалим роль, созданную в прошлой главе:
remove_role('comm_moderator'); // в качестве параметра указываем название роли и всё, дело сделано
В случае успеха возвращает объект WP_Role (который состоит преимущественно из возможностей роли), в случае неудачи — null.
$my_role = get_role( 'comm_moderator' ); // указываем роль, которая нам нужна print_r( $my_role ); // так можно вывести содержимое объекта
Благодаря этим функциям вы можете добавить или удалить права для пользователей определенной роли или даже для пользователей с определенными ID.
Эти функции также изменяют содержимое базы данных, поэтому в качестве примера мы повесим их на активацию / деактивацию темы.
function true_author_caps(){ global $pagenow; $role = get_role( 'author' ); // к примеру возьмем роль автора // $role = new WP_User( $user_id ); таким образом мы можем взять конкретного пользователя if ( 'themes.php' == $pagenow && isset( $_GET['activated'] ) ){ // если тема была активирована $role->add_cap( 'edit_others_posts' ); // разрешаем авторам редактировать посты других авторов } else { // если тема деактивирована $role->remove_cap( 'edit_others_posts' ); } } add_action( 'load-themes.php', 'true_author_caps' ); // вешаем функцию на хук
Чтобы оставить комментарий, пожалуйста, зарегистрируйтесь или войдите.
Здравствуйте, как определенному пользователю дать возможность публиковать посты только в определенную рубрику?
Здравствуйте!
А каким образом вы хотите это реализовать? Сделать другие рубрики в админки недоступными для выбора или как-то ещё?
Совершенно верно, чтобы пользователи могли публиковать посты только в одну рубрику, остальные не выводились ему в админке.
Наверное лучше скрыть через CSS при помощи хука
admin_head
и функцииcurrent_user_can()
.Спасибо, реализовал лучше вариант с хуком
get_terms
Приветствую, Михаил! Немного не в кассу, но спрошу.
Можно ли задать возможности определенной роли чтобы этим пользователям можно было только добавлять и редактировать одну конкретную кастомную запись?
Приветствую!
Да, конечно. Можно условие повесить внутри хука
save_post
, но думаю, что есть и более «чистое» решение.Хм, ладно, подумаю... Спасибо
Добрый день! Я уже всю голову сломал и весь гугл перешерстил, решения не нашел.
Мне нужно, чтобы при выборе определенной таксономии пользователю присваивалась вторая роль, помимо существующей.
То есть у меня есть таксономия "язык". Надо, чтоб когда пользователь выбирал "русский", ему добавлялась вторая роль "freelancer_ru" помимо уже присвоенной ему роли "freelancer".
Вот код, отвечающий за выбор таксономии:
Куда-то туда мне надо вставить правило типа
но я не знаю, как это правильно сделать.
Добрый день!
Это можно сделать так:
Спасибо, вы меня спасаете! И тупой вопрос: этот код вставляется в function.php или как-то еще?
А он вставляется там, где что-то происходит после того, как пользователь выбирает таксономию
Миша привет! Подскажи пожалуйста. Можно ли как то ролям подписчик, запретить редактировать Имя и Фамилию? Так же имеется плагин WPForo и HivePress там свой профиль с такими же полями.
Вот и вопрос если на уровне ролей запретить , подцепит ли это правило другие плагины? Спасибо.
Привет!
Думаю, что конечно можно, но готового кода у меня к сожалению нет
Длинный и сложный вопрос. На сайте реализованы профили пользователей через Profile Builder.
Есть потребность в том, чтобы пользователь с ролью "Брокер" мог залогиниться в админку сайта.
Сейчас (при роли "Подписчик") пользователь при логине "в админку" попадает в "профиль на фротненде".
Путём перебора было найдено, что "в админку WP" могут логиниться пользователи с ролью "Редактор" и выше.
При этом. если клонировать роль "Редактор" и сделать её "Брокер"-ом, то пользователь в админку сайта уже не может логиниться.
Если же клонировать роль "Администратор", то пользователь с таким клоном может залогиниться в админку.
Вопрос: куда хоть копать, чтобы понять, как мне дать минимальные права нужной роли для логина в админку сайта?