Advanced Custom Fields (ACF): cos’è, come funziona e come usarlo su WordPress

Se hai mai provato a trasformare WordPress da semplice sistema per pubblicare pagine e articoli in un CMS capace di gestire dati strutturati, prima o poi incontri Advanced Custom Fields.

Conosciuto soprattutto come ACF, questo plugin permette di aggiungere campi personalizzati alle schermate di modifica di WordPress e di controllare con precisione dove devono comparire, quali dati devono accettare e come recuperarli nel frontend.

La differenza rispetto ai custom field nativi di WordPress non è tanto nel sistema usato per archiviare i dati. Il vero vantaggio è il livello di gestione costruito sopra i metadati di WordPress: gruppi di campi, tipi di dato, regole di posizione, validazione, logica condizionale, API e strumenti per integrare queste informazioni in temi, blocchi, page builder e applicazioni headless.

Questo cambia anche il modo corretto di pensare al plugin. Non serve semplicemente ad aggiungere una casella di testo in più nell’editor. Serve a progettare un modello di contenuto.

Se, per esempio, stai creando un portfolio, puoi avere un custom post type “Progetti” e campi separati per cliente, settore, URL, anno del progetto, gallery, tecnologie utilizzate e risultati. L’editor compila informazioni strutturate; il template decide come mostrarle.

In questa guida vediamo come funziona Advanced Custom Fields, cosa puoi fare con la versione gratuita e con quella PRO, come creare e visualizzare i campi, come integrarli con Gutenberg, REST API e workflow di sviluppo e, soprattutto, come evitare di costruire un sistema che dopo qualche mese diventa difficile da mantenere.

Cos’è Advanced Custom Fields e perché cambia il modo di gestire i contenuti WordPress

Advanced Custom Fields è un plugin WordPress dedicato alla creazione e gestione di campi personalizzati. La versione stabile verificata durante questa revisione editoriale è la 6.8.7 e il software è disponibile nella directory ufficiale WordPress.

Per capire perché è utile devi però separare due livelli.

Il primo è il contenuto: titolo, testo, immagini, categorie, autore e gli altri dati che normalmente gestisci con WordPress.

Il secondo è la struttura del contenuto. Un immobile ha un prezzo e una superficie. Un membro del team ha un ruolo e una fotografia. Un corso ha una durata e un livello. Un progetto ha un cliente, un settore e magari un URL esterno.

Puoi inserire queste informazioni direttamente dentro il corpo della pagina, ma in quel caso stai mescolando dato e presentazione. Se invece ogni informazione ha un campo dedicato, il dato rimane strutturato e può essere riutilizzato in template, filtri, API, blocchi e layout differenti.

È in questo secondo livello che il plugin diventa realmente interessante.

Custom field, Field Group e Location Rule: il modello mentale da capire

Tre concetti sono sufficienti per comprenderne l’architettura di base.

Un field, o campo, rappresenta una singola informazione: per esempio “Cliente”, “URL progetto”, “Data evento” oppure “Immagine principale”.

Un Field Group raccoglie più campi che appartengono allo stesso contesto. Potresti creare un gruppo “Dati progetto” contenente:

• cliente;
• settore;
• URL;
• immagine;
• tecnologie;
• descrizione breve.

Le Location Rules stabiliscono dove quel gruppo deve apparire. Per esempio:

Post Type → is equal to → Progetto

In questo modo i campi “Dati progetto” vengono visualizzati solo quando qualcuno modifica un contenuto del tipo Progetto.

Puoi inoltre applicare la Conditional Logic, cioè mostrare o nascondere determinati campi in funzione del valore di altri. La documentazione ufficiale sulla Conditional Logic distingue chiaramente questa funzione dalle Location Rules: la prima governa i singoli campi all’interno del gruppo, le seconde decidono su quali schermate compare l’intero Field Group.

Questa distinzione permette di modellare l’interfaccia editoriale invece di accumulare decine di input sempre visibili.

Immagina un campo “Tipo di progetto” con due valori: “Sito web” ed “Ecommerce”. Puoi fare in modo che “Numero prodotti” compaia soltanto se l’utente seleziona Ecommerce.

Il risultato è un’interfaccia più chiara e, soprattutto, un modello dati che riflette la realtà del contenuto.

Quando serve davvero e quando i campi personalizzati sono superflui

Questo approccio ha senso quando un’informazione possiede una struttura propria e ripetibile.

Se cliente, superficie, durata o prezzo devono essere riutilizzati in punti differenti del sito, ordinati, interrogati o passati a un frontend, è logico separarli dal testo libero.

È molto meno utile creare un campo per ogni pezzo di una normale pagina solo perché tecnicamente è possibile.

Prendi un titolo introduttivo che compare una sola volta in una pagina. Se può essere gestito comodamente con un normale blocco Heading, trasformarlo in un dato separato potrebbe soltanto aggiungere complessità.

La domanda corretta non è quindi:

“Posso creare questo dato con un campo personalizzato?”

