Ogni volta che un visitatore del sito registra un account, o voi aggiungete manualmente un nuovo utente nella pagina di amministrazione degli Utenti, WordPress registra i dati essenziali dell’utente nelle tabelle wp_users e wp_usermeta. Il nuovo utente ottiene lo username di sua scelta, una password, un indirizzo email, un ruolo che determina ciò che l’utente può visualizzare nel pannello di amministrazione. Ma cosa sono esattamente i ruoli utente di WordPress?

Ruoli e Capacità degli Utenti di WordPress

Il sistema di gestione degli utenti di WordPress si basa su due concetti chiave: Ruoli e Capacità.

  • Un Ruolo identifica un gruppo di utenti a cui è consentito eseguire le stesse attività sul sito web.
  • Una Capacità è la capacità (o il permesso) di eseguire ogni singola attività assegnata a un ruolo.

Di default, WordPress dispone di sei ruoli:

  • Super Administrator è un utente che ha pieno accesso alle capacità multisite: può creare e gestire siti secondari, creare e gestire utenti di rete, installare e rimuovere temi e plugin e attivarli sul network.
  • Administrator è un utente che ha pieno accesso alle capacità di amministrazione di una normale installazione di WordPress.
  • Editor è un utente che può modificare e pubblicare contenuti creati da qualsiasi utente.
  • Author può pubblicare e modificare il proprio contenuto.
  • Contributor può creare e modificare ma non pubblicare i propri contenuti.
  • Subscriber può solo accedere al proprio profilo.

Questi ruoli utente di WordPress sono ordinati gerarchicamente, il che significa che i ruoli di livello superiore hanno le stesse capacità di ruoli inferiori, oltre a una serie di capacità specifiche del ruolo.
Considerate la seguente tabella:

Subscriber Contributor Editor
read read read
edit_posts edit_posts
delete_posts delete_posts
delete_published_posts
publish_posts
upload_files
edit_published_posts

Un Contributor ha le stesse capacità di lettura (read) di un Subscriber, ma ha altre due capacità, edit_posts e delete_posts, specifiche di questo ruolo: il contributor può creare, modificare ed eliminare i propri post non ancora pubblicati.
Un Editor ha le stesse capacità di un Contributor e in più può pubblicare, modificare ed eliminare i propri post e caricare file multimediali.

Dobbiamo fare una distinzione tra due tipi di capacità:

  • Meta Capacità dipendono dal contesto (ad esempio, l’utente che ha effettuato l’accesso e il post/pagina corrente).
  • Capacità Primitive non dipendono dal contesto (ad esempio, modificare i post creati da altri utenti).

Un utente può modificare un post se è autore del post (meta capacità 'edit_post') o se ha la capacità di modificare i post creati da altri utenti (capacità primitiva 'edit_others_posts').
WordPress traduce automaticamente le meta capacità in una o più capacità primitive per i post regolari, ma quando si utilizzano i post type è necessario mappare manualmente le meta-caps alle capacità primitive.
Si veda il Codex per un elenco completo delle capacità native.

I ruoli e le capacità predefinite di solito sono sufficienti a soddisfare i requisiti più comuni di un sito web, ma a volte vi sarà chiesto di fornire all’amministratore del sito un controllo più granulare su ciò che gli utenti possono fare e vedere.
Fortunatamente, come utenti e/o sviluppatori di WordPress, non siamo limitati ai ruoli e alle capacità predefinite, perché WordPress ci consente di creare nuove capacità e nuovi ruoli e assegnare diversi set di capacità ai ruoli esistenti. Ad esempio, è possibile assegnare ai sottoscrittori (Subscriber) la possibilità di creare e modificare i post e/o assegnare ai Contributor la possibilità di pubblicare. Ma potete ottenere molto di più dal sistema di gestione degli utenti:

  • potete mostrare/ nascondere elementi del front-end, come voci di menu, post o widget, a seconda del ruolo dell’utente
  • potete personalizzare il contenuto dei post in base all’utente
  • potete limitare l’accesso a sezioni del sito specifiche per utenti o ruoli specifici
  • potete creare custom post type con capacità personalizzate che possono essere declinate in modo diverso per ogni ruolo

Quest’ultimo punto individua l’obiettivo di questo post.

Studenti, Insegnanti e Compiti a Casa

