Immagina questa situazione: hai lanciato un portale aziendale su WordPress, hai creato un custom post type chiamato "Attrezzature" e lo hai popolato con la documentazione interna. Una settimana dopo scopri che tutte queste pagine sono indicizzate dai motori di ricerca e visibili a chiunque passi di lì. L'accesso dovrebbe essere limitato ai dipendenti autorizzati, ma il tuo è completamente aperto.

Gli strumenti integrati di WordPress non consentono di limitare selettivamente un custom post type specifico agli utenti non registrati. Ruoli e capacità esistono, ma il vincolo "gli ospiti non possono vedere il CPT X" non è disponibile di default. La soluzione si compone di tre elementi: registrazione del CPT, configurazione dei ruoli e un plugin per la restrizione della lettura. Il quarto componente (opzionale) è il social login, così i dipendenti non devono inserire una password ogni volta.

Di seguito trovi una descrizione dettagliata di ciascun componente, con plugin e impostazioni specifiche. Tutti gli strumenti sono gratuiti, disponibili nella directory ufficiale di WordPress.org e non richiedono codice, anche se alla fine viene illustrato un approccio puramente basato su codice per chi vuole evitare i plugin.

💡 Panoramica rapida:

• Registrare un custom post type con Custom Post Type UI senza scrivere una sola riga di codice
• Creare un ruolo personalizzato in PublishPress Capabilities e assegnarlo ai dipendenti
• Limitare l'accesso al CPT da parte degli ospiti usando il plugin WP Access Areas: i visitatori non autorizzati vengono reindirizzati alla pagina di login
• Opzionalmente, abilitare il social login tramite Super Socializer per un accesso senza password con account Google

Step 1: registrare un custom post type

La prima fase, la più semplice, è creare il CPT stesso. Non devi toccare functions.php per farlo: il plugin Custom Post Type UI su WordPress.org fornisce un'interfaccia grafica per registrare qualsiasi tipo di post e tassonomia.

L'installazione è standard: «Plugin → Aggiungi nuovo», cerca per nome, attiva. Dopo l'attivazione, compare una nuova voce di menu nella barra laterale: «CPT UI → Add/Edit Post Types». Compila i campi: slug (ad esempio, equipment), nomi al plurale e al singolare, etichette e clicca su «Add Post Type».

Il plugin chiama register_post_type() con i parametri corretti in automatico. Nessun codice manuale richiesto: ottieni un tipo di post perfettamente funzionante con supporto dell'editor, archivi e API REST. Se in seguito dovessi spostare la registrazione su functions.php, CPT UI mostra il codice PHP generato nella scheda «Tools».

Durante la registrazione, presta attenzione a due opzioni critiche legate alla sicurezza. Nel blocco «Settings» di CPT UI c'è un flag «Publicly Queryable» che determina se i post possono essere aperti tramite link diretti. L'impostazione predefinita è true e, anche dopo aver limitato la lettura tramite un plugin, dovresti lasciarlo abilitato; altrimenti WordPress restituirà un 404 invece di reindirizzare alla pagina di login e gli utenti non capiranno cosa è successo. Il secondo parametro, «Has Archive», abilita una pagina archivio che elenca tutti i post del CPT. Se non ti serve un archivio, disabilitalo in modo che i motori di ricerca non indicizzino una pagina di servizio con anteprime di documenti riservati.

Step 2: creare un ruolo personalizzato

Limitarsi a revocare l’accesso ai CPT agli ospiti non basta: serve un ruolo che abbia effettivamente accesso. Di default WordPress mette a disposizione un insieme fisso: Amministratore, Editor, Autore, Collaboratore, Sottoscrittore. Creeremo un nuovo ruolo usando il plugin PublishPress Capabilities (in passato chiamato Capability Manager Enhanced, stesso slug, stesse funzionalità, solo un cambio di nome).

Dopo l’attivazione, vai su «Capabilities → Roles». Sul lato destro della schermata trovi il blocco «Create New Role»:

Inserisci un nome (ad esempio «Equipment Reader»), seleziona un ruolo base da cui clonare (Sottoscrittore è la scelta migliore, perché ha permessi minimi) e clicca su «Create». Il nuovo ruolo ora esiste e puoi popolarlo con le capability. Per leggere un CPT bastano la combinazione standard read + read_equipment (la capability registrata da CPT UI).

Assegna il ruolo creato ai dipendenti che devono accedere ai contenuti riservati. Fatto questo puoi disattivare il plugin: ruoli e capability restano nel database di WordPress e non dipendono dalla presenza attiva di PublishPress Capabilities.

Step 3: limitare l’accesso in lettura al CPT

