Сегодня мы рассмотрим права пользователей в рамках вашего плагина. В частности, я расскажу, что вы должны использовать, чтобы определить, кто может видеть различные меню администратора вашего плагина.
Решение грязной проблемы
Я наткнулся на сложность пользовательских разрешений при работе над многопользовательской установкой WordPress. Мы размещали около 15-20 веб-сайтов и установили около 30 плагинов. Каждый из блогов имел пользователей разных уровней и обязанностей. Мои работодатели получали запросы или находили плагины с функциональностью, которую они хотели предложить, и я должен был установить и настроить их. Вот когда я столкнулся с проблемами. Часто я модифицировал плагины, чтобы просто приспосабливать роли пользователей, которые мы использовали. Беспорядок в основном объяснялся тем, что WordPress позволяет вам определять, кто может просматривать и использовать ваш плагин.
Когда-то давно WordPress включал «Уровни пользователей». Всего было 10 уровней, каждый из которых предоставлял пользователю больше привилегий, чем предыдущий. Очень часто разработчик нацеливается на определенный уровень пользователя, например:
1
2
3
4
5
6
7
8
9
|
<?php
if (current_user_can(‘level_10’)){
/*do something*/
}
//Or Define a Page
add_menu_page(‘Page Title’, ‘Menu Title’, 10,’unique-slug’,’menu_function’);
?>
|
Для тех из вас, кто не знаком с функциями WordPress, функция add_menu_page определяется как:
1
|
add_menu_page( $page_title, $menu_title, $capability, $menu_slug, $function, $icon_url, $position );
|
Этот конкретный набор кода нацелен на уровень пользователя 10, который будет самым высоким набором разрешений. Несмотря на полезность в некоторых обстоятельствах, пользовательские уровни не давали такой гибкости, как мне хотелось. К счастью, когда вышел WordPress 2.0, нам дали «Роли и возможности». Возможности заменили пользовательские уровни, а в WordPress 3.0 пользовательские уровни стали устаревшими.
Благодаря новому способу определения пользовательских разрешений мы получили дополнительные способы нацеливания на пользователей. Первый — по ролям. Используя те же функции, что и выше, я проиллюстрирую ориентацию пользователей на роли.
1
2
3
4
5
6
7
8
9
|
<?php
if (current_user_can(‘Administrator’)){
/*do something*/
}
//Or Define a Page
add_menu_page(‘Page Title’, ‘Menu Title’, ‘Administrator’,’unique-slug’,’menu_function’);
?>
|
По сути, это не слишком отличается от использования пользовательских уровней, и в моей ситуации это было не очень хорошо. С нашей многосайтовой установкой роли Администратора использовались только людьми в доме. Самая высокая роль, которую могли получить клиенты, были редакторами. Но они все еще должны были иметь возможность делать определенные вещи на своем сайте. И, к сожалению, многие плагины, с которыми я сталкивался, по-прежнему использовали либо пользовательские уровни, либо сами роли для предоставления или отказа в использовании своего плагина. Тем не менее, WordPress предоставил гораздо более надежное решение этой проблемы с точки зрения их возможностей.
Возможности позволяют вам ориентироваться на пользователя, основываясь на том, что он может делать, а не на той роли, которую он выполняет. Рассмотрим пример ниже.
1
2
3
4
5
6
7
8
9
|
<?php
if (current_user_can(‘upload_files’)){
/*do something*/
}
//Or Define a Page
add_menu_page(‘Page Title’, ‘Menu Title’, ‘upload_files’,’unique-slug’,’menu_function’);
?>
|
Функции теперь проверяют, может ли пользователь загружать файлы. Если возможности не были изменены, это позволяет отображать меню и запускать код для супер администраторов, администраторов, редакторов и авторов. Это гораздо лучшее решение, так как отдельные функции могут быть добавлены или удалены из ролей в функциях темы.
Сейчас, хотя это лучшее решение для многих обстоятельств, я хотел бы сделать еще один шаг вперед. Когда я разрабатываю плагин для неадминистративных функций, таких как плагин для галереи или рекомендаций, я предпочитаю предоставлять пользователю доступ на основе пользовательских возможностей, созданных для этого плагина. Я привел пример того, как сделать это ниже.
1
2
3
4
5
6
7
|
<?php
//add_cap($role,$cap,$grant);
add_cap(«editor», «my_plugin_cap», true);
add_menu_page(‘Page Title’, ‘Menu Title’, ‘my_plugin_cap’,’unique-slug’,’menu_function’);
?>
|
Как видите, мы добавляем возможность под названием «my_plugin_cap» в роль редактора. Затем мы добавляем страницу меню, которая видна всем пользователям с этой возможностью. Что приятно, так это то, что в плагине вы можете добавить возможность соответствующим пользователям, и если администратор хочет предоставить доступ другим ролям, он может сделать это, добавив возможность самостоятельно через функции темы. В моем случае это означает, что мне больше не нужно редактировать сами плагины, и я могу свободно обновлять их, не беспокоясь о потере внесенных изменений.
Я надеюсь, что этот совет был полезен для вас. Дайте мне знать, если у вас есть какие-либо вопросы или проблемы в комментариях ниже. Счастливого программирования плагинов!