В этой серии мы рассмотрели, как WordPress может служить основой для разработки веб-приложений.
Дело в том, что до этого момента мы не рассматривали возможности WordPress, которые действительно способствуют созданию веб-приложений. Вместо этого мы потратили время на изучение того, как WordPress служит основой, а не фреймворком , и мы посмотрели на то, как WordPress организован по сравнению со многими современными доступными фреймворками.
В частности, мы взглянули на шаблон проектирования, управляемый событиями, в отличие от популярного шаблона проектирования модель-представление-контроллер (и его варианты), и на то, как он выглядит в контексте WordPress.
Таким образом, мы работали, чтобы переосмыслить архитектуру приложения и ее структуру в контексте WordPress, чтобы помочь нам получить лучшую концептуальную модель того, как вещи сочетаются друг с другом в WordPress, и как использовать преимущества системы ловушек — то есть действий. и фильтры — и как они влияют на различные точки в течение жизненного цикла страницы WordPress.
Хотя это заслуживает немного большего обсуждения, нам нужно взглянуть на возможности, которые WordPress предлагает из коробки, чтобы полностью понять функции и API, с которыми нам приходится работать, прежде чем на самом деле взглянуть на то, как работать с ними.
В течение следующих нескольких статей мы собираемся сделать именно это.
Компоненты веб-приложения
Когда вы думаете о компонентах веб-приложения, вам может прийти в голову целый ряд вещей. То есть, помимо обычной архитектуры базы данных, промежуточного программного обеспечения и уровня представления, есть также следующие функции:
- Управление пользователями
- права доступа
- Управление сессиями
- Функциональность электронной почты
- Сериализация и поиск данных
- URL-маршрутизация (иногда упоминается как переписывание URL или правила перезаписи или даже просто маршруты)
- Кэширование
- Поддержка пользовательских запросов
Хотя этот список ни в коем случае не является исчерпывающим, он попадает в высокие оценки того, что входит в создание стандартного веб-приложения (конечно, если есть пропущенные пункты, не стесняйтесь упоминать их в комментариях).
И нет — это не предписания. Иногда у веб-приложений не будет управления пользователями, иногда у пользователей не будет ролей, возможно, вам не понадобится кэширование и так далее.
Но дело не в том, чтобы обосновать все, что вам нужно. Вместо этого речь идет об обосновании того, что доступно, если они вам понадобятся.
Итак, с учетом сказанного, давайте посмотрим, что предлагает WordPress для управления пользователями, разрешениями, функциями электронной почты и управления сеансами.
Управление пользователями и разрешения
Любой, кто использовал WordPress — даже если он используется только для ведения блогов или для управления контентом — знаком с базовой системой пользователей. То есть вы создаете имя пользователя, пароль, а затем заполняете свой профиль столько, сколько хотите.
Кроме того, более опытные разработчики знакомы с идеями ролей и возможностей. Я даже рискну сказать, что те, кто использует WordPress, знакомы с системой, даже если они никогда не смотрели на Кодекс и не возились с написанием какого-либо пользовательского кода.
Но общая идея действительно проста: пользователи представляют отдельный профиль для учетной записи в WordPress. Их роль определяется тем, что им было назначено при создании учетной записи.
Эти роли включают в себя:
- подписчик
- участник
- автор
- редактор
- администратор
Опять же, большинство из нас, кто работал с WordPress, знакомы с этими ролями, верно? Но как возможности вписываются в картину?
Проще говоря, возможности — это то, что предоставляет пользователям определенные разрешения в приложении WordPress, а также то, что ограничивает их в определенных областях приложения. Это относительно хорошо задокументировано в Кодексе.
Но вот в чем дело: если вы создаете приложение на WordPress, доступные API-интерфейсы позволяют блокировать пользователей из созданных вами пользовательских областей на основе их ролей и возможностей.
Программное создание пользователя
Во-первых, скажем, что в какой-то момент во время работы над вашим веб-приложением вы хотите предоставить пользователю возможность зарегистрироваться или зарегистрироваться с помощью настраиваемой формы регистрации (в отличие от стандартного метода создания учетной записи пользователя в бэкэнд, как показано выше).
Это можно сделать, создав шаблон с формой, а затем прочитав данные поста.
На самом деле, это может быть так просто, как захватить адрес электронной почты пользователя. Я упоминаю об этом, потому что, хотя имена пользователей приятны и забавны, электронные письма, как правило, уникальны для каждого отдельного человека, что облегчает проверку ошибок.
Таким образом, шаги для этого будут:
- Захватить адрес электронной почты пользователя
- Проверьте, существует ли пользователь с этим адресом электронной почты.
- Если нет, создайте пользователя
- В противном случае не создавайте пользователя и не генерируйте сообщение об ошибке.
Относительно прямо, верно? Конечно, это означает, что вы можете создать пароль для пользователя при создании его учетной записи. К счастью, для этого есть API.
Итак, вот пример, как программно создать пользователя на основе указанного адреса электронной почты (при автоматической генерации пароля).
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
|
if ( null == username_exists( $email_address ) ) {
$password = wp_generate_password( 12, false );
$user_id = wp_create_user( $email_address, $password, $email_address );
wp_update_user(
array(
‘ID’ => $user_id,
‘nickname’ => $email_address
);
);
} else {
// The username already exists, so handle this accordingly…
}
|
После этого вам нужно создать новый экземпляр WP_User .
|
1
|
$user = new WP_User( $user_id );
|
Это то, что позволит нам устанавливать роли для данного пользователя.
Установка роли и возможностей пользователя
Наконец, пришло время определить, какую роль и набор возможностей вы будете назначать пользователю.
С одной стороны, вы можете жестко кодировать эти значения в зависимости от параметров, предлагаемых WordPress. Правда в том, что вы даже можете создавать собственные роли и возможности. Пока это выходит за рамки статьи; однако, мы можем посетить это в будущих сериях.
Итак, допустим, что мы хотим, чтобы всем пользователям, которые в данный момент зарегистрированы, была назначена роль подписчика . Вы можете увидеть, какой набор возможностей им будет предоставлен в этой статье Кодекса .
Установка роли тривиальна:
|
1
|
$user->set_role( ‘contributor’ );
|
На этом этапе вы успешно создали нового пользователя в приложении WordPress программным способом без использования каких-либо административных функций по умолчанию.
Просто подключите это к своему собственному шаблону, проверьте, очистите и проверьте входящие данные $_POST , и вы будете готовы к работе.
Полный код выглядит так:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
|
if ( null == username_exists( $email_address ) ) {
// Generate the password and create the user
$password = wp_generate_password( 12, false );
$user_id = wp_create_user( $email_address, $password, $email_address );
// Set the nickname
wp_update_user(
array(
‘ID’ => $user_id,
‘nickname’ => $email_address
);
);
// Set the role
$user = new WP_User( $user_id );
$user->set_role( ‘contributor’ );
} else {
// The user already exists
} // end if/else
|
Неплохо, правда?
Проверка роли и возможностей пользователя
Но создание пользователя с последующим сохранением его информации в базе данных — только половина, не так ли?
Как только пользователь войдет в систему и пройдет проверку подлинности, вы, вероятно, захотите ограничить контент в зависимости от его роли. Так что возникает вопрос: как только пользователь вошел в систему, как мы можем получить роль пользователя?
К счастью, API WordPress делает это относительно легко:
- Во-первых, мы должны иметь возможность получить идентификатор текущего пользователя.
- После этого мы можем получить роль пользователя и перейти от условной логики оттуда
Нам нужно воспользоваться wp_get_current_user() , а затем нам нужно получить экземпляр объекта WP_User используя идентификатор текущего пользователя, после чего мы можем взглянуть на его возможности.
Посмотрите на код ниже:
|
1
2
3
|
// Get an instance of the current user
$user_id = wp_get_current_user()->ID;
$user = new WP_User( $user_id );
|
Неплохо, правда?
Это действительно облегчает написание условного кода, такого как:
|
1
2
3
4
5
6
7
|
// This will print the user capabilities
print_r( $user->wp_capabilities );
// Which in turn will allow you to perform a check like this:
if ( ‘1’ === $user->wp_capabilities[‘subscriber’] ) {
// We have a subscriber
}
|
Есть альтернативный способ сделать это, хотя:
|
1
2
3
4
5
6
|
global $current_user;
get_currentuserinfo();
if ( 0 === $current_user->user_level ) {
// We have a subscriber
}
|
Но возникает вопрос, откуда взялся этот ноль? Проверьте именно это .
Различия между этими двумя подходами зависят от того, насколько объектно-ориентированным вы хотите, чтобы ваш код был.
Я склонен быть менее фанатом использования global когда доступен объектно-ориентированный подход (такой как в первом примере); тем не менее, второй пример также предлагает относительно простое решение. Твой выбор.
В любом случае, когда вы сможете условно проверить роль учетной записи пользователя, вы можете ограничить их определенными областями приложения.
Но пользователю нужны электронные письма!
Вы правы: по крайней мере, пользователю нужно получать электронные письма, когда их учетные записи были созданы, и они должны иметь возможность получать электронные письма, когда что-то в их учетной записи изменилось.
Опять же, WordPress предоставляет API, который делает это действительно простым, но его можно расширить за пределы простых действий, таких как изменение информации профиля пользователя.
Фактически, учитывая тот факт, что WordPress имеет богатую систему событий, вы можете подключиться к любому количеству событий и отправлять электронные письма, когда что-нибудь случится. Это явно излишне, но это показывает, насколько мощным является API на самом деле.
Итак, в следующем разделе мы рассмотрим почтовый API WordPress и то, как его можно использовать для отправки сообщений об определенных действиях, а также как его можно подключить к другим функциям приложения.