Концепция ролей и возможностей WordPress может быть запутанной, поэтому давайте потратим несколько минут на то, чтобы расшифровать этот жаргон и понять его смысл. Мы также покажем вам, как реализовать роли и возможности в WordPress плагинах.
Роли — это то, по чему группируются пользователи в WordPress. Это способ присвоить права различным группам пользователей. Важно отметить, что роли не являются иерархическими. Например, администратор не обязательно «выше», чем редактор. Роли определяются лишь тем, что может и чего не может делать эта роль. Это система разрешений (возможностей).
Возможности — это система разрешений. Роли назначаются возможности, которые определяют, что может или не может делать эта роль. Они могут быть настроены по умолчанию WordPress или быть полностью индивидуальными, в зависимости от сайта. Как разработчик плагинов, вы не можете делать слишком много предположений о том, что могут делать те или иные роли.
WordPress поставляется с пятью ролями по умолчанию, которые хорошо подходят для большинства инсталляций. Хотя роли не являются иерархическими, они создают видимость иерархической системы.
Администратор — имеет контроль над всем на сайте
Редактор — имеет право публикации и редактирования всех сообщений
Автор — имеет право публикации и редактирования собственных постов, но не имеет контроля над чужим контентом
Соавтор — Может отправлять сообщения, но не публиковать их
Подписчик — Имеет доступ к редактированию своего профиля пользователя и приборной панели WordPress
Важно отметить, что хотя каждая из этих ролей имеет заранее определенный набор возможностей, их можно легко изменить с помощью кода или плагина, такого как Members. Это означает, что мы никогда не можем утверждать, что какая-либо из этих ролей обладает определенными возможностями, хотя обычно можно предположить, что роль «Администратор» имеет полные права/возможности на сайте.
Таблица Capability vs Role на WordPress.org поможет вам лучше понять, какие возможности назначены ролям в стандартной установке.
Поскольку мы никогда не можем предполагать многого о ролях, гораздо безопаснее проверять возможности при определении того, кто имеет доступ к той или иной области сайта, а кто нет. К этому мы еще вернемся.
Добавление пользовательских ролей
Прежде всего, покопаемся в коде, чтобы узнать, как можно определить пользовательские роли. Они могут быть полезны для некоторых плагинов или пользовательской функциональности для клиента. Например, большинство плагинов для электронной коммерции определяют пользовательские роли, такие как «Продавец магазина» или «Менеджер магазина», и они будут иметь определенные возможности, связанные с функциональностью электронной коммерции на сайте. Аналогичный сценарий возникает и с плагинами для форумов, где есть такие роли, как «Администратор форума» и «Участник форума», и обе они, очевидно, требуют разных возможностей.
Итак, как же нам добавить пользовательскую роль и назначить ей несколько возможностей? Вот код, который вам понадобится:
Итак, мы создали новую роль под названием ‘Advanced contributor’ и наделили ее двумя возможностями, ‘edit_posts’ и ‘read’.
Этот код можно использовать в плагине или в файле functions.php вашей темы, хотя я всегда рекомендую создавать плагин для пользовательской функциональности на сайте клиента. Пока мы здесь, я рекомендую использовать отличный Pluginception для создания пользовательской функциональности в плагине на вашем сайте.
Добавление пользовательских возможностей
Теперь, когда мы научились создавать пользовательские роли, как насчет того, чтобы научиться создавать пользовательские возможности? Опять же, это очень просто:
Если вы хотите добавить возможность конкретному пользователю, а не конкретной роли, используйте следующий код:
При добавлении пользовательской роли или пользовательской возможности информация сохраняется в базе данных (в таблице wp_options, поле wp_user_roles), поэтому, возможно, лучше выполнять эту процедуру при активации темы/плагина.
Проверка возможностей
Мы можем проверить, назначена ли определенному пользователю та или иная возможность, следующим образом. Для получения идентификатора пользователя, по которому вы хотите выполнить проверку, можно использовать плагин Reveal IDs.
Пользовательские типы постов и возможности
При регистрации пользовательского типа поста вы также можете определить возможности, которые будут необходимы для взаимодействия с этим типом поста.
По умолчанию в массиве возможностей принимаются семь ключей:
edit_post,read_postиdelete_post— это мета-возможности, которые затем обычно отображаются на соответствующие примитивные возможности в зависимости от контекста, то есть редактируемого/читаемого/удаляемого поста и проверяемого пользователя или роли. Таким образом, эти возможности обычно не предоставляются напрямую пользователям или ролям.edit_posts— контролирует, можно ли редактировать объекты данного типа сообщения.edit_others_posts— контролирует возможность редактирования объектов этого типа, принадлежащих другим пользователям. Если тип поста не поддерживает автора, то этот параметр будет вести себя какedit_posts.publish_posts— Управляет публикацией объектов этого типа.read_private_posts— контролирует возможность чтения приватных объектов.
Эти четыре примитивные возможности проверяются в ядре в различных местах.
Есть еще семь примитивных возможностей, на которые нет прямых ссылок в ядре, за исключением функции map_meta_cap(), которая берет три вышеупомянутые метавозможности и преобразует их в одну или несколько примитивных возможностей, которые затем должны быть проверены на пользователя или роль, в зависимости от контекста.
read— контролирует, можно ли читать объекты данного типа постов.delete_posts— контролирует, можно ли удалять объекты этого типа.delete_private_posts— контролирует, можно ли удалять приватные объекты.delete_published_posts— контролирует, можно ли удалять опубликованные объекты.delete_others_posts— контролирует, можно ли удалять объекты, принадлежащие другим пользователям. Если тип поста не поддерживает автора, то этот параметр будет вести себя какdelete_posts.edit_private_posts— Управляет возможностью редактирования приватных объектов.edit_published_posts— Управляет возможностью редактирования опубликованных объектов.
Эти дополнительные возможности используются только в map_meta_cap(). Таким образом, они назначаются по умолчанию, только если тип поста зарегистрирован с аргументом 'map_meta_cap', установленным в true (по умолчанию false).
Главное — знать разницу между метавозможностями и примитивными возможностями.
Примитивные возможности — это флаги, которые всегда имеют значение «да» или «нет». Мета-возможности требуют некоторого контекста, например «Является ли пользователь автором этого сообщения?».
Мета-возможности должны быть определены с помощью фильтра map_meta_cap.
Некоторые другие факты:
- Примитивные возможности назначаются ролям пользователей.
- Мета-возможности никогда не должны назначаться роли.
- Примитивные возможности обычно имеют множественное число, а мета-возможности — единственное.
Вот типичный фрагмент кода, в котором мы создаем пользовательский тип поста и настраиваем его возможности:
Аргументы capability_type и capabilities для массива $args в функции register_post_type() позволяют вам управлять пользовательскими возможностями. capability_type дает вам глобальный контроль над возможностями. Аргумент capabilities — это массив, который позволяет управлять отдельными возможностями.
Когда вы регистрируете пользовательский тип поста, вы не регистрируете новые возможности, поэтому плагин для управления ролями, например Members, не распознает их как таковые. Возможности должны быть привязаны к роли/пользователю, чтобы они, так сказать, «существовали».
У вас не будет доступа к вещам с пользовательскими капчами, если вы не назначите эти капчи буквально через экран редактирования роли (плагин Members). Это означает, что их нужно вводить, а не ставить галочки.
Если вы используете post для capability_type, все в порядке с миром, потому что вы просто используете что-то, что уже настроено. Но если вы используете что-то пользовательское… что ж… это пользовательское. Вам придется немного потрудиться.
Мета-возможности (эквивалент edit_post, delete_post и read_post) не отображаются для пользовательского типа возможностей. Их отображение придется делать самостоятельно.
WP Плагины для ролей и возможностей
Members
Бесплатный плагин от Джастина Тадлока. Members — это плагин, который расширяет ваш контроль над блогом. Это плагин для управления пользователями, ролями и контентом, который был создан для того, чтобы сделать WordPress более мощной CMS.
Основой плагина является обширная система управления ролями и возможностями. На ней основаны все текущие и планируемые в будущем функции.
Map Cap
Map Cap идеально подходит, если вы используете пользовательские типы постов и хотите ограничить доступ к ним только определенными ролями.
Другие интересные материалы
Если у вас есть плагин, который отображается на определенных ролях, для которых он не должен отображаться, прочитайте нашу предыдущую статью о том , как удалить пункты меню в админке в зависимости от роли пользователя.
Мы добавили роли и возможности, но как насчет их удаления? Это немного сложно, но ознакомьтесь с этой статьей, которая объясняет, как удалить ненужные пользовательские возможности WordPress.
Если вам понравился этот пост, не забудьте подписаться на RSS-ленту WP Mayor.
Переведено с сайта WP Mayor
Обратная связь
Если у вас возникнут вопросы или потребуется техническая поддержка, не стесняйтесь обращаться. Связаться с нами можно через контактные данные:
- Электронная почта: Пишите нам на info@kowalski.su для подробных запросов или отправки дополнительных материалов. Мы обеспечиваем оперативный ответ и всестороннюю информацию.
- Телефон: Звоните на номер +7 (906) 825 44-41 для немедленной помощи или консультации. Рабочие часы с 7:00 до 15:00 (МСК).
- Telegram: Для быстрой связи используйте наш Telegram-канал @ivan_zh. Идеально подходит для получения оперативных ответов.
Откройте новые возможности с интеграцией WordPress и Bitrix24
Отличных вам сайтов!