Supponete di creare un sito web educativo in cui studenti e insegnanti possano interagire tra loro. Gli studenti dovrebbero creare progetti e inviarli per la correzione.
Gli insegnanti dovrebbero essere in grado di modificare i progetti degli studenti e pubblicarli se approvati.
I commenti sono consentiti: gli studenti possono commentare qualsiasi progetto, ma solo gli insegnanti possono moderare i commenti.
Ecco la nostra lista delle cose da fare:

  • Aggiungere i ruoli utente student e teacher
  • Registrare il post type student_project e la tassonomia personalizzata subject
  • Registrare e mappare capacità specifiche per il tipo di post student_project
  • Assegnare capacità ai ruoli di administrator, student e teacher

Analizzeremo l’argomento principalmente dal punto di vista dello sviluppatore, creando un plugin che registri il tipo di post personalizzato e la tassonomia, i ruoli e le capacità. Ma non dimenticheremo i non sviluppatori, e nella parte finale di questo post suggerirò alcuni dei plugin più popolari e completi che troverete in rete per gestire i ruoli utente e le capacità da professionisti, ma senza scrivere una sola riga di codice.

Prima di andare avanti con la lettura dell’articolo, date un’occhiata al codice del plugin su Gist.

Registrazione dei Ruoli e delle Capacità degli Utenti di WordPress

Agli studenti sarà consentito di leggere tutti i progetti e creare, modificare ed eliminare i propri progetti. Non saranno autorizzati a pubblicare alcun progetto, né a modificare e cancellare progetti pubblicati.
Gli insegnanti potranno controllare ogni aspetto dell’amministrazione del progetto. Potranno creare nuovi progetti e modificare, eliminare e pubblicare progetti creati da qualsiasi utente.

ruolo studente

Assegnare il ruolo Studente ad un nuovo utente nella schermata Utenti – Aggiungi nuovo

Detto questo, registriamo i ruoli student e teacher:

function kinsta_add_roles() {
	add_role( 'student', 'Student', array( 
		'read' => true, 
		'edit_posts'   => true, 
		'delete_posts' => true ) );
	add_role( 'teacher', 'Teacher', array( 
		'read' => true, 
		'edit_posts'   => true, 
		'delete_posts' => true,
		'delete_published_posts' => true,
		'publish_posts' => true,
		'upload_files' => true,
		'edit_published_posts' => true,
		'manage_categories' => true ) );
}
register_activation_hook( __FILE__, 'kinsta_add_roles' );
  • register_activation_hook registra una funzione da eseguire quando viene attivato un plugin. Qui è preferibile un action hook come init, perché i nuovi ruoli sono registrati nel database e non è necessario eseguire la funzione ogni volta che WordPress viene caricato. register_activation_hook accetta due argomenti: il percorso del file principale del plugin (__FILE__) e la funzione di callback da eseguire ('kinsta_add_roles').
  • All’attivazione del plugin viene eseguito register_activation_hook e add_role registra il nuovo ruolo nella tabella wp_options se questo non esiste già. Questa seconda funzione accetta tre argomenti: il nome del ruolo, il nome visualizzato e una serie di capacità.

La funzione di callback aggiunge due ruoli. Ogni ruolo è fornito di un diverso set di capacità: gli studenti potranno leggere post pubblici, creare, modificare ed eliminare i propri post se questi non sono pubblicati. Gli insegnanti potranno pubblicare i propri post, modificare ed eliminare i post pubblicati, caricare file multimediali e gestire le categorie.

Manu ruoli

Il menu Ruoli nella schermata Profilo Utente

Ora possiamo creare una comunità di studenti e insegnanti, ma questi non sono molto più di contributori ed editori. Quindi, facciamo un passo avanti e registriamo un tipo di post personalizzato per studenti, insegnanti e amministratori del sito.

Registrazione di un Custom Post Type e Relativa Tassonomia

Il seguente codice registra il tipo di post student_project:

function kinsta_project_post_type(){

	// define an array of labels
	$post_type_labels = array(
		'name' 					=> __( 'Projects' ),
		'singular_name'			=> __( 'Project' ),
		'add_new_item'			=> __( 'Add New Project' ),
		'edit_item'				=> __( 'Edit Project' ),
		'new_item'				=> __( 'New Project' ),
		'view_item'				=> __( 'View Project' ),
		'view_items'			=> __( 'View Projects' ),
		'not_found'				=> __( 'No Projects found' ),
		'not_found_in_trash'	=> __( 'No Projects found in Thrash' ),
		'all_items'				=> __( 'All Projects' ),
		'archives'				=> __( 'Project Archives' ),
		'insert_into_item'		=> __( 'Insert into Project' ),
		'uploaded_to_this_item'	=> __( 'Uploaded to this Project' )
		);

	// define an array of arguments
	$post_type_args = array(
		'labels' => $post_type_labels,
		'public' => true,
		'menu_position' => 5,
		'menu_icon' => 'dashicons-media-document',
		'hierarchical' => false,
		'supports' => array( 'title', 'editor', 'author', 'excerpt', 'custom-fields', 'comments' ),
		'taxonomies' => array( 'subject' ),
		'has_archive' => true,
		);

	register_post_type( 'student_project', $post_type_args );

}
add_action( 'init', 'kinsta_project_post_type' );

