Роль, которая может отредактировать только виджеты, не другие опции темы

Как я мог сделать конкретное ролевое меню администрирования виджетов доступа (wp-admin/widgets.php), но не получить доступ к другим элементам меню администрирования темы.

У меня есть это далеко для отображения меню Appearance, связывающегося с widgets.php путем привязки с _admin_menu событием и изменения $submenu глобальной переменной. Хотя это ясно не работает, поскольку я вижу этот код в самом wp-admin/widgets.php:

    if ( ! current_user_can('edit_theme_options') )
            wp_die( __( 'Cheatin’ uh?' ));

Это ясно - Вам нельзя разрешить получить доступ к этой странице, если у Вас ясно не будет edit_theme_options возможности. Но что сделать, если я не хочу другие элементы этой возможности, независимо виджетов, модифицируемых текущим пользователем (роль)?

Легко "скрыть" другие опции от меню. Но это оставляет пользователя, который знает, как WP работает (понимает обращение, по крайней мере), свободный получить доступ к ним и что я ясно хотел бы избежать.

Спасибо за любую справку заранее.

3
06.08.2012, 17:15
3 ответа

Подтверждение …

Да, в настоящее время нет (WP 3.4.1) никакого способа изменить аргументы доступа в пользу страниц меню администратора. Единственный, что можно изменить через общественность wp API, является» Комментариями «пункт меню. Все другие регистрируются вручную.

Но существует справка, прибывающая из @scribu (читайте больше в trac билете), кто до сих пор приложил много усилий принести что-то более полезное для ядра.

Объяснение

Когда глубже изучат ядро, затем Вы будете видеть функцию wp_widgets_add_menu() внутри ~/wp-includes/functions.php. Этот в основном добавляет элемент подменю начиная с WP 2.2 …

function wp_widgets_add_menu() {
    global $submenu;
    $submenu['themes.php'][7] = array( __( 'Widgets' ), 'edit_theme_options', 'widgets.php' );
    ksort( $submenu['themes.php'], SORT_NUMERIC );
}

Эта функция добавляется к _admin_menu действие wp_maybe_load_widgets() функция.

Промежуточная работа вокруг для пункта меню и страницы виджетов

В настоящее время функция, которая загружает виджеты по умолчанию и регистрирует объект подменю (а именно, wp_maybe_load_widgets) назван во время plugins_loaded рычаг с приоритетом 0.

Это делает жестким вычеркнуть из списка его с нормальным плагином. Поэтому необходимо использовать плагин в Вашем mu-plugins папка.

<?php
/* Plugin Name: »Kaisers« Deny Widgets page access */
! defined( 'ABSPATH' ) AND exit;

// Init the plugin
add_action( 'muplugins_loaded', array( 'wpse6106_deny_widgets', 'init' ), 0 );

class wpse6106_deny_widgets
{
    static public $instance;

    public $required_cap = 'SET_CUSTOM_CAP_HERE';

    /**
     * Get the instance of the plugin
     * @since  2012-08-07.1505
     * @return void
     */
    static function init()
    {
        null === self :: $instance AND self :: $instance = new self;
        return self :: $instance;
    }

    /**
     * Setup
     * Removes the default function that registers the widgets.php sub menu item.
     * @since  2012-08-07.1505
     * @return void
     */
    function __construct()
    {
        // remove core function...
        remove_action( 'plugins_loaded', 'wp_maybe_load_widgets', 0 );

        // ...and add our own
        add_action( 'admin_head', array( $this, 'widgets_menu_access' ), 0 );

        // Then abort any attempt to access the widgets page
        add_action( 'load-widgets.php', array( $this, 'widgets_page_access' ), 0 );
    }

    /**
     * Adds an action, that re-registers the sub menu item with a custom capability.
     * @since  2012-08-07.1505
     * @return void
     */
    function widgets_menu_access()
    {
        global $submenu;

        // Call default widgets file
        require_once( ABSPATH . WPINC . '/default-widgets.php' );

        $submenu['themes.php'][7] = array( 
             __( 'Widgets' )
            ,$this->required_cap
            ,'widgets.php'
        );
        ksort( $submenu['themes.php'], SORT_NUMERIC );
    }

