WordPress e la gestione delle aree riservate

Quinta puntata di «Faccio cose, vedo gente», la serie sui plugin che scrivo per i clienti, e stavolta il protagonista è nato su un palco: WP Simple Access Control è il plugin per creare un’area riservata WordPress che ho usato come esempio al workshop del WordCamp Torino 2026, quando ho mostrato come farsi scrivere da un modello la specifica completa di un plugin prima di toccare una riga di codice.

Da quella demo è nata una prima versione che oggi lavora per tre miei clienti, alle prese con aree riservate semplici, di quelle in cui basta dire «questa pagina la vedono solo gli editor» senza installare un plugin di membership grande come un condominio. Per pubblicarla sono ripartito da zero, dal prompt, insieme a Claud.ia; strada facendo ci ho unito il controllo per singolo blocco di un mio plugin precedente, e adesso il codice è open source su GitHub, con gli screenshot, la documentazione e l’elenco delle trappole che abbiamo incontrato.

Dal workshop a tre clienti

Il plugin per l’area riservata WordPress è nato come esempio di meta-prompting: invece di scrivere io il prompt, l’ho fatto scrivere al modello, e da lì è finito nei progetti dei clienti.

Al workshop «Vibe Coding fatto bene» una delle parti che ha funzionato meglio è stata quella sul meta-prompting: dai al modello contesto, obiettivo e vincoli, e gli chiedi di produrre un prompt strutturato che userai in una sessione nuova per ottenere il risultato. Mi serviva un esempio concreto, abbastanza piccolo da spiegare in un workshop ma abbastanza serio da mostrare tutti i pezzi di un plugin vero, e un controllo degli accessi per ruolo era perfetto.

Il risultato è un documento di circa 470 righe, wp-simple-access-control-prompt.md, pensato come briefing iniziale per Claude Code, l’agente che scrive il codice: va letto per intero, si fanno le domande per chiarire i dubbi e poi si procede per passi, ognuno dei quali lascia qualcosa che funziona già. Oggi lo trovi su GitHub, accanto al codice che ne è uscito, ed è la prima cosa che ti consiglio di aprire, perché il metodo si riusa anche se l’area riservata WordPress non ti interessa affatto.

Dal palco il plugin è passato ai progetti dei clienti, perché una richiesta che ricevo spesso è proprio «mi fai una pagina che vedono solo alcuni». La prima versione è cresciuta così, un sito alla volta, ed è quella che tre clienti usano tuttora; quando ho deciso di pubblicarla ho preferito una riscrittura pulita, ripartendo dalla specifica invece che da un codice cresciuto a colpi di richieste.

Area riservata WordPress, senza membership

Un’area riservata WordPress semplice: proteggi singoli contenuti o singoli blocchi per ruolo, con un form di login dentro il tema e un registro di chi è entrato.

WordPress ha già la visibilità «privata» e la protezione con password, ma per un’area riservata WordPress non bastano: la prima vale solo per chi può modificare i contenuti e la seconda è una password condivisa, che dopo una settimana gira su WhatsApp. Dall’altra parte ci sono i plugin di membership, ottimi quando vendi abbonamenti e pesantissimi quando ti serve solo una cartella di documenti per i soci.

Nel lontano 2015 avevo raccontato la mia soluzione di allora, un template di pagina che controlla il login: funzionava, ma andava copiata in ogni tema e non sapeva niente di ruoli, registri o cache. WP Simple Access Control fa quello che allora mi mancava per un’area riservata WordPress fatta bene: protegge pagine, articoli e ogni tipo di contenuto pubblico per ruoli selezionabili, mostra il form di login dentro la grafica del sito, tiene un registro degli accessi nella bacheca, funziona anche sulle reti di siti (multisite) e arriva con la traduzione italiana completa.

L’area riservata WordPress si configura dal pannello Access control nella barra laterale dell’editor: un interruttore per attivare la protezione, le caselle dei ruoli e un messaggio da mostrare sopra il form di login. La regola che il prompt chiedeva di documentare è rimasta tale e quale: nessun ruolo selezionato significa «basta essere loggati, con qualsiasi ruolo», e gli amministratori entrano sempre.

Anatomia di un prompt di sviluppo

Tredici sezioni ordinate per priorità trasformano l’idea di un’area riservata WordPress in una specifica: contesto, vincoli, architettura, funzioni, criteri di accettazione e roadmap.

La struttura del prompt è la parte che riuso in quasi tutti i progetti, perché trasforma un’idea vaga in qualcosa che un agente può eseguire senza inventare. Le sezioni sono queste, nell’ordine:

• Identità del progetto: il nome del plugin e i prefissi che lo distinguono dagli altri dentro WordPress.
• Vincoli non negoziabili: le versioni minime di PHP e di WordPress, le regole di scrittura del codice e gli strumenti che le controllano in automatico.
• Struttura del progetto, cartella per cartella, e modello dei dati, cioè dove vengono salvate le regole e il registro.
• Specifica funzionale: che cosa deve fare il plugin, dal pannello nell’editor al form di login, dal registro degli accessi alla sicurezza.
• Una skill per Claude Code, cioè un promemoria con le regole del progetto che l’agente rilegge ogni volta che ci rimette le mani, più la documentazione.
• Criteri di accettazione per dire quando il lavoro è finito, una roadmap in dodici passi, le domande ancora aperte e le regole di stile.

Due dettagli fanno la differenza. Il primo è la lista delle cose escluse: niente test automatici in questa fase, ma un codice organizzato per poterli aggiungere dopo senza riscrivere tutto. Il secondo è la regola finale sulle ambiguità: se manca una risposta, l’agente deve scegliere la soluzione più conservativa, cioè quella che espone meno, protegge di più e segue le regole di WordPress. È la frase che più di tutte evita le sorprese.

## 1. Identità del progetto

Nome plugin: WP Simple Access Control
Slug / textdomain: wp-simple-access-control
Namespace PHP: WPSimpleAccessControl
Prefisso DB / opzioni / hook: wpsac_

Obiettivo in una frase: un plugin WordPress che consente di proteggere singoli contenuti
(page, post e qualsiasi CPT pubblico) [...]

Dal prompt al codice, passo per passo

La roadmap del prompt dell’area riservata WordPress è diventata la storia del progetto: una tappa alla volta, ognuna salvata e funzionante, con i criteri di accettazione come lista di controllo finale.

Ho passato il prompt a Claud.ia in una sessione nuova di Claude Code e l’ho lasciata lavorare un passo alla volta, come chiede la roadmap. Pensavo fosse un lavorone, invece la roadmap è filata via con una regolarità quasi noiosa: prima le fondamenta e il pannello nell’editor, poi il controllo degli accessi, il registro, le protezioni per le «porte di servizio», le pagine di amministrazione, il login con la verifica in due passaggi e le traduzioni.

Ogni passo è stato salvato con un messaggio che spiega il perché delle scelte e non solo il cosa, seguendo la convenzione dei Conventional Commits: rileggere la cronologia è come sfogliare un diario di bordo, e quando qualcosa si rompe so dove cercare. Alla roadmap originale si sono aggiunti il controllo per singolo blocco, che ti racconto più avanti, e gli screenshot della documentazione, catturati in automatico su un sito di prova.

I sedici criteri di accettazione del prompt, scritti come prove da fare a mano, sono diventati la lista di controllo per dire «finito»: la pagina riservata agli editor provata da un visitatore anonimo, da un utente semplice, da un editor e da un amministratore, il blocco dopo troppi tentativi di login sbagliati, il feed che mostra solo l’estratto, la disinstallazione che cancella i dati solo se lo chiedi e il codice che supera tutti i controlli automatici di qualità.

Il cancello: chi entra e chi no

Il cuore dell’area riservata WordPress è un controllo che scatta prima che la pagina venga mostrata: un solo punto del codice decide chi entra, e tutto il resto del plugin lo riusa.

Il prompt descriveva il cancello con uno pseudocodice, cioè una ricetta passo per passo scritta quasi in italiano, e il codice finale lo ricalca quasi riga per riga. Il controllo scatta quando WordPress ha capito quale pagina mostrare ma non l’ha ancora mostrata (per chi programma, sull’hook template_redirect con priorità 1): legge la regola del contenuto, chiede di non conservarne copie in cache e domanda il verdetto ad AccessPolicy, l’unico posto in cui vive la decisione di accesso. Pagine, feed, archivi e blocchi chiedono tutti a lui, e la skill vieta esplicitamente di duplicarlo.

Le regole dell’area riservata WordPress stanno in una tabella dedicata del database, una riga per ogni contenuto protetto, così l’elenco di tutto ciò che è riservato si ottiene in un colpo solo. Lungo la strada c’è stato anche un piccolo inciampo: con l’editor a blocchi le impostazioni del pannello arrivano un attimo dopo il salvataggio dell’articolo, e copiarle troppo presto voleva dire registrare la regola vecchia (per chi programma: wp_after_insert_post e non save_post).

Quando l’accesso è negato, la pagina risponde con il codice 403, il modo standard del web per dire «vietato l’ingresso», e al posto del contenuto mostra il form di login con la grafica del sito. Funziona sia con i temi classici sia con i nuovi temi a blocchi, che però hanno richiesto un trucco diverso. Chi sviluppa può personalizzare il form copiandone il modello nel tema e cambiarne i colori con poche righe di CSS.

Un blocco alla volta, per ruolo