Per registrare un nuovo tipo di post, dobbiamo chiamare la funzione register_post_type, che deve essere invocata tramite l’azione init.
register_post_type accetta due argomenti: lo slug del tipo di post ('student_project') e una serie di argomenti che impostano le etichette di amministrazione e i parametri del tipo di post.
Di seguito, registreremo una tassonomia non gerarchica che identifica l’oggetto del progetto:

function kinsta_project_post_type(){

	$taxonomy_labels = array(
		'name'                       => __( 'Subjects' ),
		'singular_name'              => __( 'Subject' ),
		'search_items'               => __( 'Search Subjects' ),
		'popular_items'              => __( 'Popular Subjects' ),
		'all_items'                  => __( 'All Subjects' ),
		'parent_item'                => null,
		'parent_item_colon'          => null,
		'edit_item'                  => __( 'Edit Subject' ),
		'update_item'                => __( 'Update Subject' ),
		'add_new_item'               => __( 'Add New Subject' ),
		'new_item_name'              => __( 'New Subject Name' ),
		'separate_items_with_commas' => __( 'Separate subjects with commas' ),
		'add_or_remove_items'        => __( 'Add or remove subjects' ),
		'choose_from_most_used'      => __( 'Choose from the most used subjects' ),
		'not_found'                  => __( 'No subjects found.' ),
		'menu_name'                  => __( 'Subjects' ),
		);

	$taxonomy_args = array(
		'hierarchical'          => false,
		'labels'                => $taxonomy_labels,
		'show_ui'               => true,
		'show_admin_column'     => true,
		'update_count_callback' => '_update_post_term_count',
		'query_var'             => true,
		'rewrite'               => array( 'slug' => 'subject' ),
	);

	register_taxonomy( 'subject', 'student_project', $taxonomy_args );
}
add_action( 'init', 'kinsta_project_post_type' );

register_taxonomy accetta tre argomenti: la slug della tassonomia ('subject'), il tipo di post collegato ('student_project'), un array di argomenti che memorizzano le etichette e altri parametri (si veda il Codex per maggiori informazioni).
Proprio come register_post_type, register_taxonomy va essere agganciato all’azione init.
Una volta fatto, è il momento di definire il set di capacità che consentiranno livelli separati di controllo sul tipo di post.

Un Set Specifico di Capacità per i Progetti degli Studenti

Per aggiungere capacità specifiche per il nuovo tipo di post, dovremo utilizzare uno o due dei seguenti argomenti di register_post_type:

capability_type: (string|array) una stringa da utilizzare come base per costruire le capacità di lettura, modifica ed eliminazione (es. 'student_project'). Se avesste bisogno di passare plurali alternativi, (cioè story/stories), dovreste impostare il suo valore ad un array (cioè array('story', 'stories')). capability_type genera le seguenti capacità:

Meta capacità:

  • edit_{capability_type}
  • read_ {capability_type}
  • delete_{capability_type}

Capacità Primitive:

  • edit_{capability_type}s
  • edit_others_{capability_type}s
  • publish_{capability_type}s
  • read_private_{capability_type}s

Capacità Primitive definite nella funzione map_meta_cap:

  • read
  • delete_{capability_type}s
  • delete_private_{capability_type}s
  • delete_published_{capability_type}s
  • delete_others_{capability_type}s
  • edit_private_{capability_type}s
  • edit_published_{capability_type}s

capability_type garantisce un controllo generale sulle capacità del tipo di post. Se doveste aver bisogno di un controllo più granulare, è possibile utilizzare l’argomento capabilities.

capabilities: (array) è un array di capacità per il tipo di post. Se scegliete questo argomento invece di capability_type, potete passarlo alla funzione register_post_type come segue:

'capabilities' => array(
	'read_post'			=> 'read_student_project',
	'read_private_posts' 		=> 'read_private_student_projects',
	'edit_post'			=> 'edit_student_project',
	'edit_posts'			=> 'edit_student_projects',
	'edit_others_posts'		=> 'edit_others_student_projects',
	'edit_published_posts'		=> 'edit_published_student_projects',
	'edit_private_posts'		=> 'edit_private_student_projects',
	'delete_post'			=> 'delete_student_project',
	'delete_posts'			=> 'delete_student_projects',
	'delete_others_posts'		=> 'delete_others_student_projects',
	'delete_published_posts'	=> 'delete_published_student_projects',
	'delete_private_posts'		=> 'delete_private_student_projects',
	'publish_posts'			=> 'publish_student_projects',
	'moderate_comments'		=> 'moderate_student_project_comments',
	),

map_meta_cap: (boolean) converte automaticamente le meta capacità in una o più capacità primitive per il tipo di post. Nel nostro esempio, deve essere impostato su true quando si utilizza l’argomento capability, ma potrebbe essere necessario impostarne il valore su false quando si utilizza l’argomento capability_type (ulteriori informazioni su questo argomento nel Codex).

Ora possiamo tornare alla nostra funzione register_post_type e definire un nuovo array di argomenti come segue:

$post_type_args = array(
	'labels' => $post_type_labels,
	'public' => true,
	'menu_position' => 5,
	'menu_icon' => 'dashicons-media-document',
	//'capability_type' => 'student_project',
	'capabilities' => array(
		'read_post'					=> 'read_student_project',
		'read_private_posts' 		=> 'read_private_student_projects',
		'edit_post'					=> 'edit_student_project',
		'edit_posts'				=> 'edit_student_projects',
		'edit_others_posts'			=> 'edit_others_student_projects',
		'edit_published_posts'		=> 'edit_published_student_projects',
		'edit_private_posts'		=> 'edit_private_student_projects',
		'delete_post'				=> 'delete_student_project',
		'delete_posts'				=> 'delete_student_projects',
		'delete_others_posts'		=> 'delete_others_student_projects',
		'delete_published_posts'	=> 'delete_published_student_projects',
		'delete_private_posts'		=> 'delete_private_student_projects',
		'publish_posts'				=> 'publish_student_projects',
		'moderate_comments'			=> 'moderate_student_project_comments',
		),
	'map_meta_cap' => true,
	'hierarchical' => false,
	'supports' => array( 'title', 'editor', 'author', 'excerpt', 'custom-fields', 'comments' ),
	'taxonomies' => array( 'subject' ),
	'has_archive' => true,
	);

register_post_type( 'student_project', $post_type_args );

Le capacità sono ben documentate nel file /wp-includes/post.php e nella documentazione della funzione register_post_type.

Aggiunta di Capacità a Insegnanti e Studenti

Ora che abbiamo registrato due ruoli e un tipo di post con capacità specifiche, il nostro compito è assegnare le capacità ai ruoli:

function kinsta_add_caps(){
	$admin = get_role( 'administrator' );
	$admin->add_cap( 'read_student_project' );
	$admin->add_cap( 'read_private_student_project' );
	$admin->add_cap( 'edit_student_project' );
	$admin->add_cap( 'edit_student_projects' );
	$admin->add_cap( 'edit_others_student_projects' );
	$admin->add_cap( 'edit_published_student_projects' );
	$admin->add_cap( 'edit_private_student_projects' );
	$admin->add_cap( 'delete_student_projects' );
	$admin->add_cap( 'delete_student_project' );
	$admin->add_cap( 'delete_others_student_projects' );
	$admin->add_cap( 'delete_published_student_project' );
	$admin->add_cap( 'delete_student_project' );
	$admin->add_cap( 'delete_private_student_project' );
	$admin->add_cap( 'publish_student_projects' );
	$admin->add_cap( 'moderate_student_project_comments' );

	$student = get_role( 'student' );
	$student->add_cap( 'read_student_project' );
	$student->add_cap( 'edit_student_project' );
	$student->add_cap( 'edit_student_projects' );
	$student->add_cap( 'delete_student_project' );
	$student->add_cap( 'delete_student_projects' );

	$teacher = get_role( 'teacher' );
	$teacher->add_cap( 'read_student_project' );
	$teacher->add_cap( 'read_private_student_project' );
	$teacher->add_cap( 'edit_student_project' );
	$teacher->add_cap( 'edit_student_projects' );
	$teacher->add_cap( 'edit_others_student_projects' );
	$teacher->add_cap( 'edit_published_student_projects' );
	$teacher->add_cap( 'edit_private_student_projects' );
	$teacher->add_cap( 'delete_student_project' );
	$teacher->add_cap( 'delete_student_projects' );
	$teacher->add_cap( 'delete_others_student_projects' );
	$teacher->add_cap( 'delete_published_student_projects' );
	$teacher->add_cap( 'delete_private_student_project' );
	$teacher->add_cap( 'publish_student_projects' );
	$teacher->add_cap( 'moderate_student_project_comments' );
}
add_action( 'admin_init', 'kinsta_add_caps');