ma:

“Questo dato deve avere una struttura indipendente dalla sua presentazione?”

Se la risposta è sì, sei probabilmente davanti a un buon candidato.

Cosa puoi costruire con ACF

Il caso d’uso più semplice è aggiungere qualche metadato a un articolo. Lo stesso sistema, però, può diventare la base di architetture editoriali molto più strutturate.

Puoi usarlo per portfolio, directory, cataloghi, siti immobiliari, corsi, eventi, schede professionisti, sezioni aziendali, documentazione, landing dinamiche e molti altri progetti in cui il contenuto non è soltanto un blocco di testo.

Il vantaggio principale è sempre lo stesso: l’autore inserisce il dato senza preoccuparsi di come verrà rappresentato.

Campi strutturati per articoli, pagine, utenti, tassonomie e media

I campi non sono limitati ai post.

Un Field Group può essere associato, a seconda del contesto, a pagine, custom post type, utenti, termini di tassonomia, allegati e altre schermate amministrative.

Questo permette di costruire relazioni interessanti.

Un termine della tassonomia “Servizi”, per esempio, può avere:

• un’icona;
• una descrizione breve;
• un colore;
• un’immagine;
• un ordine di visualizzazione.

Un profilo utente può invece avere:

• ruolo professionale;
• telefono;
• foto;
• link social;
• biografia sintetica.

Invece di codificare queste informazioni dentro un template o inserirle manualmente ogni volta, il dato entra nel normale workflow editoriale.

Custom post type e tassonomie direttamente dal plugin

Dalla linea 6.1 è possibile registrare Custom Post Type e custom taxonomy direttamente dall’interfaccia. La documentazione ufficiale su post type e tassonomie permette quindi di gestire nello stesso ambiente sia la struttura principale del contenuto sia i relativi campi personalizzati.

Torniamo al nostro esempio.

Potresti creare:

Custom Post Type → Progetti

poi:

Field Group → Dati progetto

e collegare il gruppo a:

Post Type = Progetto

Se ti serve classificare i lavori puoi aggiungere anche una tassonomia:

Settori

A questo punto WordPress non è più una raccolta di pagine indipendenti. Hai una vera entità editoriale “Progetto”, con attributi e classificazioni proprie.

Questo è content modeling: prima definisci quali entità esistono e quali informazioni le descrivono; soltanto dopo decidi come presentarle.

Dal semplice dato aggiuntivo a un vero modello di contenuto

Qui si vede anche uno degli errori più frequenti: cominciare dal layout.

Supponiamo che una pagina debba mostrare:

Cliente
Acme Srl

Settore
Ecommerce

Sito
example.com

Se parti dalla grafica potresti creare tre campi perché hai visto tre righe nel mockup.

Ma il modello dati dovrebbe nascere dal significato delle informazioni, non dalla loro posizione nel layout.

Il cliente potrebbe un giorno essere mostrato nella pagina singola, nell’archivio dei progetti e in un filtro. Il settore potrebbe diventare una tassonomia invece di un Text Field. L’URL potrebbe richiedere un campo URL e non un semplice input testuale.

Prima definisci l’informazione. Poi scegli il tipo di campo. Alla fine costruisci l’interfaccia.

È una piccola inversione di ordine che evita moltissimi problemi quando il progetto cresce.

ACF Free e ACF PRO: quali sono le differenze che contano davvero

La versione gratuita è già sufficiente per molti siti WordPress.

ACF PRO aggiunge invece field type e strumenti particolarmente utili quando il contenuto presenta strutture ripetibili, layout modulari, gallery, impostazioni globali o blocchi Gutenberg personalizzati.

Il punto non è quindi chiedersi quale versione sia “migliore”. Devi capire se una funzione PRO risolve realmente un problema del tuo modello dati.

Cosa puoi fare con la versione gratuita

Con l’edizione Free puoi già creare Field Group, utilizzare numerosi tipi di campo, configurare regole di posizione e Conditional Logic, gestire custom post type e tassonomie e recuperare i valori nei template.

Per un progetto come:

• portfolio aziendale;
• directory semplice;
• schede team;
• casi studio;
• articoli con metadati aggiuntivi;

la versione gratuita può essere sufficiente.

Se ogni Progetto possiede Cliente, Settore, URL e Immagine, non hai automaticamente bisogno della licenza PRO.

La differenza emerge quando i dati diventano ripetibili oppure il sistema editoriale richiede componenti più complessi.

Repeater, Flexible Content, Gallery, Clone, Options Pages e Blocks

Le funzioni più riconoscibili di ACF PRO comprendono Repeater, Flexible Content, Gallery e Clone, oltre a Options Pages e ACF Blocks. L’elenco corrente è disponibile nella pagina ufficiale della versione PRO.

Il Repeater Field serve quando hai una struttura di sottocampi che può ripetersi.

Per esempio:

Membro team → Nome + Ruolo + Foto

