Chi ha accesso al tuo WordPress: i ruoli utente e cosa può fare ciascuno

Apri la schermata Utenti del tuo WordPress e conta. Se ci sono cinque nomi e due non sai chi siano, non è un problema di ordine: è un problema di accessi. E quasi sempre dentro quella lista c’è ancora l’agenzia che ha costruito il sito due anni fa, con il ruolo più alto che WordPress sa dare.

La domanda giusta non è «che ruolo gli metto». È: cosa deve fare questa persona, e qual è il ruolo più piccolo che glielo permette. La documentazione di WordPress lo dice in una riga, parlando di come costruire ruoli su misura: «Only grant the capabilities required for the tasks the role is intended to perform» — concedi solo i permessi necessari ai compiti per cui il ruolo esiste.

I cinque ruoli, e cosa significano in pratica

WordPress ha sei ruoli predefiniti, ma su un sito singolo come il tuo ne vedi cinque (il sesto, Super Admin, esiste solo nelle installazioni multisito). Le definizioni sono quelle della documentazione ufficiale:

• Amministratore (administrator) — «somebody who has access to all the administration features within a single site»: ha accesso a tutte le funzioni di amministrazione del sito.
• Editore (editor) — «somebody who can publish and manage posts including the posts of other users»: pubblica e gestisce gli articoli, anche quelli scritti da altri.
• Autore (author) — «somebody who can publish and manage their own posts»: pubblica e gestisce i propri articoli.
• Collaboratore (contributor) — «somebody who can write and manage their own posts but cannot publish them»: scrive e gestisce i propri articoli, ma non può pubblicarli.
• Sottoscrittore (subscriber) — «somebody who can only manage their profile»: può solo gestire il proprio profilo.

Tre cose non ovvie stanno dietro questo elenco, e sono quelle che fanno la differenza quando decidi.

1. Amministratore non vuol dire «capo»: vuol dire installare codice

Su un sito singolo l’Amministratore è tutto. La documentazione è esplicita: «In the case of single site WordPress installation, Administrators are, in effect, Super Admins». Non c’è nessuno sopra di lui.

Ma la parte che conta non è l’organigramma, è l’elenco dei permessi che solo l’Amministratore ha su un sito singolo: install_plugins (Plugin → Aggiungi nuovo), install_themes, update_core (aggiornare WordPress stesso), edit_plugins e edit_themes — cioè modificare i file di plugin e temi direttamente dal pannello. Più create_users, edit_users e delete_users per la gestione degli utenti, e manage_options per tutte le schermate Impostazioni.

Tradotto: dare l’accesso Amministratore a qualcuno significa dargli la possibilità di far girare codice sul tuo server e di creare altri utenti, Amministratori compresi. Non è un permesso di modifica dei contenuti più generoso degli altri. È una cosa di categoria diversa.

Da qui la regola pratica: gli Amministratori si contano sulle dita di una mano, sono persone che conosci di persona, e l’elenco si rivede quando un rapporto di lavoro finisce. L’agenzia che ha fatto il sito ha avuto bisogno di quel ruolo durante lo sviluppo. A sito finito, no.

2. Il ruolo si chiama «Editore» ma non modifica il sito

Questo manda fuori strada molti. L’Editore gestisce i contenuti — articoli, pagine, categorie, commenti, media — ma non tocca l’aspetto del sito. Con un tema a blocchi, l’accesso all’editor del sito (Site Editor), quello con cui si modificano template, intestazione, piè di pagina e stili, dipende dal permesso edit_theme_options, che la documentazione descrive così: «Grants access to the Site Editor and its navigation menu». Quel permesso ce l’ha l’Amministratore, non l’Editore. Stessa cosa per i menu, i widget e la personalizzazione del tema.

È una buona notizia, non un limite: significa che puoi affidare a un collaboratore tutta la redazione del sito senza che possa smontarne il layout.

3. L’Editore può scrivere HTML e JavaScript

L’altra faccia della medaglia, e il motivo per cui l’Editore non è un ruolo da regalare. Su un sito singolo, Amministratore ed Editore hanno il permesso unfiltered_html, descritto senza giri di parole: «Allows user to post HTML markup or even JavaScript code in pages, posts, comments and widgets», con la nota «Enabling this option for untrusted users may result in their posting malicious or poorly formatted code».

Autore, Collaboratore e Sottoscrittore non ce l’hanno: il loro HTML viene filtrato. Quindi la scelta fra Autore ed Editore per un collaboratore esterno non è una questione di quanto ti fidi delle sue capacità editoriali, ma di quanto ti fidi e basta.

Il caso del collaboratore che «non riesce a mettere le foto»

Succede sempre, e non è un bug. Il Collaboratore ha solo tre permessi: leggere, scrivere i propri articoli, cancellarli. Non ha publish_posts, che è il permesso di «see and use the “publish” button when editing their post (otherwise they can only save drafts)» — senza quello, l’articolo può solo restare in bozza. E non ha upload_files, che dà accesso a Media e Media → Aggiungi nuovo: un Collaboratore non può caricare un’immagine.

Il Collaboratore è il ruolo giusto per chi scrive testi che qualcun altro rilegge e manda online. Se la stessa persona deve anche scegliere le immagini e pubblicare da sé, il ruolo è Autore.

Errori da evitare

Il ruolo predefinito per i nuovi utenti. Sta in Impostazioni → Generali e vale per chiunque si registri. Se è diverso da Sottoscrittore e la registrazione è aperta, stai assegnando permessi a sconosciuti. Controllalo.

L’account condiviso. Un solo utente «redazione» usato da tre persone significa che nessuna modifica è attribuibile a nessuno, e che la password è ormai in tre posti diversi. Un account per persona, sempre.

Il ruolo scelto sulla gerarchia invece che sul compito. La documentazione lo dice meglio di qualunque parafrasi: «One particular role should not be considered to be senior to another role. Rather, consider that roles define the user’s responsibilities within the site». Non stai dando un grado, stai descrivendo un lavoro.

Chiamare admin l’utente amministratore. Dalla guida ufficiale all’hardening di WordPress: «When creating an administrative account, avoid easily guessed terms such as admin or webmaster as usernames because they are typically subject to attacks first».

La verifica, dieci minuti in wp-admin

1. Apri Utenti e leggi tutta la lista, compresa la colonna del ruolo. Non solo la prima pagina.
2. Per ogni nome, rispondi a una domanda: questa persona lavora ancora con te? Se no, l’account va rimosso. WordPress ti chiede a chi riassegnare i suoi contenuti, così gli articoli non si perdono.
3. Conta gli Amministratori. Per un sito aziendale normale sono uno o due. Se sono cinque, quattro vanno declassati.
4. Per ciascuno degli altri: pubblica da sé? Allora Autore. Scrive e qualcuno rilegge? Collaboratore. Gestisce anche il lavoro degli altri? Editore. Deve installare plugin e cambiare le impostazioni? Solo allora Amministratore.
5. Controlla il ruolo predefinito in Impostazioni → Generali.
6. Sugli account che restano, attiva la verifica in due passaggi: la stessa guida la consiglia — «it’s a good idea to enable two-step authentication as an additional security measure».

Nessuno di questi passaggi richiede un tecnico. Richiede mezz’ora e la volontà di fare una domanda scomoda su ogni nome della lista.

Fonti: Roles and Capabilities e Hardening WordPress, documentazione ufficiale di WordPress.

Se la lista degli utenti del tuo sito è un mistero e preferisci che la guardi qualcuno insieme a te, scrivici: si sistema in una sessione.