Користувачі в WordPress

Базова інформація, яку потрібно знати про користувачів WordPress.

Таблиця wp_users

ID
(число)

ID користувача. Вказується лише, якщо потрібно оновити дані існуючого користувача. Усі обов’язкові параметри стають не обов’язковими.

user_login
(рядок) (обов’язковий)

Логін нового користувача. Для додаткової перевірки логіну перед створенням/оновленням можна використовувати фільтр:
pre_user_login .

user_pass
(рядок) (обов’язковий)

Пароль для користувача. Хешується.

user_nicename
(рядок)

Ім’я користувача. Якщо не вказати, буде як логін. Містить очищений для використання URL логін – очищається через
sanitize_title() . Наприклад, якщо при реєстрації вказати в полі логіну email
[email protected] , то тут отримаємо
userexample-com . Використовується на архівну сторінку автора, тому значення поля має бути унікальним кожному за користувача.

user_email
(рядок)

Пошта. Перевіряється на існування у БД.

user_url
(рядок)

Сайт. Фільтр:
pre_user_url .

user_registered
(DATETIME)

Дата реєстрації. Ymd H:i:s. Якщо не вказано при створенні користувача, поточна дата в діапазоні GMT береться.

user_activation_key

Хеш ключа для відновлення пароля створюється при запиті відновлення. get_password_reset_key
() .

user_status
(не використовується)

Це поле більше не використовується ядром WordPress, яке раніше використовувалося в мультисайтах при переміщенні користувача в спам (цей функціонал був вилучений). Докладніше див. функцію: update_user_status() .

Колонку можна використовувати якось у своїх цілях, але краще дати їй спокій.

display_name
(рядок)

Відображене ім’я. Якщо порожньо буде як логін.

Таблиця wp_usermeta

Важливі мета-дані (мета-поля)

wp_capabilities
(масив)

Роль і права користувача: a:1:{s:13:"administrator";b:1;}.

ВАЖЛИВО! Префікс цієї опції wp_повинен збігатися з префіксом таблиць БД $wpdb->prefixабо $wpdb->get_blog_prefix()мультисайту.

Так, наприклад, якщо на робочому сайті змінити префікс таблиць в wp-config.php, то в цій опції вручну також потрібно змінити префікс, інакше всі користувачі залишаться без прав, тому що після зміни префікса, наприклад, на wk_ВП шукатиме права в метаполі wk_capabilities.

session_tokens

Активні сесії. Створюються при вході до облікового запису.

Які ще дані зберігаються в таблиці метаданих

nickname
(рядок)

Нік. Якщо пусто, буде як логін.

first_name
(рядок)

Ім’я.

last_name
(рядок)

Прізвище.

description
(рядок)

Трохи про себе.

rich_editing
(рядок/bool)

Включити (true) чи ні (false) візуальний редактор. user_can_richedit
()


За замовчуванням – ‘true’

syntax_highlighting
(рядок/bool)

Увімкнути підсвічування синтаксису для візуального редактора.

comment_shortcuts
(рядок/bool)

Чи включити для користувача комбінації клавіш модерації коментарів. Підключати чи ні скрипт
enqueue_comment_hotkeys_js. enqueue_comment_hotkeys_js
() .


Типово – ‘false’

use_ssl
(рядок/bool)

Чи повинен користувач завжди логінуватися по https.


Типово – ‘false’

show_admin_bar_front
(рядок)

Показувати адмін бар на сайті чи ні.


Типово ‘true’

role
(рядок)

Роль користувача.


За замовчуванням береться з налаштувань: get_option(‘default_role’)

locale
(рядок)

Мова користувача (локаль). Наприклад: ru_RU. З WP 4.7.


За замовчуванням ”

default_password_nag
(true/false)

true – означає, що встановлено пароль за замовчуванням.

Також у метаполях зберігаються Опції Адмін-панелі – це налаштування сторінок адмінки та інше. Наприклад: збережені вибори метабоксів на різних сторінках.

Ролі та права користувачів

За промовчанням у WordPress 6 ролей:

Яку роль отримує новий користувач вказується у Настройки > Общие. Дані зберігаються в опції: default_role :

Список прав за ролями

Список примітивних (фундаментальних) прав користувача. Це можливості, які за замовчуванням є у зазначених ролей (користувачів). Цей список прав задається один раз, при встановленні WordPress – він зберігається в таблицю БД wp_optionsв опцію wp_user_roles.

• ¹коли один сайт (не мультисайт).
• ²коли один сайт (не мультисайт). Або вмикається у налаштуваннях мережі.
• ³– Це право потрібно включати окремо, докладніше нижче .

Мета права

Вище перераховано перелік примітивних (фундаментальних) прав. Але ще є так звані мета-права. Вони ніде не зберігаються, а обчислюються «нальоту» й у результаті перетворюються на примітивне право.

Список мета-прав:

