Роли и возможности WordPress: основы

Это серия из четырех частей, охватывающая тему пользователей, ролей и возможностей WordPress. Серия будет посвящена архитектуре и дизайну пользовательских ролей в WordPress; выделить наиболее важные функции для взаимодействия с пользователями и управления ролями и возможностями; и в последнем уроке мы собираемся создать реальный пример, демонстрирующий полезность этого API.

Вступление

В этой первой части мы познакомимся с основами и внутренней работой системы пользователей, ролей и возможностей WordPress. Никакие функции или код не будут покрыты в этой части. Таким образом, вы можете перейти к следующему, если вас интересует только написание кода, взаимодействующего с этой системой. Однако я настоятельно рекомендую сначала пройти через это, чтобы получить общее представление о пользователях и ролях в WordPress.

После версии 2.0 WordPress представил новую систему ролей и возможностей, которая заменила старую систему пользовательского уровня. Старая система не будет обсуждаться; теперь он полностью устарел (начиная с версии 3.0) и больше не должен использоваться.

Новая система более продвинутая и гибкая. Теперь можно создавать собственные разрешения и назначать их для каждого пользователя. Это обновление предназначено для устранения недостатков старой модели и позволяет разработчикам создавать более мощные и настраиваемые плагины и темы.

Архитектура базы данных для пользователей

1. Схема пользовательских таблиц

   WordPress хранит данные пользователей в двух таблицах: wp_users и wp_usermeta (в течение всей этой серии я предполагаю, что в вашей настройке WordPress используется префикс wp_ по умолчанию). Вторая таблица создана для расширения первой и позволяет разработчикам прикреплять дополнительные данные каждому пользователю.

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

   Ниже приведена схема схемы двух таблиц. Таблицы связаны между собой отношением «один ко многим». Фактически в wp_usermeta может быть столько строк, сколько вы хотите, с wp_usermeta и тем же user_id (который является внешним ключом для этого отношения и представляет столбец идентификатора в wp_users ).

   

2. Внутри столов

Если мы посмотрим на схему этих двух таблиц, мы можем заключить, что wp_users используется для хранения ограниченного и конечного объема данных о каждом пользователе. Некоторые из них являются обязательными и в основном используются ядром WordPress, темами или плагинами, такими как логин, пароль, электронная почта и хорошее имя (также псевдоним). Но это не относится к полю user_url , например. Это поле может поместиться в таблице wp_usermeta поскольку оно не является обязательным.

Некоторые обязательные поля хранятся в wp_usermeta как псевдоним. Ну, на самом деле я знаю только об этом. Однако некоторая критическая информация, такая как пользовательские возможности, уровень пользователя и режим SSL, также хранится в таблице wp_usermeta . Это делает его не менее важным, чем таблица wp_users (особенно, когда права доступа и безопасность очень важны).

При этом вы должны быть осторожны при работе с обеими таблицами. Я бы порекомендовал вам придерживаться функций WordPress для взаимодействия с системой пользователей и возможностей.

Роли и возможности в WordPress

Как и любая другая CMS, WordPress имеет систему разрешений для пользователей, которая устанавливает и ограничивает привилегии для каждого пользователя. В этом разделе я собираюсь объяснить концепцию ролей и возможностей в WordPress. Так что, если вы боролись с объяснением Кодекса, я надеюсь, что это разъяснит его, так как я подхожу к этой концепции по-другому.