Non sai in anticipo quanti membri verranno inseriti. Il Repeater permette di aggiungere righe mantenendo la stessa struttura.

Flexible Content porta il concetto oltre. Puoi definire diversi layout, ciascuno con i propri sottocampi, e consentire all’editor di combinarli.

È potente, ma richiede disciplina. Se crei decine di layout che duplicano tutto ciò che Gutenberg potrebbe già gestire, rischi di costruire un secondo page builder dentro WordPress.

Il Gallery Field gestisce collezioni di immagini, mentre Clone consente di riutilizzare campi o gruppi esistenti senza ricrearli.

Le Options Pages sono invece utili per dati globali, cioè informazioni che non appartengono a un singolo post: telefono aziendale, link social, impostazioni di un header personalizzato o elementi condivisi del tema.

I blocchi personalizzati meritano una sezione a parte perché non sono semplicemente un altro tipo di campo: costituiscono un framework per creare componenti Gutenberg utilizzando il sistema di editing del plugin.

Licenze PRO e quando vale la pena pagare

Al momento della verifica editoriale il listino ufficiale indica tre licenze annuali:

Piano	Siti	Prezzo
Personal	1	49 $/anno
Freelancer	10	149 $/anno
Agency	illimitati	249 $/anno

La versione PRO è un plugin standalone: non è necessario mantenere installata anche quella gratuita. Prezzi e condizioni possono cambiare, quindi prima di un acquisto conviene sempre controllare il listino ufficiale.

Quando vale la pena passare a PRO?

Se ti serve un Repeater una tantum, il costo rimane una decisione economica. Se invece Repeater, Options Pages o blocchi personalizzati sono componenti centrali dell’architettura del sito, la licenza diventa parte dello stack di sviluppo.

Non acquistare però la versione a pagamento solo perché il progetto è “professionale”. La soluzione corretta è quella che contiene le funzioni realmente necessarie.

Come usare ACF: creare il primo gruppo di campi passo dopo passo

Vediamo adesso un workflow completo usando un esempio concreto.

Immaginiamo di avere un custom post type chiamato progetto e di voler aggiungere:

• cliente;
• settore;
• URL progetto;
• immagine principale;
• descrizione sintetica.

L’obiettivo non è soltanto creare cinque campi. È costruirli in modo che rimangano comprensibili anche tra un anno, quando un altro sviluppatore o un editor dovrà modificare il sito.

Progettare i dati prima di creare i campi

Prima di aprire il Field Builder scrivi la struttura.

Per esempio:

Informazione	Tipo logico	Tipo di campo
Cliente	testo breve	Text
Settore	classificazione	Taxonomy oppure Select
URL progetto	URL	URL
Immagine	media	Image
Descrizione	testo con formattazione	WYSIWYG o Text Area

Nota il caso “Settore”.

Potresti usare un Select con valori fissi. Ma se il settore serve anche a filtrare e organizzare più progetti, probabilmente una tassonomia è un modello migliore.

Questo dimostra perché scegliere il Field Type non è un passaggio puramente grafico.

Creare il Field Group e scegliere i tipi di campo

Dopo aver installato e attivato il plugin vai in:

ACF → Field Groups → Add New

Crea un gruppo chiamato, per esempio:

Dati progetto

La guida ufficiale ai Field Group mostra come aggiungere più campi allo stesso gruppo e controllare validazione, presentazione, Conditional Logic e Location Rules dalla stessa schermata.

Aggiungi il primo campo:

Field Label: Cliente
Field Name: cliente
Field Type: Text

Poi aggiungi gli altri seguendo il modello definito prima.

Il Field Label è ciò che vede l’editor.

Il Field Name è invece il riferimento che utilizzerai nel codice. Conviene trattarlo come parte della tua API interna: breve, descrittivo e stabile.

Cambiare una label da “Cliente” a “Azienda” è normalmente una modifica editoriale.

Cambiare arbitrariamente il Field Name utilizzato in template e integrazioni può invece richiedere interventi sul codice e sui dati esistenti.

Nome, field name, valore restituito e validazione

Uno stesso dato può essere restituito in forme differenti.

Un Image Field, per esempio, può essere configurato per restituire un ID, un array oppure un URL. Un Relationship Field restituisce una struttura diversa da un Text Field.

Questa impostazione incide direttamente sul codice che dovrai scrivere.

Per questo conviene decidere il Return Format pensando al punto in cui userai il valore.

Se vuoi sfruttare le funzioni native WordPress per generare un’immagine responsive, avere l’attachment ID è spesso più utile di memorizzare soltanto un URL.

La validazione è altrettanto importante.

Se un dato è indispensabile al template, puoi marcarlo come Required. Ma non abusare dei campi obbligatori: un editor potrebbe dover salvare una bozza incompleta.

Il modello deve proteggere l’integrità dei dati senza rendere inutilmente frustrante il workflow editoriale.

Location Rules e Conditional Logic

Terminati i campi devi dire al sistema dove devono essere visualizzati.

Per il nostro esempio:

