Grupy możliwości: użytkownicy z wieloma rolami?

Jestem prawie pewien, że rozumiem ustawienia ról i możliwości w WordPress: szczegółowe możliwości, pogrupowane w role, które można przypisać użytkownikom. Kod powinien sprawdzać szczegółowe możliwości, a nie role (ponieważ możliwości poszczególnych ról mogą się zmieniać). Role niekoniecznie są hierarchiczne (choć role domyślne).

Czy istnieje jakiś sposób przypisywania wielu ról użytkownikom? Alternatywnie, mając wiele grup możliwości i kojarząc jedną lub więcej grup z użytkownikiem? Sposób działania mojej witryny wiąże się z pewnymi oczywistymi obowiązkami: aktualizowaniem stron internetowych, moderowaniem forów, aktualizowaniem kalendarza wydarzeń i tak dalej. Każda odpowiedzialność ma grupę możliwości niezbędnych do wykonywania związanych z nią zadań. Chciałbym umożliwić użytkownikowi wykonywanie jednego lub więcej obowiązków. Tak więc użytkownik A może aktualizować strony internetowe i kalendarz wydarzeń, ale nie moderować forów (co nie jest wystarczająco taktowne), ale użytkownik B może moderować fora, aktualizować kalendarz wydarzeń, ale nie jest dozwolony w pobliżu stron internetowych.

Czy istnieje jakiś sposób, by nie zdefiniować roli dla każdej możliwej kombinacji obowiązków?

Brak wielu ról irytował mnie od dawna, ponieważ bazowa klasa WP_User obsługuje wiele ról. Rozważałem nawet znalezienie alternatywnego rozwiązania programowego. @lpryor - po przeczytaniu twojego posta zmotywowałem go do samodzielnego wdrożenia.

Zajęło mi to zaskakująco mało wierszy, chociaż musiałem zhakować plik users.php, ponieważ byłem zbyt leniwy, aby stworzyć osobną wtyczkę, aby to dla mnie zrobić. Oczywiście jest to zły sposób, aby to zrobić, więc jeśli będę wystarczająco zmotywowany w przyszłości, mogę spróbować zrobić to właściwie.

Jeśli nie obchodzi Cię możliwość uaktualnienia do najnowszej wersji Wordpress (co powinieneś) - możesz zaimplementować wiele ról za pomocą poniższych fragmentów kodu. Pamiętaj, że nie jestem ekspertem od wordpress. Właśnie otworzyłem odpowiednie pliki i wprowadziłem zmiany, nie próbując zrozumieć pełnych konsekwencji tego, co robiłem. Kod wydaje mi się rozsądny, ale nie ufałbym mu w moim życiu.

(Używam 3.2, więc numery linii mogą się różnić) W klasie-wp-users-list-table.php tuż przed linią 150 dodaj kilka takich:

<div class="alignleft actions">
    <label class="screen-reader-text" for="remove_role"><?php _e( 'Remove role &hellip;' ) ?></label>
    <select name="remove_role" id="remove_role">
        <option value=''><?php _e( 'Remove role &hellip;' ) ?></option>
        <?php wp_dropdown_roles(); ?>
    </select>
    <?php submit_button( __( 'Remove' ), 'secondary', 'changeit', false ); ?>
</div>

następnie zmień funkcję current_account, aby wyglądała mniej więcej tak

function current_action() {
    if ( isset($_REQUEST['changeit']) ) {
        if ( !empty($_REQUEST['new_role']) )
            return 'promote';
        elseif ( !empty($_REQUEST['remove_role']) )
            return 'remove_role';
    }

    return parent::current_action();

}

Teraz w users.php Skomentuj linie 71-76

/*
if ( $id == $current_user->ID && !$wp_roles->role_objects[$_REQUEST['new_role']]->has_cap('promote_users') ) {
    $update = 'err_admin_role';
    continue;
}
*/

Zamień set_role w linii 83 na add_role

$user->add_role($_REQUEST['new_role']);

W wierszu 92 dodaj: (To tylko lekko edytowana kopia i wklej z akcji promowania - nie sprawdziłem, czy funkcja promot_user jest odpowiednia do usuwania ról)

case 'remove_role':
    check_admin_referer('bulk-users');

    if ( ! current_user_can( 'promote_users' ) )
            wp_die( __( 'You can’t edit that user.' ) );

    if ( empty($_REQUEST['users']) ) {
            wp_redirect($redirect);
            exit();
    }

    $editable_roles = get_editable_roles();
    if ( empty( $editable_roles[$_REQUEST['remove_role']] ) )
            wp_die(__('You can’t remove that role'));

    $userids = $_REQUEST['users'];
    $update = 'remove_role';
    foreach ( $userids as $id ) {
            $id = (int) $id;

            if ( ! current_user_can('promote_user', $id) )
                    wp_die(__('You can’t edit that user.'));
            // The new role of the current user must also have promote_users caps
            // Need to think this through
            /*
            if ( $id == $current_user->ID && !$wp_roles->role_objects[$_REQUEST['new_role']]->has_cap('promote_users') ) {
                    $update = 'err_admin_role';
                    continue;
            }
            */

            // If the user doesn't already belong to the blog, bail.
            if ( is_multisite() && !is_user_member_of_blog( $id ) )
                    wp_die(__('Cheatin’ uh?'));

            $user = new WP_User($id);
            $user->remove_role($_REQUEST['remove_role']);
    }

    wp_redirect(add_query_arg('update', $update, $redirect));
    exit();

W wierszu 370 dodaj:

case 'remove_role':
    $messages[] = '<div id="message" class="updated"><p>' . __('Removed role.') . '</p></div>';
    break;

Wtyczka User Role Editor obsługuje wiele ról dla użytkownika.

Po zainstalowaniu Użytkownicy> pod każdym użytkownikiem ma opcję Możliwości. URE traktuje pierwszą rolę WP jako „rolę podstawową” i umożliwia dodawanie „innych ról”.

Używam wtyczki Members wraz z niestandardowymi możliwościami tworzenia.

Nie możesz przypisać kilku ról do jednej osoby, ale możesz utworzyć dowolne role i określić, jakie możliwości ma ta rola.

W tempaltes możesz użyć czegoś takiego jak current_user_can () .