activate_plugin
activate_plugins
add_comment_meta
add_post_meta
add_term_meta
add_user_meta
add_users
assign_categories
assign_post_tags
assign_term
create_app_password
create_sites
create_users
customize
deactivate_plugin
deactivate_plugins
delete_app_password
delete_app_passwords
delete_categories
delete_comment_meta
delete_page
delete_page
delete_plugins
delete_post
delete_post
delete_post_meta
delete_post_tags
delete_site
delete_sites
delete_term
delete_term_meta
delete_themes
delete_user
delete_user
delete_user_meta
delete_users
edit_app_password
edit_categories
edit_comment
edit_comment
edit_comment_meta
edit_css
edit_files
edit_page
edit_page
edit_plugins
edit_post
edit_post
edit_post_meta
edit_post_tags
edit_term
edit_term_meta
edit_themes
edit_user
edit_user
edit_user_meta
edit_users
erase_others_personal_data
export_others_personal_data
install_languages
install_plugins
install_themes
list_app_passwords
manage_links
manage_network
manage_network_options
manage_network_plugins
manage_network_themes
manage_network_users
manage_post_tags
manage_privacy_options
manage_sites
promote_user
promote_user
publish_post
read_app_password
read_page
read_page
read_post
read_post
remove_user
remove_user
resume_plugin
resume_theme
setup_network
unfiltered_html
unfiltered_upload
update_core
update_https
update_languages
update_php
update_plugins
update_themes
upgrade_network
upload_plugins
upload_themes

edit_term - WP 4.7 - Не перевірять хто створив термін - тільки перевіряє наявність зазначеного терміну та таксономії.
delete_term - WP 4.7 -
assign_term - WP 4.7 -
activate_plugin - WP 4.9 - current_user_can( 'activate_plugin', 'my-plugin/my-plugin.php' )
deactivate_plugin - WP 4.9 - current_user_can( 'deactivate_plugin', 'my-plugin/my-plugin.php' )

export_others_personal_data - WP 4.9.6 - is_multisite() ? 'manage_network' : 'manage_options'
erase_others_personal_data - WP 4.9.6 - is_multisite() ? 'manage_network' : 'manage_options'
manage_privacy_options - WP 4.9.6 - is_multisite() ? 'manage_network' : 'manage_options'

update_php - WP 5.0 - is_multisite() ? is_super_admin() : update_core
update_https - WP 5.7 - is_multisite() ? is_super_admin() : manage_options | update_core

create_app_password - WP 5.7 - map_meta_cap( 'edit_user', $user_id )
list_app_passwords - WP 5.7 - map_meta_cap( 'edit_user', $user_id )
read_app_password - WP 5.7 - map_meta_cap( 'edit_user', $user_id )
edit_app_password - WP 5.7 - map_meta_cap( 'edit_user', $user_id )
delete_app_passwords - WP 5.7 - map_meta_cap( 'edit_user', $user_id )
delete_app_password - WP 5.7 - map_meta_cap( 'edit_user', $user_id )

Для перевірки таких прав потрібно передавати додаткові параметри, наприклад ID запису, для якої потрібно перевірити, чи може користувач її редагувати. Наприклад:

if( current_user_can( 'edit_post', 123 ) ){
	 echo 'Поточний користувач може редагувати пост 123';
}

У цьому випадку WP нальоту перевіряє чи є користувач автором цієї посади, чи має примітивне право редагувати всі пости. У результаті, якщо перевірку пройдено, це мета право перетворюється на аналогічне примітивне право, яке дозволяє виконувати дію.

Докладніше про мета права читайте в описі map_meta_cap() .

unfiltered_upload

За замовчуванням можливість unfiltered_upload є у адміністратора . Проте це за замовчуванням заблоковано, тобто. ролі не пройдуть перевірку if( current_user_can('unfiltered_upload') ), незважаючи на наявність у них такого права.

Щоб право unfiltered_upload почало працювати як очікується, потрібно у файлі wp-config.php “включити” константу:

define( 'ALLOW_UNFILTERED_UPLOADS', true );

З визначенням цієї константи ролі, що мають право unfiltered_upload, зможуть завантажувати файли з будь-яким розширенням (без перевірки типу файлу).

Для мультисайту складання право unfiltered_uploadє тільки у Супер Адміністратора. Якщо інша роль має право unfiltered_upload, воно просто ігноруватися. Докладніше дивіться перевірку мета-права в map_meta_cap() :

case 'unfiltered_upload':
	if ( defined( 'ALLOW_UNFILTERED_UPLOADS' ) && ALLOW_UNFILTERED_UPLOADS && ( ! is_multisite() || is_super_admin( $user_id ) ) ) {
		$caps[] = $cap;
	} else {
		$caps[] = 'do_not_allow';
	}
	break;

PHP Функції

Весь список функцій дивіться тут . А ось деякі з функцій:

Процес встановлення поточного користувача

Для встановлення поточного користувача в ядрі на хук determine_current_user повішені такі функції. Кожна з них встановлює поточного користувача різних видів запиту (фронт, REST запит).

add_filter( 'determine_current_user', 'wp_validate_auth_cookie');
add_filter( 'determine_current_user', 'wp_validate_logged_in_cookie', 20);
add_filter( 'determine_current_user', 'wp_validate_application_password', 20);

Хук _wp_get_current_user() .

_wp_get_current_user() встановлює поточного користувача в глобальну змінну $current_userпри першому дзвінку та при наступних дзвінках бере дані від туди.

Рано коли може бути викликана функція wp_get_current_user() – це подія plugins_loaded (бажано з великим пріоритетом, щоб відпрацювала в кінці), тобто. після підключення всіх плагінів та базової їх ініціалізації.