Questo è il passaggio chiave. Il plugin WP Access Areas permette di definire con precisione chi può leggere, modificare e commentare i post di ciascun tipo, fino al livello di singola pagina. Ha un parco installazioni attive modesto (400) e non riceve aggiornamenti importanti da un po’, ma per il compito di «impedire l’accesso ai CPT agli ospiti» funziona in modo prevedibile e senza conflitti.

Dopo l’installazione, vai su «Settings → Access Areas». Nella sezione «Default Behaviour», seleziona:

«If not logged in, redirect to login. Otherwise redirect to the fallback page.»

Questa impostazione reindirizza gli utenti non autorizzati a wp-login.php quando provano ad aprire una qualsiasi pagina protetta del CPT.

Subito sotto trovi una tabella con tutti i tipi di post registrati. Per il tuo CPT, nella colonna «Reading», seleziona dal menu a tendina «Logged in Users». Tutto qui: da questo momento qualsiasi ospite che segua un link diretto a una pagina del CPT viene reindirizzato al form di autenticazione.

Nota importante: le impostazioni applicate tramite la tabella valgono solo per i nuovi post. Per le pagine già create devi impostare manualmente i permessi nella sidebar dell’editor, dove compare un blocco «Access Areas». Dopo la configurazione ricordati di verificare il risultato in modalità incognito del browser: aprendo un link diretto a una pagina protetta del CPT devi vedere wp-login.php, non il contenuto.

Alternative a WP Access Areas se serve una soluzione con manutenzione più attiva: PublishPress Permissions (la versione gratuita copre CPT e ruoli) oppure ContentGate (un plugin leggero con regole basate su stato di login e ruoli).

Step 4: Login social (opzionale)

Inserire ogni volta nome utente e password su un portale aziendale crea un attrito inutile. La soluzione logica: login con un clic tramite account Google. Il plugin Super Socializer gestisce questa funzione con oltre 20.000 installazioni attive e supporto per Google, Facebook, X (Twitter) e una dozzina di altri provider.

Dopo l'attivazione, vai in «Super Socializer → Social Login»:

Impostazioni di base: attiva la casella «Disable user registration via social networks». È importante perché così solo gli account già esistenti possono accedere tramite social network, senza crearne di nuovi. Poi seleziona il provider (Google) e inserisci Client ID e Client Secret. Dove recuperarli:

• Apri Google Cloud Console, crea un progetto (o selezionane uno esistente)
• Nella sezione «APIs & Services → Credentials», clicca «Create Credentials → OAuth client ID»
• Tipo applicazione: Web application; in Authorized redirect URIs incolla l'URL di callback dalle impostazioni di Super Socializer
• Salva per ottenere Client ID e Client Secret

Copia le chiavi nei campi del plugin:

Punto critico: il campo Authorized redirect URIs non deve avere una barra finale, altrimenti otterrai un errore redirect_uri_mismatch. Dopo il salvataggio, nella pagina di login compare il pulsante «Sign in with Google».

Importante: la versione originale di questo articolo (2020) descriveva l'integrazione con Google+, chiuso ad aprile 2019. Super Socializer oggi utilizza il protocollo standard Google OAuth 2.0 tramite Google Identity Services. L'interfaccia di Google Cloud Console è stata aggiornata nel frattempo, ma la logica dei passaggi (progetto → Credentials → OAuth client ID → redirect URI) resta la stessa.

Approccio alternativo: tutto via codice

Se plugin aggiuntivi non sono desiderabili, il compito si può risolvere nel functions.php del tema o in un child theme. Il codice registra il CPT, crea un ruolo e aggancia un controllo di autorizzazione al template:

1
// Registering a custom post type
2
function register_equipment_cpt() {
3
    register_post_type('equipment', [
4
        'labels'      => ['name' => 'Equipment', 'singular_name' => 'Equipment'],
5
        'public'      => true,
6
        'has_archive' => true,
7
        'supports'    => ['title', 'editor', 'thumbnail'],
8
        'capability_type' => 'equipment',
9
        'map_meta_cap' => true,
10
    ]);
11
}
12
add_action('init', 'register_equipment_cpt');
13
 
14
// Creating a role on theme activation
15
function add_equipment_reader_role() {
16
    add_role('equipment_reader', 'Equipment Reader', ['read' => true, 'read_equipment' => true]);
17
}
18
add_action('after_switch_theme', 'add_equipment_reader_role');
19
 
20
// Redirecting guests from CPT to login page
21
function restrict_equipment_to_logged_in() {
22
    if (is_singular('equipment') && !is_user_logged_in()) {
23
        wp_redirect(wp_login_url(get_permalink()));
24
        exit;
25
    }
26
}
27
add_action('template_redirect', 'restrict_equipment_to_logged_in');

Cosa fa questo codice: il primo blocco registra il CPT equipment con un proprio capability type (capability_type). Il secondo blocco crea il ruolo Equipment Reader con i permessi per leggere questo CPT all'attivazione del tema. Il terzo blocco verifica l'autorizzazione sull'hook template_redirect e reindirizza i visitatori non autenticati a wp-login.php.