Non sempre serve chiudere una pagina intera: in un’area riservata WordPress il controllo per singolo blocco nasconde una sezione e lascia pubblico il resto.

Ad aprile avevo scritto wp-access-control-block, un plugin che aggiunge a ogni blocco di Gutenberg un pannello per decidere chi lo vede. Era il fratello minore di questo progetto, e tenerli separati voleva dire due plugin da installare per lo stesso problema: l’ho integrato in WP Simple Access Control, così da avere tutto insieme, aggiungendo i ruoli e sistemando alcune cose della prima versione, come l’elemento in più che avvolgeva i blocchi nell’editor.

Ogni blocco ha tre modalità: visibile a tutti, solo agli utenti loggati (con i ruoli facoltativi, come per le pagine) oppure solo ai visitatori non loggati, comoda per un invito a registrarsi che chi è già dentro non deve vedere. Per proteggere una sezione intera basta metterla in un blocco Gruppo o Colonne e restringere quello; nell’editor i blocchi riservati hanno un’etichetta colorata, senza cambiare l’impaginazione.

Al posto del blocco nascosto si può lasciare un messaggio in testo semplice, e per il link di accesso basta scrivere [login]testo[/login]. Niente formattazione HTML, e il motivo è una delle trappole più cattive dello sviluppo: quando a scrivere è un utente con permessi ridotti, per esempio un autore, WordPress ripulisce per sicurezza il codice HTML, ma così facendo rovina anche le impostazioni nascoste del blocco, e il blocco riservato diventa pubblico, in silenzio. Per un controllo degli accessi è il fallimento peggiore possibile.

Altra cosa da sapere: quando WordPress crea da solo l’estratto di un articolo, cioè le prime righe che compaiono negli elenchi, salta i blocchi contenitore (Gruppo, Colonne, Elenco) e legge direttamente quello che c’è dentro. Il risultato era che un gruppo riservato finiva intero negli archivi, nella ricerca e nei feed.
Ora il plugin toglie i blocchi non visibili prima di calcolare l’estratto.

Login, tentativi e registro accessi

Nell’area riservata WordPress il form di login lavora dentro la pagina, con un tetto ai tentativi sbagliati e il ritorno alla pagina di partenza, e ogni visita a un contenuto protetto finisce nel registro degli accessi.

Il form di login si può mostrare in due modi: dentro la pagina, con la grafica del tema, oppure su una pagina a parte, essenziale e nascosta ai motori di ricerca. In entrambi i casi il plugin segue sempre lo stesso ordine: controlla che la richiesta arrivi davvero dal form, verifica che non ci siano stati troppi tentativi falliti, fa entrare l’utente con il login standard di WordPress (opzione «ricordami» compresa), scrive nel registro e lo riporta alla pagina da cui era partito, dopo aver controllato che l’indirizzo sia sicuro. Se la password è sbagliata, si torna semplicemente al form.

Con l’autenticazione a due fattori, quella che oltre alla password chiede un codice sul telefono, il plugin non fa il furbo: usa il login standard di WordPress, quindi i plugin che la gestiscono funzionano come sulla normale pagina di accesso e, dopo il codice, riportano l’utente alla pagina riservata. L’ho provato con Two Factor, che si mette in mezzo prima della fine del login: per questo il «login riuscito» si registra solo quando anche il codice è stato verificato, e non un attimo prima.

Il registro degli accessi sta nel menu Strumenti e raccoglie ogni visita a un contenuto protetto e ogni tentativo di login, con data, contenuto, utente, indirizzo IP, esito e browser usato. Si filtra, si ordina, si cancella in blocco e si esporta in CSV per aprirlo con Excel, ripulito da tutto quello che Excel potrebbe scambiare per una formula: sembra un dettaglio, ma è un trucco usato davvero per colpire chi apre il file. Se vuoi, una pulizia giornaliera elimina le righe più vecchie. I blocchi nascosti invece non finiscono nel registro, perché sarebbe una riga per blocco a ogni visita.

Le porte di servizio: REST, feed, cache

Un’area riservata WordPress che controlla solo la pagina lascia aperte tre porte di servizio: REST API, feed RSS e cache.

È la parte che distingue un’area riservata WordPress vera da una tenda. Oltre alle pagine che vedi nel browser, WordPress ha un ingresso pensato per i programmi e le app che leggono i contenuti in automatico, l’API REST: se proteggi la pagina ma non questo ingresso, il testo si legge comodamente da lì. Il plugin risponde «vietato» sul singolo contenuto e lo toglie dagli elenchi, lasciando passare solo chi ha il permesso di modificarlo, altrimenti un autore non riuscirebbe più ad aprire la propria pagina protetta nell’editor.