Post Type → is equal to → Progetto

Questa è una Location Rule.

Se invece hai un campo:

Progetto online? → Sì / No

puoi mostrare URL progetto soltanto quando la risposta è Sì.

Questa è Conditional Logic.

Le due funzioni risolvono problemi differenti:

Location Rules → dove appare il gruppo.
Conditional Logic → quando appare un campo dentro quel gruppo.

Mantenere questa distinzione rende la configurazione molto più facile da leggere.

Inserire e modificare i valori nell’editor WordPress

Dopo aver salvato il Field Group apri un contenuto che soddisfa le Location Rules.

Troverai i nuovi campi nella schermata di modifica.

Inserisci, per esempio:

Cliente → Rossi Srl

URL progetto → https://example.com/

e salva il post.

A questo punto hai memorizzato i dati, ma non significa che siano automaticamente visibili sul sito.

Ed è qui che spesso nasce la prima confusione.

Creare un campo e visualizzare un campo sono due operazioni separate.

Il plugin gestisce struttura e inserimento del dato. Il tema, il blocco, il page builder o il frontend devono decidere come utilizzarlo.

Come visualizzare i campi ACF nel frontend

Se utilizzi un tema personalizzato, il metodo classico consiste nel recuperare il valore tramite le funzioni messe a disposizione dal plugin e generare il markup necessario.

Le due che incontrerai più spesso sono get_field() e the_field().

get_field() e the_field(): differenza e casi d’uso

get_field() restituisce il valore.

$cliente = get_field( 'cliente' );

Puoi quindi controllarlo, modificarlo o usarlo in una condizione.

the_field() invece produce direttamente l’output:

the_field( 'cliente' );

Per un template reale preferisco normalmente get_field() perché offre maggiore controllo.

Per esempio:

$cliente = get_field( 'cliente' );

if ( $cliente ) {
    echo '<p class="project-client">';
    echo esc_html( $cliente );
    echo '</p>';
}

La documentazione di get_field() espone inoltre parametri per controllare la formattazione e la restituzione di una versione HTML-safe del valore.

Il vantaggio non è soltanto stilistico: hai separato lettura del dato, verifica e output.

Controllare il valore prima di generare l’HTML

Evita di stampare markup vuoto.

Questo codice:

<p class="project-client">
    <?php the_field( 'cliente' ); ?>
</p>

potrebbe generare un <p> senza contenuto quando il campo non è valorizzato.

È spesso più pulito verificare prima:

$cliente = get_field( 'cliente' );

if ( ! empty( $cliente ) ) {
    printf(
        '<p class="project-client">%s</p>',
        esc_html( $cliente )
    );
}

Lo stesso principio diventa ancora più importante con campi complessi.

Se una sezione dipende dalla presenza di una gallery, di un link o di una relazione con altri post, controlla il dato prima di costruire tutto il componente.

Escape e output: perché il tipo di campo cambia il codice

Un campo non va “escapato” sempre con la stessa funzione.

Un testo semplice può essere trattato con:

esc_html()

un URL con:

esc_url()

un attributo HTML con:

esc_attr()

mentre contenuti in cui vuoi consentire un insieme sicuro di markup richiedono un approccio differente, per esempio wp_kses_post() quando appropriato.

Dalla versione 6.2.7 the_field() e the_sub_field() applicano automaticamente l’escaping dell’HTML potenzialmente non sicuro, mentre get_field() non deve essere interpretato come sostituto delle funzioni di escaping contestuale di WordPress. La documentazione sulla sicurezza dell’output chiarisce questa distinzione.

Il principio resta semplice:

prima capisci quale dato stai stampando e in quale contesto HTML, poi scegli l’escaping corretto.

Non usare un’unica funzione come formula universale.

Page builder, Dynamic Tags e block theme

Non devi necessariamente modificare un template PHP per utilizzare i dati personalizzati.

Diversi page builder possono leggerli dinamicamente. È uno dei motivi per cui questa soluzione viene spesso utilizzata insieme a strumenti come Elementor o Oxygen Builder.

In questo workflow il sistema dei campi continua a svolgere la stessa funzione:

contenuto strutturato → dato

mentre il page builder si occupa di:

dato → presentazione

È una separazione utile.

Puoi cambiare un template senza riscrivere i dati e puoi modificare i contenuti senza permettere all’editor di intervenire sulla struttura visuale.

Anche i block theme stanno rendendo sempre più naturale il collegamento tra dati dinamici e blocchi, soprattutto attraverso la Block Bindings API di WordPress.

Perché lo shortcode non è più la scorciatoia da consigliare per default

Per anni una soluzione molto semplice è stata:

[acf field="cliente"]

Oggi non la considererei la scelta predefinita.

Dalla versione 6.3 lo shortcode è disabilitato per default nelle nuove installazioni e la documentazione ufficiale raccomanda di lasciarlo disabilitato se non viene utilizzato.

Il motivo è anche di sicurezza: quando abilitato può rendere accessibili campi a utenti che possono pubblicare contenuti e conoscono field name o field key.