    /**
     * Does a second check if someone without the custom cap entered the widgets page and dies.
     * @since  2012-08-07.1505
     * @return void
     */
    function widgets_page_access()
    {
        get_currentuserinfo();
        global $current_user;

        if ( ! current_user_can( $this->required_cap ) )
            wp_die( __( 'Cheatin&#8217; uh?' ) );
    }
}

Просто бросьте это в свою папку MU-Plugins, корректируйтесь SET_CUSTOM_CAP_HERE представьте в виде строки в плагине (переменная класса на вершине ↑), и Вы готовы пойти. Удостоверьтесь, что Вы используете некоторого менеджера по роли (как участники, который позволяет Вам давать эту роль только тем, кто предназначен для доступа к странице виджетов. Или добавьте его вручную с некоторым собственным/пользовательским плагином.

Также удостоверьтесь, что пользователи не имеют некоторых в запасе по материалу возможности. Если это не работает, деактивируйте все плагины, переключатель назад к TwentyTen/Eleven и сделайте сброс своей локальной базы данных с плагином как» Сброс WordPress «.

Доказанный результат

enter image description here

Примечание: Плагин тестируется и работает в простой ванильной установке.


Отключите виджеты по умолчанию и элементы подменю

Примечание: Это только для более поздних читателей, которые хотят избавиться от всего этого.

Если Вы хотите полностью избавиться от всех виджетов по умолчанию, то существует простой фильтр, который можно назвать, который останавливается включая ~/wp-includes/default-widgets.php файл и отключает регистрацию страницы:

add_filter( 'load_default_widgets', '__return_false' );
3
19.02.2020, 22:17
  • 1
    за длинный комментарий (не видели, что trac выходят), но это не работает из-за причины, которую я объяснил: в [этом] [core.svn.wordpress.org/trunk/wp-admin/widgets.php] регистрируют существует проверка if ( ! current_user_can('edit_theme_options') ), таким образом любые другие сбои разрешения. Но да, это работает в пунктах меню, тем не менее. –  Justas Butkus 07.08.2012, 09:24
  • 2
    @JustasButkus Без проблем. В теории было бы достаточно изменить разрешение пользовательского ограничения (Вы попробовали его, или Вы просто предполагаете, что это не работает? Мой тест показал его работающий...). Но так или иначе, я даю Вам другое обновление с полным плагином, который делает вторую проверку в widgets.php странице и аварийных прекращениях работы. Голосование ценится. –  kaiser 07.08.2012, 16:13
  • 3
    за справку, хотя протестировали Вас на самом деле, того данного пользователя, у которого нет edit_theme_options разрешения, могло все еще получить доступ к конфигурации виджетов (wp-admin/widgets.php)? Поскольку я протестировал его (wp_get_current_user()->remove_cap('edit_theme_options')) и, учитывая код выше - я не мог получить доступ к конфигурации виджетов, поскольку я добираюсь, вышеупомянутая ошибка (стоит по причине). –  Justas Butkus 07.08.2012, 17:27
  • 4
    @JustasButkus Да, я протестировал его - еще я не буду говорить так. Для меня это достаточно только к функции, ограничивающей меню. Это предлагает мне с тем, что Вы видите в снимке экрана. Если я удаляю функцию меню администратора из MU-плагина, я добираюсь "Cheatin' uh?"- сообщение. Если я удаляю возможность, ничто не изменяется. Деактивируйте все свои плагины, переключатель назад к теме TwentyEleven по умолчанию и попробуйте еще раз. Это - проблема с Вашей установкой (или некоторые левые верхние мячи в Таблице метаданных Разработки DB/userWordPress) а не с моим плагином. Я также добавил эту информацию как редактирование и связал плагин, который поможет u. –  kaiser 07.08.2012, 17:39
  • 5
    , возможно, мы обсуждаем различные моменты. Я не говорю о ДОБАВЛЕНИИ новой возможности, без которой пользователи не могли бы видеть запись меню. Создайте нового пользователя с полномочиями Подписчика. Затем проверьте, может ли он получить доступ к wp-widgets.php (он не должен). Затем используйте свой плагин, чтобы предоставить ему SET_CUSTOM_CAP_HERE и проверку снова - если можно получить доступ к wp-widgets.php. Удостоверьтесь, тому пользователю не предоставили edit_theme_options возможность. Для меня, учитывая чистый (я на самом деле загрузил новый WP и установил в чистом DB), установка - пользователь не получает доступ. –  Justas Butkus 09.08.2012, 13:50

Я нашел частичный путь вокруг этого.

Обязательные действия

Я добавляю последний (priority=10) метод к user_has_cap действие. В связанном методе я проверяю на страницу, к которой получают доступ (удостоверьтесь, что это - wp-admin/widgets.php), и если это имеет место, и проверяемое разрешение является edit_theme_options - я даю то разрешение return $all_caps + array('edit_theme_options' => true);.

Дополнительно я связал очень последний (priority=999) метод с admin_menu действием. Тот метод, учитывая, что у текущего пользователя есть моя собственная определенная возможность получить доступ только к меню виджетов (не имеет смысла - мог быть user_can_customize_themes_widgets_only), я выполняю итерации по глобальному разделу массива $submenu, связанному с появлением ($submenu ['themes.php']), и удаляю любые элементы, которые не имеют 'widgets.php' как элемента пути (индекс для пути равняется 2). И наконец я повторно добавляю widgets.php к нему, в случае, если это получило пропавших без вести.

Вещи рассмотреть

Почему я говорю, что это неравнодушно?

Поскольку это - обходное решение. Я предоставляю пользователю edit_theme_options право, даже если в течение короткого срока и после того, как удостоверяющийся пользователь получает доступ к widgets.php и не какой-либо другой странице.

И также - я не могу полагаться на это для работы с будущими версиями WP, поскольку я изменяю $submenu глобальной переменной, который мог измениться всегда в любое время.

Учитывая, что - легко реализовать решение, но это не хорошо всегда.

0
19.02.2020, 22:17

Обзор

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

Я добавил Шаг № 3, потому что я забыл об Администраторской Панели. Ой! Таким образом, теперь, вошедший ли Панель инструментов или вошла в систему и на веб-сайте WP, Вы имеете полный контроль над тем, что доступно редактору для 'edit_theme_capablity' подменю.

Если у Вас нет Ролей и Плагина Возможностей установленными, можно сделать это:

(Если Вы делаете, пропустите № 1 и перейдите к № 2, затем № 3),

(1) Добавьте это к своей теме functions.php:

// Add all Editors the privilege to edit Themes, Widgets, Menus, Backgrounds

// get the the role object - editor, author, etc. (or those specially created)
$role_object = get_role( 'editor' );

// add $cap capability to this role object
// 'edit_theme_options' enables Dashboard APPEARANCE sub-menus
// for Themes, Widgets, Menus, and Backgrounds for users with that role
$role_object->add_cap( 'edit_theme_options' );


(2) Добавьте это к admin-footer.php : (расположенный в wp-администраторском каталоге)
То, что это делает, должно позволить Вам выбирать, какую опцию Вы хотите, чтобы Редакторы имели на их Панели инструментов.
СЧИТАЙТЕ ЭТО для большего количества информации от автора отрывка jQuery.

<?php
  //  Using jQuery: How to allow Editors to edit only Menus (or more!)
  //  Placed in admin-footer.php as Dashboard comes from the wp-admin files

  if ( is_user_logged_in() ) { // This IF may be redundant, but safe is better than sorry...
    if ( current_user_can('edit_theme_options') && !current_user_can('manage_options') ) { // Check if non-Admin
?>
      <script>
    jQuery.noConflict();
    jQuery(document).ready(function() {
      //  Comment out the line you WANT to enable, so it displays (is NOT removed).
      //  For example, the jQuery line for MENUS is commented out below so it's not removed.

      // THEMES:  If you want to allow THEMES, also comment out APPEARANCE if you want it to display Themes when clicked. (Default behaviour)
      jQuery('li#menu-appearance.wp-has-submenu li a[href="themes.php"]').remove();
      jQuery('li#menu-appearance.wp-has-submenu a.wp-has-submenu').removeAttr("href");

      // WIDGETS:
      jQuery('li#menu-appearance.wp-has-submenu li a[href="widgets.php"]').remove();

      // MENUS:
      // jQuery('li#menu-appearance.wp-has-submenu li a[href="nav-menus.php"]').remove();

      // BACKGROUND:
      jQuery('li#menu-appearance.wp-has-submenu li a[href="themes.php?page=custom-background"]').remove();
    });
      </script>
<?php
    } // End IF current_user_can...
  } // End IF is_user_logged_in...
?>


(3) Добавьте это к Теме footer.php :
То, что это делает, должно позволить Вам выбирать, какую опцию Вы хотите, чтобы Редакторы имели на их Администраторской Панели.

<?php
  //  Using jQuery: How to allow Editors to edit only Menus (or more!)
  //  Placed in THEME's footer.php as the Admin Bar is added when a user is logged in

  if ( is_user_logged_in() ) { // This IF may be redundant, but safe is better than sorry...
    if ( current_user_can('edit_theme_options') && !current_user_can('manage_options') ) { // Check if non-Admin
?>
      <script>
    jQuery.noConflict();
    jQuery(document).ready(function() {
      //  Comment out the line you WANT to enable, so it displays (is NOT removed).
      //  For example, the jQuery line for MENUS is commented out below so it's not removed.

      // THEMES:
      jQuery('li#wp-admin-bar-themes').remove();

      // CUSTOMIZE:
      jQuery('li#wp-admin-bar-customize').remove();

      // WIDGETS:
      jQuery('li#wp-admin-bar-widgets').remove();

      // MENUS:
      // jQuery('li#wp-admin-bar-menus').remove();

      // BACKGROUND:
      jQuery('li#wp-admin-bar-background').remove();
    });
      </script>
<?php
    } // End IF current_user_can...
  } // End IF is_user_logged_in...
?>
1
19.02.2020, 22:17
  • 1
    Отметьте это <style> содержание не предназначено для работы назад, банка не элементы стиля, которые уже являются частью DOM когда <style> печатается. Это работает в некоторых браузерах, но Вы не можете полагаться на это. –  fuxia♦ 18.02.2013, 14:49
  • 2
    , который я знаю, и добавленные комментарии во фрагменте кода, который обращается к этому, и предложил, чтобы некоторый инициативный человек зафиксировал это самостоятельно. Поэтому это естественно должно было бы войти <код> в администратора-header.php </код> (где-нибудь в конце файла), и возможно я должен был сделать это первоначально. Я просто предложил решение за часы до этого и протестировал, это - функциональность и подтверждение концепции... И второпях совместно использовать его с миром. lol –  Chris Lemke 18.02.2013, 20:36
  • 3
    я заменил код для № 2 для использования jQuery вместо этого и это должно устранить любые проблемы проверки. В целом, часть jQuery вместе с любым Плагином Роли и Возможности (или используют код в № 1) должна рассмотреть исходный вопрос к их удовлетворенности. Я записал это для обеспечения гранулярности управления, которое отсутствовало. Другие могут использовать его (почему я отправил его), и даже другим, которые хотят добавить его к их Плагинам для Ролей и Возможностей. –  Chris Lemke 19.02.2013, 10:26
  • 4
    , я добавил Шаг № 3, потому что я забыл об Администраторской Панели. Ой! Теперь Вы имеете полный контроль, является ли Редактор в их Панели инструментов или вошел в систему и на веб-сайте. –  Chris Lemke 28.02.2013, 07:01

Теги

Похожие вопросы