E qui arriva la scena migliore dello sviluppo. Con tutto già finito, un ultimo giro di verifiche ha scoperto che, chiedendo all’API un elenco che «include» proprio la pagina protetta, un visitatore anonimo riceveva il testo intero. Il colpevole è un dettaglio del modo in cui WordPress cerca i contenuti, che conoscono in pochi: se gli chiedi di includere e di escludere gli stessi articoli, guarda solo l’elenco da includere e ignora l’altro. Togliere i contenuti protetti solo dall’elenco degli esclusi, che è la cosa più naturale da fare, lasciava quindi la porta socchiusa: ora il plugin li toglie da entrambi (per chi programma: post__in vince su post__not_in).

Lo stesso vale per il feed RSS, l’elenco degli ultimi articoli che leggono le app di notizie: se il feed contiene il testo completo, la pagina riservata finisce intera nel lettore di chiunque, quindi il plugin mostra solo l’estratto con un link «Leggi tutto» che riporta al form (o solo titolo e link, se preferisci). Negli archivi i contenuti protetti restano visibili con l’estratto e una nota «Contenuto riservato», così chi visita sa che esistono, e chi sviluppa può nasconderli del tutto con un filtro (wpsac_hide_protected_in_loops).

L’ultima porta è la più subdola, la cache, cioè la copia delle pagine che il sito conserva per servirle più in fretta. Se la pagina riservata vista da un editor finisce in quella copia, il visitatore successivo vede quello che non dovrebbe. Per questo ogni contenuto protetto, e ogni pagina con blocchi riservati, chiede esplicitamente ai plugin di cache e al browser di non conservarne copie, sia quando compare il form sia quando l’accesso è concesso: resta solo da verificare che la cache del tuo hosting rispetti la richiesta.

Funziona, ma è «perfettibile»

Un’area riservata WordPress con qualche spigolo ancora da limare.

Ci sono alcune cose che per il momento non ho ancora sistemato, per scelta, e che è giusto tenere in considerazione se vuoi usarla in produzione per un cliente.

• La ricerca può rivelare che una parola esiste: WordPress cerca dentro il contenuto, quindi un visitatore può scoprire che una pagina protetta contiene un certo termine, anche senza leggerla.
• Gli elenchi «extra» non sono coperti: widget, page builder e blocchi che mostrano gli ultimi articoli fuori dall’elenco principale della pagina non passano dal filtro degli archivi, e lì serve un intervento di chi sviluppa il sito.
• Alcuni temi fatti in casa mostrano il testo degli articoli saltando i passaggi standard di WordPress, e così saltano anche i filtri di archivi e feed; la pagina protetta però resta protetta.
• Dietro servizi come Cloudflare (proxy o CDN) va attivata nelle impostazioni l’opzione che legge l’indirizzo vero dei visitatori, altrimenti sembrano arrivare tutti dallo stesso IP e il tetto ai tentativi li blocca tutti insieme.
• I blocchi «solo non loggati» spariscono per chiunque sia loggato, amministratori compresi: se non li vedi, non è un bug.

I test automatici in questa prima fase non ci sono, ma saranno pronti prima della prossima installazione.
Se nel frattempo decidi di usarlo per un’area riservata WordPress di un tuo cliente e trovi una porta che ho lasciato aperta, apri una segnalazione su GitHub e, se riesco, la sistemo.

Porta chiusa, ma con il campanello

Un’area riservata WordPress non deve essere complicata: deve chiudere tutte le porte, non solo quella principale.

Un buon prompt di sviluppo vale quanto un buon documento di analisi, e anzi lo è: vincoli, criteri e domande aperte servono a un agente esattamente come servono a un collega, e ripartire dalla specifica mi ha dato un codice più pulito di quello cresciuto un cliente alla volta. Allo stesso modo, un’area riservata WordPress seria si misura sulle porte di servizio, cioè REST, feed e cache, molto più che sul form di login.

Se vuoi provare questa area riservata WordPress, il repository di WP Simple Access Control ha la documentazione con gli screenshot e le istruzioni per provarlo, e il prompt del workshop è lì accanto, pronto da adattare a un plugin tuo.

Il racconto del workshop al WordCamp Torino 2026 ha le slide e il template di meta-prompting, e la guida pratica a Claude Code spiega come lavorare con un agente su un plugin vero.

Se il 14 novembre sei al WordCamp Pisa, passa al mio talk «Ideas are Cheap, Execution is Cheaper»: questo plugin ne è un buon esempio.

Nella serie trovi anche il plugin di prenotazioni che ha sostituito Calendly, i listini prezzi WooCommerce per i clienti B2B, il passaggio da WPBakery a Gutenberg e il multi magazzino WooCommerce.

Se invece ti serve un’area riservata su misura per i tuoi clienti o i tuoi soci, puoi prenotare una call conoscitiva.

Domande frequenti sull’area riservata