Questo non significa che gli shortcode siano improvvisamente “sbagliati”.

Significa che non dovresti abilitarne uno così potente soltanto per evitare di configurare correttamente template, Dynamic Tags o blocchi.

ACF con Gutenberg e Blocks

Gutenberg e i campi personalizzati non sono due sistemi necessariamente alternativi.

Il Block Editor gestisce componenti e contenuto visuale. Il secondo livello gestisce dati strutturati. Le due cose possono convivere e, nelle versioni più recenti, stanno diventando sempre più integrate.

I campi personalizzati non sostituiscono l’editor a blocchi

Un errore architetturale comune è utilizzare Flexible Content per ricostruire un intero page builder mentre il sito dispone già di Gutenberg.

Tecnicamente puoi farlo.

Ma la domanda è se serva davvero.

Se una pagina è composta da titoli, paragrafi, immagini e call to action editoriali, i blocchi core possono già essere il modello corretto.

Se invece devi gestire una scheda tecnica con:

Prezzo → Superficie → Classe → Località

i dati strutturati continuano ad avere senso.

La soluzione migliore spesso è ibrida:

blocchi per il contenuto libero; campi dedicati per i dati che devono mantenere una struttura.

Quando ACF Blocks diventa utile

ACF Blocks è una funzione PRO che permette di creare blocchi personalizzati utilizzando un workflow fortemente orientato a PHP e ai custom field, senza richiedere necessariamente lo stesso livello di sviluppo JavaScript/React di un blocco completamente custom.

La documentazione ufficiale dei Blocks li presenta come un framework PHP per costruire blocchi dinamici integrati con il sistema dei campi.

Immagina un blocco “Testimonianza” con:

• nome;
• ruolo;
• azienda;
• fotografia;
• citazione.

L’editor aggiunge il blocco e modifica questi valori. Il render template controlla l’HTML.

Qui il plugin non viene utilizzato per sostituire Gutenberg. Viene usato per definire l’interfaccia dati di un blocco specifico.

Blocks V3 ha inoltre modificato il workflow di editing: il blocco mantiene la preview e i relativi campi vengono gestiti nella sidebar o in un pannello esteso. La documentazione di Blocks V3 descrive anche il percorso di migrazione dai blocchi precedenti.

Datastore e Block Bindings: dove sta andando l’integrazione con l’editor

La versione PRO 6.8.1 ha introdotto un nuovo datastore wp.data opt-in per integrare più profondamente i valori personalizzati nel flusso nativo del Block Editor.

Quando viene abilitato, il salvataggio dei campi può passare attraverso il flusso REST dell’editor e supportare revisioni e autosave. La stessa integrazione permette di collegare alcuni blocchi nativi ai dati tramite Block Bindings e ottenere aggiornamenti più immediati nell’editor.

La documentazione della release 6.8.1 descrive questa evoluzione, mentre la Block Bindings API di WordPress spiega il meccanismo utilizzato per collegare sorgenti dinamiche agli attributi dei blocchi.

Questa direzione è interessante perché riduce la distanza storica fra “metabox sotto l’editor” e “contenuto dinamico dentro l’esperienza a blocchi”.

Non significa però che ogni progetto debba attivare immediatamente queste funzioni. Datastore e integrazioni avanzate vanno valutati rispetto alla versione di WordPress, al tema e al workflow reale del sito.

Custom Post Type, REST API e WordPress headless

Quando i campi vengono utilizzati come vero modello dati, è naturale che quelle informazioni debbano uscire dalla normale pagina HTML.

Può accadere con una web app, un frontend JavaScript, un’app mobile o un’architettura WordPress headless.

In questi scenari il plugin non serve più soltanto a rendere ordinato il back-end. Diventa parte del contratto dati fra WordPress e il sistema che consuma le informazioni.

Creare CPT e tassonomie senza un plugin separato

Come abbiamo visto, l’interfaccia permette di registrare Custom Post Type e tassonomie.

Puoi quindi mantenere nello stesso sistema:

entità → classificazioni → campi

Per un sito di eventi, per esempio:

Post Type: Evento
Taxonomy: Tipo evento
Fields: data, luogo, prezzo, URL prenotazione

È una struttura molto più leggibile di una serie di pagine indipendenti in cui ogni informazione viene scritta a mano.

Non significa che devi obbligatoriamente usare l’interfaccia grafica per registrare ogni CPT. In un plugin custom puoi continuare a definirli via codice.

La scelta dipende dal workflow del progetto e da quanto vuoi che la configurazione sia gestibile dal pannello amministrativo.

Come esporre i Field Group nella REST API

Su questo punto circola ancora molta documentazione vecchia.

Il supporto alla WordPress REST API è disponibile sia nella versione gratuita sia in PRO. I Field Group, però, non vengono esposti automaticamente.

Devi abilitare:

Show in REST API

nelle impostazioni del gruppo interessato.

