Чи існує спосіб (плагін?) Обмежити користувача у можливості редагувати лише одну сторінку?


9

Ми використовуємо wordpress, як CMS, і дуже хотіли б, щоб користувачі мали «домашню сторінку». В ідеалі їм не вдалося б заблокувати весь сайт.

Чи існує простий спосіб обмежити права редагування користувачів однією сторінкою?

Наразі я використовую плагін Members, щоб робити інші матеріали на основі дозволів, тому було б чудово, якби рішення могло або акуратно доповнити це, або повністю замінити його.

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


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

Відповіді:


5

Базова установка WordPress, ймовірно, не буде робити те, що ви хочете. Ви можете створити екземпляр для багатьох сайтів і дозволити користувачам мати власний "під" сайт або використовувати щось на зразок BuddyPress або Mingle, що має функцію профілю користувача.


4

Вибачте за це, але я натрапив на відповідь на форумах wordpress .

Виявляється, Ролевий Скепер робить це справді добре. Автор цього форуму сказав, що найкраще:

Щоб дозволити користувачеві редагувати одну конкретну сторінку, але нічого іншого:

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

Звучить як ручний процес. Що робити, якщо у вас тисячі користувачів?
MikeSchinkel

Це звичайно так, але це найближче досі. Я буду тримати щедрість відкритою до кінця.
Том Райт

3

Я зіткнувся з тією ж ситуацією, що і ви, і я створив спеціальний тип публікації під назвою "домашня сторінка", а також створив плагін "Межі створення повідомлень Bainternet", щоб обмежити створення кожного типу публікації для кожного користувача. Спробуйте http://wordpress.org/extend/plugins/bainternet-posts-creation-limits/


Приємний простий підхід. Незначна проблема в тому, що вона базується на публікації - я також хочу обмежити, де знаходиться сторінка.
Том Райт

обмежити, де стоїть сторінка? хочете пояснити?
Бейнтернет

Тому проблема полягає в тому, що я хочу, щоб усі сторінки користувачів були в одному місці. Тобто mysite.com/users/bob Plus, я також хочу дозволити підсторінки в тому ж стилі: mysite.com/users/bob/mysubpage
Tom Wright,

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.