ACF Blocks: come funzionano e perché sono uno standard

ACF Blocks è la funzionalità di Advanced Custom Fields che permette di registrare blocchi Gutenberg nativi usando campi personalizzati invece di scrivere React, collegando un template PHP ai valori inseriti dal cliente nell’editor a blocchi. In pratica: lo sviluppatore definisce i campi (testo, immagine, link, ripetitore) e il markup HTML che li renderizza, il cliente compila i campi dentro un blocco che si comporta in tutto e per tutto come un blocco nativo di WordPress, con anteprima live nell’editor e nessun accesso diretto al codice.

Prima che ACF introducesse questa funzionalità nella versione 5.8 del plugin, sviluppare un componente riutilizzabile su WordPress significava scegliere tra shortcode poco flessibili, campi personalizzati gestiti a mano nel backend senza anteprima visiva, o buttarsi su React per costruire un blocco nativo da zero. ACF Blocks ha colmato quel vuoto: dà la flessibilità dei blocchi nativi a chi scrive PHP e non vuole affrontare la curva di apprendimento di React solo per un box testimonianza o una scheda prodotto.

Come si registra un blocco ACF nella pratica

La registrazione avviene tramite un file block.json che dichiara nome, titolo, categoria e icona del blocco, e un file render.php che riceve i valori dei campi ACF e produce l’HTML finale. Non serve build step, non serve Node.js, non serve npm: il ciclo di sviluppo è identico a quello di un template PHP tradizionale, con la differenza che il risultato si comporta come un blocco Gutenberg a tutti gli effetti, inseribile, spostabile e configurabile direttamente nell’editor.

Le versioni più recenti di ACF hanno sostituito il vecchio metodo di registrazione tramite acf_register_block_type(), ancora presente in molti progetti sviluppati anni fa, con la registrazione basata su block.json, allineata al modo in cui WordPress registra qualsiasi altro blocco nativo o custom. Chi eredita un progetto con blocchi registrati nel vecchio modo non deve necessariamente riscriverli: entrambi i metodi continuano a funzionare, ma per nuovi sviluppi block.json è la scelta più solida, perché si integra meglio con strumenti moderni come i block pattern e semplifica l’eventuale migrazione futura verso funzionalità come la Block Bindings API.

{
  "name": "acf/scheda-servizio",
  "title": "Scheda servizio",
  "category": "blurr-sezioni",
  "icon": "list-view",
  "acf": {
    "mode": "preview",
    "renderTemplate": "render.php"
  },
  "supports": { "align": true, "mode": false }
}

Problema: cliente che chiede di poter aggiungere autonomamente nuove sezioni testimonianza senza intervento dello sviluppatore
Causa: le sezioni erano hardcoded nel template della pagina, ogni nuova testimonianza richiedeva una modifica al codice
Soluzione Blurr: blocco ACF con campi ripetitore per nome, ruolo, foto e testo, il cliente inserisce quante testimonianze vuole direttamente dall'editor senza toccare codice

Il vantaggio principale rispetto a un plugin generico di form builder o di gestione contenuti è che il blocco vive esattamente dentro l’editor a blocchi che il cliente già conosce. Non c’è un pannello separato da imparare, non c’è un plugin aggiuntivo da mantenere aggiornato: è la stessa interfaccia con cui si scrive un articolo, applicata a componenti strutturati.

I limiti che vale la pena conoscere prima di scegliere questa strada

ACF Blocks non è adatto a tutto. Per componenti con interattività complessa lato client, un configuratore con stato condiviso tra più elementi, un carrello che si aggiorna in tempo reale, un filtro che modifica dinamicamente una lista senza ricaricare la pagina, la strada corretta resta React con i pacchetti nativi di WordPress (@wordpress/blocks, @wordpress/element). ACF Blocks brilla per componenti di presentazione: sezioni con testo e immagini strutturati, card ripetibili, elementi che cambiano contenuto ma non comportamento.

