Czy istnieje sposób (wtyczka?), Aby ograniczyć użytkownikowi możliwość edytowania tylko jednej strony?


9

Używamy wordpress jak CMS i bardzo chcielibyśmy umożliwić użytkownikom utworzenie „strony głównej”. Idealnie byłoby, gdyby nie dopuścili do zepsucia całej witryny.

Czy istnieje prosty sposób ograniczenia uprawnień użytkowników do edycji na jednej stronie?

Obecnie używam wtyczki Members do robienia innych rzeczy opartych na uprawnieniach, więc byłoby wspaniale, gdyby rozwiązanie mogło to dobrze ulepszyć lub całkowicie zastąpić.

Punkty bonusowe za automatyczne tworzenie strony głównej po utworzeniu nowego użytkownika.


AKTUALIZACJE: Powinienem wyjaśnić, że strony te muszą ograniczać się do określonego obszaru witryny (tj. Wszystkich dzieci tej samej strony). Ponadto po rozmowie z niektórymi użytkownikami wydaje się, że przydałoby im się tworzenie podstron rozgałęziających się ze strony głównej.

Odpowiedzi:


5

Podstawowa instalacja WordPress prawdopodobnie nie zrobi tego, co chcesz. Możesz skonfigurować instancję obejmującą wiele witryn i pozwolić użytkownikom na posiadanie własnej witryny podrzędnej lub użyć czegoś takiego jak BuddyPress lub Mingle z funkcją profilu użytkownika.


4

Przepraszam, że to zrobiłem, ale natknąłem się na odpowiedź na forach wordpress .

Okazuje się, że Role Scoper robi to naprawdę dobrze. Autor tego postu na forum powiedział najlepiej:

Aby umożliwić użytkownikowi edycję jednej konkretnej strony, ale nic innego:

  1. Daj im rolę subskrybenta w WordPress
  2. Zarządzaj> Strony> Edytuj ich stronę
  3. Rozwiń kartę „Redaktorzy” w sekcji „Opcje zaawansowane”
  4. Zaznacz nieuzbrojone pole wyboru po lewej stronie nazwy użytkownika (jeśli zostaną utworzone strony potomne, zaznacz także pole wyboru usztywnione {[]}, które przypisuje rolę wszystkim bieżącym lub przyszłym stronom potomnym)
  5. Zapisz stronę

Brzmi jak proces ręczny. Co jeśli masz tysiące użytkowników?
MikeSchinkel

To z pewnością prawda, ale jak dotąd jest najbliższa. Trzymam nagrodę aż do końca.
Tom Wright

3

Zetknąłem się z tą samą sytuacją, co Ty, i stworzyłem niestandardowy typ postu o nazwie „strona główna”, a także stworzyłem wtyczkę „Bainternet Posts Creation Limits”, aby ograniczyć tworzenie każdego typu postów na użytkownika. Wypróbuj http://wordpress.org/extend/plugins/bainternet-posts-creation-limits/


Ładne proste podejście. Nieznaczny problem z tym, że jest oparty na postach - chcę również ograniczyć to, gdzie jest strona.
Tom Wright,

limit gdzie jest strona? chcesz wyjaśnić?
Bainternet,

Problem polega na tym, że chcę mieć strony wszystkich użytkowników w tym samym miejscu. Tj. Mysite.com/users/bob Plus, chcę również pozwolić na podstrony w tym samym stylu: mysite.com/users/bob/mysubpage
Tom Wright

2

Wtyczka User Access Manager zrobi to za Ciebie, wszystkie inne podejścia są zbyt skomplikowane. UAM jest po prostu łatwy, skonfiguruj grupy i przypisz grupę do swoich podstron, gotowy.



1

Sollution oznacza, że ​​wyłączyłeś edycję „normalnych” typów postów (post, strona).

To nie jest tak trudne, jak mogłoby się wydawać. Kluczem jest nazwa logowania użytkownika . To samo można zrobić z taksonomiami, a nawet terminami.

Zobacz następujące informacje (istnieje również przykład zapytania):

// 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

W przypadku taksonomii byłoby to jeszcze bardziej sensowne, ponieważ można było wyszukiwać tylko posty oznaczone tagami terminów z taksonomii użytkowników, ale wymagałoby to meta-skrzynki z terminami taksonomii użytkowników. Warunek byłby taki sam: nazwa logowania użytkownika i wystarczy dodać taksonomię:

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' );

Umieszczenie sprawdzania zdolności (current_user_can) może być również w innym miejscu. Wszystko zależy od twoich konkretnych potrzeb. Tylko dla pewności: są to przykłady, które poprowadzą cię na drodze do sollution. Mam nadzieję, że to pomoże :)


0

Zrobiłem coś podobnego z „członkami”, niestandardowym typem posta i ręcznym przypisaniem praw autorskich do konkretnego członka, ponieważ jest to strona internetowa małej grupy, ale pamiętam, że czytałem w jakimś wątku wsparcia dla prasy, że jest to możliwe aby dołączyć do procesu rejestracji, więc przypuszczam, że możliwe byłoby automatyczne utworzenie strony / niestandardowego typu posta dla użytkownika podczas rejestracji i przypisanie tej konkretnej strony do nowo utworzonego członka jako strony głównej. Dodałem również edytor frontonu Scribu i zablokowałem backend dla członków, którzy nie są administratorami. Prawdopodobnie możesz również dodać przekierowanie przy rejestracji, aby nowi członkowie zostali przekierowani na ich stronę (która, jak sądzę, może mieć domyślną treść).

Zobaczę, czy mogę znaleźć ten wątek wsparcia buddypress.

Dodatek - w selektorze autorów w polu edycji postów występuje błąd. Obecnie nie korzysta ze standardowego systemu uprawnień, co może utrudnić rozwiązanie członków (chociaż prawdopodobnie będzie działać, jeśli autor zostanie przypisany do tworzenia strony). Trac ma łatkę, ale nie sądzę, żeby została jeszcze zastosowana do rdzenia.


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.