1. Обзор о возможностях

   Забудьте о ролях. Давайте на несколько минут предположим, что они не существуют.

   Давайте представим следующий сценарий: у вас есть блог WordPress, который вы недавно установили, и вы являетесь администратором. (Таким образом, у вас есть все возможные возможности.) Вы решили добавить нового пользователя в свой блог, чтобы добавить некоторые сообщения в блоге. Вы также подумали, что было бы справедливо позволить ему комментировать и настраивать его отображаемое имя.

   Ниже приведена фотография нашего пользователя с возможностями, которые вы ему присвоили.

   

   Так все просто. Вы назначаете возможности для пользователей. Вы можете назвать эти возможности. Например, вы можете назвать «write_new_post» как слаг для написания нового поста.

   В вашем блоге у вас будет список возможностей, каждая из которых дает особые и ограниченные возможности пользователям, которые их имеют. Каждый пользователь может иметь ограниченное количество возможностей. Пользователь, обладающий всеми возможностями, является администратором, поскольку он может делать практически все. Думайте об этом как о системе разрешений, а возможности — это разрешения, которые вы предоставляете пользователям.

   Но почему возможности имеют значение? Ну, именно ты ответственен за это. Например, в случае, если вы создаете свой собственный плагин (или тему), вы можете создать свою собственную access_control_panel « access_control_panel » и назначить ее нескольким пользователям.

   Когда пользователь запрашивает вашу «Панель управления», вы должны убедиться, что пользователь имеет возможность « access_control_panel » перед отображением страницы панели управления. Вы также можете проверить возможность перед запуском определенного фрагмента кода, чтобы убедиться, что у пользователя есть необходимые привилегии.

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

2. Как роли вступают в игру

   Итак, теперь мы знаем, что такое возможности. Давайте представим другой сценарий, где у вас есть группа пользователей. Вы хотите разделить этих пользователей на две группы: мощные пользователи и менее влиятельные пользователи. У каждой группы пользователей будут особые возможности.

   Для этого вам необходимо назначить эти возможности каждому пользователю, что может быть немного неприятно и непродуктивно. Роли созданы именно для этого, они — то, по чем пользователи группируются.

   Таким образом, вместо назначения возможностей пользователям, вы назначаете их ролям; а затем вы назначаете роли пользователям. Впрочем, можно назначать возможности напрямую пользователям. Роль может быть сделана для одного или нескольких пользователей; и один пользователь может не иметь ни одной, ни одной, ни нескольких ролей.

   Так что реальность гораздо больше похожа на это.

   

   Здесь важно отметить, что вы должны проверить возможности пользователя, а не роль пользователя, прежде чем запускать код, требующий разрешения. Никогда не предполагайте, что роль обладает определенной возможностью, потому что это может быть изменено другим плагином или темой.

3. Мета-возможности

   Есть действия, которые требуют нескольких возможностей. Например, чтобы редактировать сообщение в блоге, вам нужна возможность edit_post . Но что, если этот пост был создан другим пользователем? Затем вам также понадобится возможность edit_other_posts . Так что вам нужно проверить оба, прежде чем позволить пользователю редактировать сообщение.

   Вот где в игру вступают мета-возможности. WordPress имеет функцию map_meta_cap() которая возвращает массив требуемых возможностей для выполнения конкретной возможности.

   Итак, вернемся к предыдущему примеру. Предположим, у нас есть пользователь с идентификатором 3, и мы хотим проверить, может ли этот пользователь редактировать сообщение в блоге с идентификатором 5. Это сообщение публикуется другим пользователем с идентификатором 6.

   В этом случае the map_meta_cap() вернет массив со следующими возможностями: edit_post , edit_published_posts и edit_other_posts . Чтобы создать этот массив, map_meta_cap() должна выполнить несколько проверок на основе пользователя и сообщения.

   Возможности по умолчанию, которые проверяет функция: « delete_user », « edit_user », « remove_user », « promote_user », « delete_post », « delete_page », « edit_post », « edit_page », « read_post » или « read_page ». Тем не менее, можно дополнить свой собственный, подключив фильтр ‘ map_meta_cap ‘.

Вывод

В общем, это была система пользователей и разрешений WordPress. Я старался сделать его максимально простым и минималистичным; и я избегал включать любой код по этой причине. В следующей части мы рассмотрим широкий спектр функций, которые WordPress предоставляет для взаимодействия с этой системой.