Il vantaggio dell'approccio via codice: zero plugin aggiuntivi, controllo totale. Lo svantaggio: il social login richiederà comunque un plugin (scrivere un'integrazione OAuth a mano è dispendioso in termini di tempo e insicuro), e ogni modifica ai ruoli comporta la modifica del codice.

⁉️🤔 Domande frequenti

Posso restringere un CPT senza plugin, solo tramite functions.php?

Sì. La combinazione di register_post_type() + add_role() + l'hook template_redirect con un controllo is_user_logged_in() è una soluzione pienamente funzionante. Il codice è fornito nella sezione precedente. Il social login senza plugin è significativamente più complesso da realizzare: un'integrazione OAuth manuale richiede la gestione di token, stato e sicurezza.

Perché WP Access Areas invece di un plugin più recente come ContentGate?

WP Access Areas è uno strumento minimalista per un compito specifico: «restringere un tipo di contenuto ai visitatori non autenticati». Non porta con sé un rule builder, editor visuali o abbonamenti. Se serve una logica più complessa (per esempio, livelli di accesso diversi per ruoli diversi sullo stesso CPT), usa ContentGate o PublishPress Permissions, che sono aggiornati attivamente. Per lo scenario base di questa guida, WP Access Areas è sufficiente.

Cosa devo fare se i visitatori non autenticati vedono ancora le pagine del CPT dopo la configurazione?

Tre cause tipiche. Prima: l'impostazione «Logged in Users» nella tabella di WP Access Areas si applica solo ai nuovi contenuti; per le pagine esistenti, devi impostare i permessi manualmente tramite la sidebar dell'editor. Seconda: un plugin di caching sta servendo una versione cache della pagina ai visitatori non autenticati; svuota la cache e configura le esclusioni per il CPT protetto. Terza: il CPT è registrato con 'publicly_queryable' => true e lo slug è in conflitto con una pagina pubblica; verifica eventuali collisioni.

Posso usare Super Socializer solo per il login, senza condivisione e commenti?

Sì, i moduli del plugin sono indipendenti. Nella scheda «Social Sharing», deseleziona tutte le caselle e i pulsanti «Share» spariranno. Nella scheda «Social Commenting», disabilita l'integrazione. Lascia attivo solo «Social Login» con i provider che ti servono. Il plugin è leggero e disabilitare i moduli superflui non incide sulle performance.

È sicuro disattivare PublishPress Capabilities dopo aver creato un ruolo?

Sì. I ruoli e le capacità di WordPress sono memorizzati nella tabella wp_options (l'opzione wp_user_roles) e non dipendono dal plugin che li ha creati. Dopo aver disattivato PublishPress Capabilities, tutti i ruoli creati e i permessi concessi vengono conservati. Puoi riattivare il plugin in un secondo momento se devi modificare i permessi.

Scrivere codice o restare sui plugin

La scelta tra plugin e functions.php si riduce a due fattori: il numero di CPT da proteggere e la frequenza con cui cambiano i permessi.

Se hai un solo CPT (come nell'esempio dell'attrezzatura), i ruoli sono stabili e sei disposto a scrivere 30 righe di codice una tantum, l'approccio functions.php è più pulito: non genera plugin, non dipende da aggiornamenti di terze parti ed è completamente trasparente. Puoi tenere Super Socializer per il social login, dato che risolve un compito circoscritto e non entra in conflitto con il codice personalizzato.

Se hai più CPT, i permessi vengono rivisti di frequente o il sito è gestito da una persona non sviluppatrice, scegli la combinazione di plugin. CPT UI + PublishPress Capabilities + WP Access Areas (o ContentGate) si configurano dal pannello di amministrazione in 15 minuti senza toccare codice. Inoltre, PublishPress Capabilities esegue automaticamente il backup dei ruoli a ogni modifica, consentendo il rollback in due clic.

In ogni scenario, segui il principio: uno strumento per un compito. Non installare una potente soluzione all-in-one per una singola casella di spunta, e non reinventare la ruota se un plugin esistente fa esattamente la stessa cosa in modo più rapido e sicuro.

Il version control merita una considerazione a parte. Il codice nel functions.php risiede nel repository del tema, le modifiche sono tracciate tramite Git e, durante la migrazione del sito, i ruoli vengono ricreati automaticamente sull'hook after_switch_theme. L'approccio con i plugin non offre questa trasparenza: i ruoli sono memorizzati nel database e, quando si distribuisce una copia di staging o si trasferisce il sito su un nuovo dominio, devono essere ricreati manualmente o tramite uno script di migrazione. Questo fattore diventa spesso decisivo a favore del codice per i team che praticano CI/CD e il deployment basato su Git.