La documentazione ufficiale dell’integrazione REST specifica che i dati possono essere associati agli endpoint di post, pagine, custom post type, utenti e tassonomie e che l’esposizione del gruppo è opt-in.

Questo evita una conclusione ormai superata: non devi acquistare la versione PRO soltanto per poter leggere normali campi personalizzati attraverso la REST API.

Naturalmente un’architettura headless reale richiede comunque di ragionare su autenticazione, permessi, schema dei dati, caching e quantità di informazioni restituite.

Quando il plugin diventa un layer di dati per un frontend separato

In un WordPress tradizionale puoi pensare:

campi → PHP template → HTML

In un progetto headless il percorso può diventare:

campi → REST API → frontend → componente

La differenza sembra piccola ma cambia il modo in cui devi progettare i dati.

Un field name non è più un dettaglio interno al tema: potrebbe diventare parte del contratto utilizzato dal frontend.

Anche la struttura di Repeater, Relationship e campi complessi diventa importante perché determina il formato dei dati restituiti.

Per questo, nei progetti headless, è ancora più utile trattare il sistema come schema editoriale e non come semplice collezione di input.

Local JSON, versionamento e deploy: dal sito singolo al workflow professionale

Finché lavori direttamente su un singolo sito può sembrare normale creare un Field Group nel database e considerare il lavoro finito.

Il problema arriva quando hai:

locale → staging → produzione

oppure più sviluppatori che lavorano sullo stesso progetto.

Come trasferisci una modifica a un gruppo senza ricrearla manualmente?

È uno dei problemi risolti da Local JSON.

Cosa salva Local JSON e perché è diverso dal database

Local JSON consente di salvare configurazioni come Field Group, post type, tassonomie e Options Pages in file .json.

Per attivare il comportamento di base puoi creare nel tema:

/acf-json/

Quando salvi una configurazione compatibile, viene generato il relativo file.

La documentazione Local JSON spiega che questi file possono essere caricati e sincronizzati fra database differenti.

Il vantaggio più importante, dal punto di vista di sviluppo, è che la configurazione smette di vivere soltanto nel database.

Ora può entrare in Git insieme al tema o al plugin.

Sincronizzare configurazioni tra sviluppo, staging e produzione

Immagina questo flusso:

1. modifichi un Field Group in locale;
2. viene aggiornato il relativo JSON;
3. esegui il commit;
4. distribuisci il codice su staging;
5. sincronizzi la configurazione;
6. dopo i test distribuisci in produzione.

Questo riduce il problema classico delle configurazioni effettuate manualmente in ambienti differenti.

Attenzione però: Local JSON riguarda principalmente la definizione dei campi, non è un sistema per sincronizzare automaticamente tutti i valori editoriali del sito.

La configurazione di “Cliente è un Text Field” può essere versionata.

Il valore “Rossi Srl” inserito dentro uno specifico progetto resta contenuto del sito.

Sono due livelli differenti.

WP-CLI e gestione dei file nei deploy

La linea 6.8 ha aggiunto anche il comando:

wp acf json

per gestire via WP-CLI import, export, sincronizzazione e stato degli elementi Local JSON.

La documentazione di wp acf json lo presenta esplicitamente come supporto a workflow automatizzati, versionamento e pipeline di deploy.

Per un piccolo sito gestito interamente dall’interfaccia potrebbe essere superfluo.

Per un progetto distribuito attraverso CI/CD, invece, avere un’interfaccia a riga di comando significa poter ridurre ulteriormente operazioni manuali e differenze fra ambienti.

Le funzioni recenti di Advanced Custom Fields che vale la pena conoscere

Il plugin ha ampliato parecchio il proprio raggio d’azione.

Questo non significa che ogni funzione recente debba entrare nel tuo progetto. Ma alcune modifiche mostrano chiaramente la direzione dello sviluppo: dati strutturati più interoperabili, maggiore integrazione con WordPress e workflow meno dipendenti dal solo pannello amministrativo.

Abilities API e accesso controllato da strumenti AI

La linea 6.8 integra la WordPress Abilities API.

La Abilities API ufficiale di WordPress fornisce un modo standardizzato per registrare e scoprire unità di funzionalità con input, output e controlli dei permessi definiti.

Il plugin può utilizzare questo sistema per rendere alcune proprie strutture, come Field Group, Custom Post Type e tassonomie, scopribili e utilizzabili da strumenti compatibili.

L’integrazione è opt-in. Non significa che installando il software un agente AI ottenga automaticamente accesso completo al tuo sito.

La documentazione della release 6.8 richiede di abilitare l’integrazione e configurare l’accesso per gli elementi interessati.

Questo è un punto importante.

La funzione non va letta come “il plugin ha aggiunto l’intelligenza artificiale”. Espone invece strutture e operazioni attraverso un’API che altri sistemi possono utilizzare nel rispetto dei permessi definiti da WordPress e dalla configurazione adottata.

Structured data Schema.org: funzione interessante, ma ancora sperimentale

