Есть ли способ (плагин?) Ограничить пользователя возможностью редактировать только одну страницу?


9

Мы используем WordPress как CMS и очень хотим, чтобы у пользователей была «домашняя страница». В идеале они не должны были испортить весь сайт.

Есть ли простой способ ограничить права пользователей на редактирование одной страницы?

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

Бонусные баллы за автоматическое создание домашней страницы при создании нового пользователя.


ОБНОВЛЕНИЯ: Я должен уточнить, что эти страницы должны быть ограничены определенной областью сайта (то есть все дети одной и той же страницы). Кроме того, после разговора с некоторыми пользователями кажется, что было бы полезно создать ветвление подстраниц со своей домашней страницы.

Ответы:


5

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


4

Извините, что сделал это, но я наткнулся на ответ на форумах WordPress .

Оказывается, Роль Скоупер делает это очень хорошо. Автор этого сообщения на форуме сказал это лучше всего:

Чтобы позволить пользователю редактировать одну конкретную страницу, но не что-нибудь еще:

  1. Дайте им роль подписчика в WordPress
  2. Управление> Страницы> Редактировать свою страницу
  3. Разверните вкладку «Редакторы» в разделе «Дополнительные параметры»
  4. Установите флажок без скобок слева от имени вашего пользователя (если дочерние страницы будут созданы, установите флажок в скобках {[]}, который назначает роль для всех текущих или будущих дочерних страниц)
  5. Сохранить страницу

Звучит как ручной процесс. Что делать, если у вас есть тысячи пользователей?
MikeSchinkel

Это, конечно, правда, но пока самое близкое. Я буду держать награду открытой до самого конца.
Том Райт

3

Я столкнулся с той же ситуацией, что и вы, и я создал собственный тип поста с именем "homepage", а также создал плагин "Bainternet Posts Creation Limits", чтобы ограничить создание каждого типа поста для каждого пользователя. Попробуйте это http://wordpress.org/extend/plugins/bainternet-posts-creation-limits/


Хороший простой подход. Небольшая проблема с тем, что он основан на постах - я также хочу ограничить, где находится страница.
Том Райт

ограничить, где находится страница? хочешь объяснить?
Bainternet

Поэтому проблема в том, что я хочу, чтобы все пользовательские страницы были в одном месте. Т.е. mysite.com/users/bob Plus, я также хочу разрешить подстраницы в том же стиле: mysite.com/users/bob/mysubpage
Том Райт

2

Плагин User Access Manager сделает это за вас, все остальные подходы слишком сложны. UAM - это просто, настройте группы и назначьте группу своим подстраницам, готово.



1

Решение подразумевает, что вы отключили редактирование «обычных» типов записей (публикация, страница).

Это не так сложно, как вы могли бы поверить. Ключ является имя пользователя Логин . То же самое можно сделать с таксономиями или даже терминами.

Смотрите следующее (также есть пример для запроса):

// 1st: Add a post type for that user with it's 
//   user login & according capabilities 
function create_user_home() {
    global $current_user;
    get_currentuserinfo();

    register_post_type(
        'home_of_'.$current_user->user_login,
        array(
            'public' => true,
            'capability_type' => $current_user->user_login,
            'capabilities' => array(
                'publish_posts' => 'publish_'.$current_user->user_login,
                'edit_posts' => 'edit_'.$current_user->user_login,
                'edit_others_posts' => 'edit_'.$current_user->user_login,
                'delete_posts' => 'delete_'.$current_user->user_login,
                'delete_others_posts' => 'delete_others_'.$current_user->user_login,
                'read_private_posts' => 'read_private_'.$current_user->user_login,
                'edit_post' => 'edit_'.$current_user->user_login,
                'delete_post' => 'delete_'.$current_user->user_login,
                'read_post' => 'read_'.$current_user->user_login,
            ),
        )
    );
}
add_action( 'init', 'create_user_home' );

// A query could be done like this:
wp_reset_query(); // to be sure

global $wp_query, $current_user;
get_currentuserinfo();

$query_user_home = new WP_Query( array(
    ,'order'        => 'ASC'
    ,'post_type'    => 'home_of_'.$current_user->user_login
    ,'post_status'  => 'publish'
) );

if ( $query_user_home->have_posts() ) :
    while ( $query_user_home->have_posts() ) : $query_user_home->the_post();
        // check for password
        if ( post_password_required() ) :
            the_content();
        elseif ( !current_user_can('') ) :
            // display some decent message here
            return;
        else :

            // here goes your content

        endif;
    endwhile;

else : // else; no posts
    printf(__( 'Nothing from Mr./Mrs. %1$s so far.', TEXTDOMAIN ), $current_user->user_firstname.' '.$current_user->user_lastname);
endif; // endif; have_posts();

wp_rewind_posts(); // for a sec. query

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

function create_user_tax() {
    if ( current_user_can("$current_user->user_login") ) :
        global $current_user;
        get_currentuserinfo();

        $singular = $current_user->user_login;
        $plural = $singular.'\'s';

        // labels
        $labels = array (
                 'name'         => $plural
                ,'singular_name'=> $singular
            );

        // args
        $args = array (
             'public'               => true
            ,'show_in_nav_menus'    => true
            ,'show_ui'              => true
            ,'query_var'            => true
            ,'labels'               => $labels
            ,'capabilities' => array(
                'manage_'.$current_user->user_login
            )
        );

        // Register
        register_taxonomy ( 
             $current_user->user_login
            ,array ( 'post', 'page' )
            ,$args
        ); 
        // Add to post type
        // you can even add your current user post type here
        register_taxonomy_for_object_type (
             $current_user->user_login
             ,array ( 'post', 'page', 'home_of_'.$current_user->user_login ) 
        );
    endif;
}
add_action( 'init', 'create_user_tax' );

Размещение проверки возможностей (current_user_can) может быть и другим. Зависит все от ваших конкретных потребностей. Просто чтобы убедиться в этом: вот примеры, которые помогут вам на пути к решению. Надеюсь, это поможет :)


0

Я сделал нечто подобное с «участниками», пользовательским типом поста и ручным назначением прав автора определенному участнику, поскольку это веб-сайт небольшой группы, но я помню, что читал в какой-то ветке поддержки прессы друзей, что это возможно подключиться к процессу регистрации, поэтому я предполагаю, что можно будет автоматически создать страницу / пользовательский тип записи для каждого пользователя при регистрации и назначить эту конкретную страницу вновь созданному участнику в качестве домашней страницы. Я также добавил редактор внешнего интерфейса Scribu и заблокировал его для пользователей, которые не являются администраторами. Вы также можете добавить перенаправление при регистрации, чтобы новые участники перенаправлялись на свою страницу (которая, я полагаю, могла бы иметь некоторый контент по умолчанию).

Я посмотрю, смогу ли я найти эту ветку поддержки buddypress.

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


Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.