Il codice è abbastanza intuitivo: la funzione di callback è agganciata all’azione admin_init, che viene attivata, prima di ogni altro hook, quando viene caricato il pannello di amministrazione. Il metodo add_cap dell’oggetto WP_Role assegna la capacità specificata ad un ruolo.

Schermata Progetti

La schermata progetti per uno studente

Pulizia del Database alla Disattivazione del Plugin

Infine, possiamo eliminare i ruoli student e teacher e rimuovere le capacità legate al tipo di post dal ruolo di amministratore alla disattivazione del plugin:

function kinsta_remove_roles(){
	//check if role exist before removing it
	if( get_role('student') ){
		remove_role( 'student' );
	}
	if( get_role('teacher') ){
		remove_role( 'teacher' );
	}

	$admin = get_role( 'administrator' );

	$caps = array(
		'read_student_project',
		'read_private_student_project',
		'edit_student_project',
		'edit_student_projects',
		'edit_others_student_projects',
		'edit_published_student_projects',
		'edit_private_student_projects',
		'delete_student_projects',
		'delete_student_project',
		'delete_others_student_projects',
		'delete_published_student_project',
		'delete_student_project',
		'delete_private_student_project',
		'publish_student_projects',
		'moderate_student_project_comments'
	);

	foreach ( $caps as $cap ) {
		$admin->remove_cap( $cap );
	}	
}
register_deactivation_hook( __FILE__, 'kinsta_remove_roles' );

Il progetto è ora completo e potete prelevare il codice completo di questi esempi da questo Gist pubblico.

Schermata Progetti

La Schermata Progetti per un insegnante

Controllare i Ruoli Utente e le Capacità di WordPress con i Plugin

Se non siete programmatori, potete comunque assumere il controllo dei ruoli e delle capacità grazie a una serie di plugin gratuiti disponibili nella directory dei plugin.

Members di Justin Tadlock è un editor di ruoli e capacità completo e facile da usare. Consente all’amministratore del sito di aggiungere, modificare e rimuovere ruoli e capacità, assegnare agli utenti più di una capacità, negare capacità specifiche a ruoli specifici, controllare quali ruoli possono accedere ai contenuti dei post, fornisce shortcode, widget e altro ancora.

Pagina Add new Role del plugin Members

Pagina Add new Role del plugin Members

User Role Editor di Vladimir Garagulya è un altro plugin che offre il pieno controllo su ruoli e capacità. Inoltre, consente agli amministratori del sito di assegnare ruoli a singoli utenti e garantisce la compatibilità Multisite. Questo plugin è disponibile anche in una versione commerciale dotata di funzionalità aggiuntive.

WPFront User Role Editor è un’altra opzione per gestire ruoli e capacità in WordPress. È disponibile in una versione gratuita nella directory dei plugin e in una versione commerciale con funzionalità più avanzate.

Sebbene non sia un editor di ruoli, User Switching è un plugin indispensabile per la gestione dei ruoli e delle capacità. Il suo unico scopo è di consentire all’amministratore del sito di passare da un account utente all’altro con un solo clic, in modo che non sia necessario effettuare il logout e il login ripetutamente per verificare cosa possono vedere gli utenti sul sito web.

Conclusioni

A prima vista, i concetti dei ruoli e delle capacità degli utenti di WordPress possono essere un po’ difficili da comprendere, soprattutto per quanto riguarda le meta capacità e le capacità primitive. Tuttavia, una volta focalizzato il concetto chiave del sistema di gestione degli utenti di WordPress, è possibile ottenere facilmente un controllo granulare sulle attività degli utenti.
Avete mai avuto occasione di creare siti web centrati sull’utente? Condividete le vostre esperienze con noi nei commenti.


Se ti è piaciuto questo articolo, allora apprezzerai la piattaforma di hosting WordPress di Kinsta. Metti il turbo al tuo sito web e ricevi supporto 24x7 dal nostro team di veterani di WordPress. La nostra infrastruttura potenziata da Google Cloud è centrata su scaling automatico, performance e sicurezza. Permettici di mostrarti la differenza di Kinsta! Scopri i nostri piani