La versione PRO 6.8 ha introdotto anche la possibilità di mappare campi su proprietà Schema.org e generare automaticamente structured data JSON-LD.

La funzione è interessante per contenuti fortemente strutturati: prodotti, eventi, ricette o altre entità che hanno un mapping sensato.

Ma c’è un dettaglio che non va nascosto: il vendor la indica ancora come sperimentale.

Quindi eviterei due conclusioni.

La prima è che basta attivarla per “ottimizzare automaticamente il sito per l’AI”.

La seconda è che più structured data equivalgano automaticamente a maggiore visibilità.

Lo structured data deve descrivere fedelmente il contenuto realmente presente nella pagina e, quando l’obiettivo è ottenere specifiche funzionalità di Google Search, deve rispettare anche i requisiti previsti da Google per il relativo markup.

Questa funzione può semplificare la generazione del dato strutturato; non sostituisce la progettazione semantica né garantisce un risultato di ranking.

Cosa non cambia: resta prima di tutto uno strumento di content modeling

Abilities API, Block Bindings, datastore e Schema.org sono interessanti, ma non cambiano il motivo principale per cui questo sistema è utile.

Il valore continua a partire da una domanda molto più semplice:

come devono essere organizzati i dati di questo sito?

Se il modello dati è sbagliato, aggiungere più API non lo rende corretto.

Se il Field Group “Progetto” contiene venticinque campi creati senza una logica, automatizzarne l’accesso significa semplicemente distribuire una struttura confusa più velocemente.

Le nuove funzioni diventano realmente utili quando la base è buona.

entità chiare → campi coerenti → relazioni corrette → output controllato → eventuali API e automazioni

Questo ordine rimane valido anche quando la tecnologia intorno al plugin cambia.

Sicurezza ed errori comuni

Un sistema di campi personalizzati può interagire con dati memorizzati nel database, frontend, REST API, upload e moduli di modifica.

Va quindi trattato come qualsiasi altro componente applicativo: aggiornamenti, permessi, validazione e output non sono dettagli opzionali.

Tenere il plugin aggiornato e perché le security release contano

La versione 6.8.7 include diverse correzioni di sicurezza, tra cui maggiore validazione server-side per i campi Image e Gallery, controlli più restrittivi su alcune query AJAX e limitazioni dei dati User restituiti via REST agli utenti senza i permessi necessari.

Il punto non è memorizzare ogni singola patch.

È capire che un plugin che interagisce con contenuti, upload, utenti, AJAX e API deve essere mantenuto aggiornato.

Su un sito importante conviene comunque evitare aggiornamenti “alla cieca”: backup, staging e controllo delle funzionalità critiche restano la procedura più prudente.

Esporre dati nel frontend senza controllare output e permessi

Un campo salvato correttamente non è automaticamente sicuro in qualsiasi contesto di output.

Se recuperi un URL, un attributo HTML, un testo o contenuto formattato devi trattarlo secondo il contesto in cui verrà stampato.

Allo stesso modo, se abiliti l’esposizione REST devi verificare che quel dato sia effettivamente destinato ai client che possono accedere all’endpoint.

Il fatto che esistano strumenti per gestire questi scenari non elimina la responsabilità dell’implementazione.

Trasformare Flexible Content in un page builder ingestibile

Flexible Content è potente proprio perché consente di costruire layout modulari.

Quella libertà può diventare un problema.

Supponiamo di creare:

• Hero;
• Hero alternativo;
• Hero piccolo;
• Hero grande;
• Hero con CTA;
• Hero con immagine sinistra;
• Hero con immagine destra.

Dopo qualche mese il sito può avere un sistema editoriale parallelo che duplica funzionalità del Block Editor e richiede codice specifico per ogni variante.

Flexible Content funziona meglio quando i layout rappresentano componenti semanticamente distinti, non ogni possibile variazione estetica.

Separare struttura e stile rimane una buona regola anche qui.

Creare campi prima di aver progettato il modello dati

Questo è probabilmente l’errore più importante.

Apri il Field Builder, premi “Add Field” e cominci a costruire.

Dopo mezz’ora hai:

titolo_2

testo_sotto

blocco_dx

immagine_mobile

testo_finale

Sono nomi che descrivono un layout, non un’informazione.

Se il design cambia, il modello perde senso.

Meglio chiedersi:

• quale entità sto descrivendo?
• quali proprietà possiede?
• quali valori possono ripetersi?
• quali relazioni esistono?
• cosa appartiene al contenuto e cosa al design?

Soltanto dopo dovresti creare i campi.

Dimenticare portabilità e versionamento della configurazione

Se questa architettura è centrale in un progetto professionale, non lasciare che tutta la configurazione esista soltanto nel database di produzione.

Local JSON, esportazioni e, nei workflow più strutturati, WP-CLI permettono di mantenere una traccia delle modifiche.

La vera domanda è:

“Se domani devo ricostruire staging o passare il progetto a un altro sviluppatore, riesco a ricostruire anche il modello dei campi?”