Problema: blocco ACF che diventa lento a caricare nell'editor quando la pagina contiene più di venti istanze dello stesso blocco
Causa: ogni istanza del blocco esegue una query o un ciclo PHP pesante nel render, e l'editor richiama il render ad ogni modifica per l'anteprima live
Soluzione Blurr: cache dei dati pesanti (per esempio risultati di query WP_Query) tramite transient con chiave legata all'ID del post, invalidata al salvataggio, così l'editor richiama dati cachati invece di rieseguire la query ad ogni render

Un altro limite riguarda la portabilità: un sito che usa ACF Blocks dipende dal plugin ACF PRO per continuare a funzionare correttamente. Non è una dipendenza leggera come potrebbe sembrare, va comunicata al cliente in fase di consegna, insieme al costo di licenza annuale se si usa la versione PRO necessaria per i blocchi.

Sui progetti che gestiamo per le agenzie partner, la combinazione che usiamo più spesso è ACF Blocks per le sezioni di contenuto strutturato e blocchi nativi di WordPress (paragrafo, immagine, gruppo, colonne) per tutto il resto, evitando di reinventare componenti che WordPress offre già di default. È un principio che vale la pena tenere a mente prima di trasformare in blocco ACF qualcosa che il core gestisce già bene, come una semplice immagine con didascalia. Quando invece serve gestire una collezione di contenuti con una struttura propria, prodotti, eventi, schede membro, la scelta corretta si sposta su un <a href=”/custom-post-type-wordpress-campi-personalizzati/”>custom post type dedicato</a>, con ACF Blocks o ACF Fields usati per i campi specifici di quel contenuto.

Perché conviene rispetto a scrivere un blocco React da zero

Il confronto onesto con un blocco React nativo va fatto sui tempi di sviluppo e sul profilo di chi lo manterrà nel tempo. Un blocco React offre più controllo e più performance nell’editor per componenti complessi, ma richiede tooling JavaScript, un processo di build, e competenze che molte agenzie web che lavorano principalmente in PHP non hanno internamente. ACF Blocks abbassa questa barriera: chi sa scrivere un template PHP può costruire un blocco Gutenberg completo in poche ore invece che in giorni.

Su un progetto per un’agenzia di Bologna che segue un cliente nel settore immobiliare, abbiamo sostituito sei shortcode diversi, ciascuno gestito con parametri testuali che il cliente doveva ricordare a memoria, con altrettanti blocchi ACF con campi visivi. Il tempo di formazione del cliente sull’uso del nuovo sistema è sceso da una sessione di quaranta minuti a una spiegazione di cinque minuti, perché i campi si vedono e si compilano senza dover consultare una guida per ricordare la sintassi dello shortcode.

Chi vuole capire quando conviene investire in blocchi custom invece di affidarsi a un page builder generico può leggere il nostro confronto su blocchi Gutenberg custom e page builder, che approfondisce la questione dal lato manutenzione e performance. Per chi gestisce più progetti WordPress in parallelo e vuole valutare come strutturare al meglio lo sviluppo custom, su blurr.it/contatti/ possiamo guardare insieme l’architettura più adatta al caso specifico.

Domande frequenti

ACF Blocks richiede la versione PRO di Advanced Custom Fields?

Sì, la registrazione di blocchi tramite ACF è una funzionalità di ACF PRO, non disponibile nella versione gratuita del plugin. Va considerato come costo di licenza ricorrente nel preventivo del progetto.

Un blocco ACF è più lento di un blocco nativo di WordPress?

Dipende da cosa fa il render. Un blocco ACF che si limita a stampare campi testuali e immagini ha un impatto trascurabile. Un blocco che esegue query pesanti ad ogni render può rallentare l’editor, e in quel caso serve introdurre una cache lato server.

Conviene usare ACF Blocks per un sito con poche pagine statiche?

Spesso no. Per un sito vetrina di poche pagine senza necessità di aggiornamenti frequenti da parte del cliente, i blocchi nativi di WordPress o un tema con sezioni predefinite sono sufficienti e più veloci da consegnare.

Cosa succede a un blocco ACF se il cliente disattiva il plugin?

Il blocco smette di funzionare e il contenuto già inserito nell’editor rimane visibile come blocco non riconosciuto, senza rendering corretto in front-end finché il plugin non viene riattivato. È un motivo in più per includere ACF PRO nel piano di manutenzione del sito.