Se la risposta è no, manca un pezzo del workflow.

ACF e Secure Custom Fields non sono la stessa cosa

Se cerchi oggi un plugin per custom field nella directory WordPress potresti incontrare anche Secure Custom Fields, abbreviato SCF.

È importante non confonderlo con Advanced Custom Fields.

Sono progetti distinti e vanno valutati come tali.

Perché oggi esistono entrambi

Secure Custom Fields è distribuito attraverso WordPress.org e offre strumenti per custom field, Custom Post Type e tassonomie.

Advanced Custom Fields continua invece come prodotto separato, con versione gratuita e PRO, sviluppato nell’ecosistema WP Engine.

Per utilizzare uno dei due non hai bisogno di approfondire tutta la storia organizzativa che ha portato alla separazione.

Ciò che conta operativamente è sapere che ACF e SCF non sono due componenti da combinare nello stesso stack.

Perché non vanno installati contemporaneamente

La pagina di Secure Custom Fields nella directory WordPress specifica che l’installazione disattiva ACF, ACF PRO e versioni legacy con funzionalità sovrapposte per evitare errori dovuti a funzioni duplicate.

Quindi non trattare SCF come un’estensione del plugin trattato in questa guida.

Se stai mantenendo un sito esistente basato su ACF, valuta con attenzione compatibilità e dipendenze prima di cambiare soluzione.

Temi, plugin custom, template e integrazioni potrebbero chiamare direttamente funzioni specifiche.

Quando il confronto merita un articolo separato

Un confronto completo fra Advanced Custom Fields e Secure Custom Fields richiede una pagina dedicata.

Bisognerebbe confrontare almeno:

• compatibilità;
• feature;
• API;
• sviluppo;
• ecosistema;
• licenza;
• migrazione;
• dipendenze del progetto.

Inserire tutto qui sposterebbe l’intento dalla guida operativa a una comparativa fra plugin.

Per questa pagina è sufficiente la regola pratica:

scegli consapevolmente quale stack utilizzare e non installare i due prodotti come se fossero complementari.

Quando scegliere ACF e quando valutare un’altra soluzione

Advanced Custom Fields è particolarmente adatto quando vuoi mantenere WordPress come CMS e aggiungere un modello dati strutturato senza sviluppare tutta l’interfaccia dei custom field da zero.

Non è però automaticamente la soluzione corretta per ogni progetto.

Scenario	Soluzione da valutare
Pochissimi metadati semplici gestiti da sviluppatori	API native dei custom field WordPress
Campi strutturati con interfaccia editoriale	ACF Free
Dati ripetibili, Flexible Content, Options Pages, Gallery	ACF PRO
Blocchi Gutenberg custom con workflow PHP	ACF PRO + Blocks
Dati destinati a frontend esterno	REST API, con progettazione dell’interfaccia dati
Configurazioni condivise fra ambienti	Local JSON
Progetto già basato su un altro framework custom field	Valutare il costo reale della migrazione prima di cambiare
Esigenze molto specifiche di storage, API o sviluppo	Confrontare plugin dedicati e codice custom

Alternative come Meta Box e Pods esistono e possono essere più adatte a determinati stack. Non ha però senso migrare semplicemente perché un altro plugin offre una feature equivalente.

Il costo di una tecnologia non è solo il prezzo della licenza.

Devi considerare:

implementazione + manutenzione + formazione + dipendenze + migrazione + compatibilità

Su un sito che utilizza già decine di Field Group, Repeater e template specifici, cambiare framework per risparmiare una licenza potrebbe costare molto più del rinnovo.

Al contrario, su un nuovo progetto molto semplice potresti non aver bisogno né della versione PRO né di un framework avanzato.

Il criterio corretto resta il modello dati.

Conclusione

Advanced Custom Fields diventa realmente utile quando smetti di pensarlo come un plugin che “aggiunge campi” e inizi a usarlo come uno strumento per separare dati, editing e presentazione.

Se devi aggiungere pochi metadati strutturati, la versione gratuita può essere più che sufficiente. Se il progetto richiede dati ripetibili, Options Pages, layout modulari o blocchi personalizzati, le funzioni PRO possono giustificare il passaggio alla versione a pagamento.

Le integrazioni con REST API, Block Bindings, Abilities API, Local JSON e WP-CLI ampliano parecchio ciò che puoi costruire, ma non sostituiscono una buona progettazione.

La sequenza che seguirei è sempre questa:

definisci le entità → progetta i dati → scegli i Field Type → configura le regole → costruisci l’output → solo dopo aggiungi automazioni e integrazioni avanzate.

Se il tuo sito WordPress utilizza già una struttura complessa e devi modificarla senza compromettere template, dati o integrazioni, può avere senso affrontare l’intervento come attività di sviluppo e non come semplice configurazione di un plugin. In quel caso puoi valutare un servizio di assistenza WordPress e supporto tecnico prima di intervenire direttamente su un sito in produzione.