Il pattern, spiegato in dettaglio nel pezzo ufficiale How To Create Cross-Canvas Interactions In Divi 5, combina due feature di Divi 5 che da sole sono potenti ma insieme diventano un pattern architetturale riutilizzabile: i Canvas (workspaces separati per contenuti off-page) e le Interactions (trigger + effect + target). La magia sta nel fatto che un trigger sulla Main Canvas può mostrare, nascondere o modificare un elemento che vive su un altro Canvas. È il primo vero pattern no-code di Divi per orchestrare UI complesse senza JavaScript custom.

Nei prossimi paragrafi ti spiego come usare questo pattern in modo non banale (non solo "clicca qui e si apre un modal"), come integrarlo con logica AI-assisted per esperienze predittive, e i 4 limiti pratici che devi conoscere prima di proporlo a un cliente. È un articolo per chi usa Divi 5 in produzione e vuole spingersi oltre il Visual Builder base.

Perché Cross-Canvas Interactions è un cambio architetturale

La maggior parte delle agenzie WordPress usa Divi 5 come page builder visuale: moduli, righe, sezioni, preset. Ma il modello mentale resta quello del 2018: una pagina lunga con tanti moduli impilati. Cross-Canvas Interactions rompe questo modello perché ti permette di separare la logica di interazione dal layout principale.

Il Canvas Portal Module (introdotto con i Canvases in Divi 5) è un modulo speciale che inietta il contenuto di un altro Canvas dentro la pagina principale. Le Interactions possono quindi avere come target un elemento che vive su un Canvas separato, aprendo la porta a pattern come:

• modal contestuali che vivono su Canvas dedicati, richiamati da trigger sulla Main Canvas
• pannelli informativi che appaiono in base allo scroll position
• multi-step form dove ogni step è un Canvas separato
• menu mobile come Canvas off-page con Interactions di toggle
• preset switching cross-page basato su evento utente

La differenza rispetto al passato è radicale: prima per fare un modal serviva JavaScript custom, CSS per l'overlay, z-index management, e un sistema di eventi. Con Cross-Canvas Interactions tutto questo vive nel Visual Builder e si configura con click + drag. È un risparmio di ore per interazione e una riduzione del debito tecnico perché il pattern è gestito dal core di Divi invece che da plugin custom.

Il pattern base: 8 step per costruire un modal AI-assisted

Per mostrarti il pattern in azione, ti guido attraverso la costruzione di un modal AI-assisted che appare quando l'utente clicca su un bottone "Analizza il tuo caso". Il modal contiene un mini-form con 3 domande, e quando l'utente le compila, mostra una risposta contestuale generata da AI (mockata in questo esempio, ma pronta per essere collegata a un endpoint).

Step 1: Creare il Canvas per il modal. Nel Visual Builder di Divi 5, vai su Settings → Canvases → Add New Canvas. Chiamalo "AI Analysis Modal". Questo Canvas è separato dalla Main Canvas e non viene renderizzato nella pagina principale.

Step 2: Dimensionare il modal come overlay. Nel Canvas dedicato, aggiungi una Section con impostazioni Position: Fixed, larghezza e altezza 100%, background semitrasparente. Questo crea l'overlay che coprirà la pagina quando attivato.

Step 3: Stilizzare il pannello del modal. Aggiungi una Row dentro la Section, con larghezza 500px, centrata, background bianco, border-radius, padding. Questo è il "pannello" visivo che conterrà il form.

Step 4: Aggiungere il form. Inserisci 3 moduli Code (testo semplice che funge da label) e 3 moduli Text Field (per le risposte). Aggiungi un modulo Button con label "Analizza".

Step 5: Aggiungere un bottone di chiusura. Inserisci un modulo Icon posizionato in alto a destra del pannello, con classe CSS close-modal. Questo bottone chiuderà il modal quando cliccato.

Step 6: Nascondere il modal di default. Nella Section del Canvas, vai su Advanced → Visibility → Hide on load. Il modal non deve essere visibile quando la pagina carica.

Step 7: Creare l'Interaction di chiusura. Sul bottone di chiusura (Step 5), vai su Advanced → Interactions → Add Interaction. Trigger: Click. Effect: Hide Element. Target: Parent Section. Questo è il trigger che chiude il modal.

Step 8: Creare l'Interaction di apertura dalla Main Canvas. Torna sulla Main Canvas. Trova il bottone "Analizza il tuo caso" nella pagina. Vai su Advanced → Interactions → Add Interaction. Trigger: Click. Effect: Show Element. Target: Element Selected by ID. Inserisci l'ID del Section del modal (lo trovi nel Canvas dedicato). Questo trigger apre il modal.

Quando pubblichi la pagina, il modal appare solo quando l'utente clicca sul bottone, e si chiude quando clicca sull'icona. Nessun JavaScript custom, nessun plugin di terze parti, tutto nel Visual Builder.

Per una comprensione più ampia dell'ecosistema Divi 5 e di come le nuove feature si integrano, ti rimando a Divi 5 Workspaces per agenzie WordPress multi-ruolo nel 2026 che copre la governance di team con Workspaces, e a Generare design system WordPress con AI e Divi 5 nel 2026 per la generazione di token e preset.

4 pattern avanzati con logica AI

Una volta padroneggiato il pattern base, puoi iniziare a usarlo per casi più sofisticati che integrano logica AI in modo nativo. Ecco 4 pattern che ho implementato con successo su progetti reali.

Pattern 1: Multi-step form con contesto persistente

Crea un Canvas separato per ogni step del form (3-5 Canvas totali). Ogni Canvas contiene un modulo Code con il prompt per il modello AI, basato sulle risposte degli step precedenti. Quando l'utente clicca "Avanti", un'Interaction nasconde lo step corrente e mostra il successivo. Il vantaggio è che la logica del prompt AI è visibile e modificabile nel Visual Builder, senza dover editare JavaScript.

Per implementare il passaggio di contesto, usa una variabile globale JavaScript iniettata via modulo Code:

// modulo Code all'inizio del primo Canvas
window.formContext = { step1: '', step2: '', step3: '' };

// nel bottone "Avanti" del Canvas Step 1, aggiungi Interaction:
// Trigger: Click → Effect: Run Custom Code → Target: Self
// Custom Code:
window.formContext.step1 = document.querySelector('#field-step1').value;

Pattern 2: Modal contestuale basato su scroll

Crea un Canvas "Help Context Panel" che appare quando l'utente scrolla oltre il 50% della pagina. Trigger: Viewport Enter su un elemento Section posizionato a metà pagina. Effect: Show Element sul modal contestuale.

Questo pattern è perfetto per guide lunghe o documentazione tecnica: l'utente legge fino a un certo punto, poi vede apparire un pannello "Hai bisogno di aiuto con questa sezione?" con link rapidi. È un'alternativa no-code al classico chatbot overlay.

Pattern 3: Cross-Canvas Preset Switching

Quando l'utente cambia un'impostazione (es. dimensione testo, dark mode, lingua), un'Interaction cambia il preset applicato all'intera pagina. Il preset vive su un Canvas dedicato "Presets Library" e contiene tutte le varianti.

Questo pattern è particolarmente utile per siti multi-brand o per agenzie che gestiscono portfolio di clienti con lo stesso template Divi: cambiare preset cambia completamente l'aspetto senza dover ricaricare la pagina.

Pattern 4: Micro-interactions predittive con AI

Questo è il pattern più avanzato: usa un endpoint AI esterno per prevedere quale azione l'utente sta per compiere (es. vuole uscire, è in difficoltà, sta cercando qualcosa di specifico) e mostra un Interaction contestuale. L'endpoint AI può essere un tuo server PHP che chiama un LLM, oppure un webhook che riceve eventi da uno strumento come Hotjar o Microsoft Clarity.

Per un esempio reale di integrazione AI in workflow agenzia, vedi anche Toolchain agenzia WordPress moderna 2026: guida pratica completa che copre l'integrazione tra Bedrock, Sage e Divi 5 in un'architettura completa.

I 4 limiti pratici che devi conoscere

Cross-Canvas Interactions è potente ma ha limiti che devi comunicare al cliente prima di iniziare. Conoscerli ti salva da scope creep e promesse non mantenibili.

Limite 1: Nessuna logica condizionale complessa. Le Interactions supportano trigger semplici (click, hover, scroll, time, viewport) ma non catene logiche del tipo se l'utente ha risposto X e ha scrollato Y, allora mostra Z. Per questo ti serve JavaScript custom o un plugin come Divi AI Mode che estende le Interactions con logica condizionale.

Limite 2: Limite di Canvas per pagina. Il Visual Builder di Divi 5 gestisce fino a 20-30 Canvas per pagina senza degrado percepibile. Oltre questo limite, il page builder rallenta significativamente in fase di editing (non in fase di frontend). Per pagine molto complesse, valuta di spezzare in più pagine con link di navigazione.

Limite 3: Performance frontend con molti Canvas Portal. Ogni Canvas Portal Module aggiunge un render pass in più al frontend. Con 10-15 Canvas Portal in una pagina, il TTFB può aumentare di 50-100ms. Per pagine performance-critical (landing page ads, e-commerce checkout), usa i Canvas Portal con parsimonia e monitora il TTFB con Query Monitor.

Limite 4: Mancanza di debug visuale. Quando un'Interaction non funziona, il debug è difficile: il Visual Builder non ha un debugger passo-passo che ti dice "il trigger è scattato ma l'effect non ha trovato il target". Devi aprire i DevTools del browser, ispezionare il DOM, e verificare manualmente che gli ID dei target siano corretti. È un'area in cui Divi 5 deve ancora maturare.

Come integrare Cross-Canvas con il workflow di migrazione Divi 5

Per le agenzie che stanno migrando portfolio di clienti da Divi 4 a Divi 5 (processo che ho coperto in Divi 5 ufficiale: migrazione agenzia 2026), Cross-Canvas Interactions è una feature da posizionare come vantaggio competitivo della nuova versione. Ecco come integrarlo nel workflow di migrazione.

Fase 1 — Audit pre-migrazione. Identifica quali siti del portfolio usano plugin di terze parti per modal, popup, multi-step form, scroll-triggered content. Cross-Canvas può sostituire molti di questi plugin, riducendo il numero di dipendenze.

Fase 2 — Prototipo su un sito pilota. Costruisci un sito pilota con 3-4 pattern Cross-Canvas prima di migrare il portfolio completo. Misura il tempo risparmio rispetto all'implementazione JavaScript custom o plugin equivalenti.

Fase 3 — Documentazione interna. Crea una libreria di pattern riutilizzabili (modal AI-assisted, multi-step form, preset switching) con screenshot e codice di esempio. Ogni nuovo cliente può partire da questa libreria invece di ricostruire da zero.

Fase 4 — Formazione del team. Cross-Canvas Interactions richiede un cambio di mentalità: da "aggiungo un plugin" a "configuro un pattern nativo". Dedica 4-6 ore di formazione pratica al team, con esercizi su casi reali dei tuoi clienti.

Le 7 domande da farsi prima di proporre Cross-Canvas a un cliente

Cross-Canvas è un pattern potente ma non è la risposta a tutti i problemi di UI. Prima di proporlo a un cliente, fatti queste 7 domande.

1. Il cliente vuole modificare il pattern da solo? Se sì, il Visual Builder è perfetto. Se no, e devi fare modifiche solo tu, forse conviene JavaScript custom documentato.

2. Il sito ha esigenze di performance estreme? Se il TTFB deve essere sotto i 100ms, l'overhead dei Canvas Portal potrebbe essere un problema. Valuta alternative.

3. Il pattern verrà usato in 1 pagina o in 20? Se in 20, investi in un sistema di preset riutilizzabili. Se in 1 sola pagina, anche un'implementazione artigianale va bene.

4. Il cliente ha bisogno di logica condizionale complessa? Se sì, Cross-Canvas da solo non basta. Valuta plugin aggiuntivi o JavaScript custom.

5. Il sito sarà mantenuto dal cliente o da te? Se dal cliente, la semplicità del Visual Builder è un vantaggio. Se da te, JavaScript custom ti dà più controllo.

6. Il budget del progetto giustifica il setup iniziale? Cross-Canvas richiede 4-8 ore di setup iniziale per ogni pattern complesso. Per progetti sotto le 20 ore totali, potrebbe non valere.

7. Il pattern sarà compatibile con futuri aggiornamenti di Divi 5? Sì, perché è una feature supportata ufficialmente. Ma tieni d'occhio le release notes per breaking changes.

Checklist operativa per implementare Cross-Canvas in produzione

Per implementare Cross-Canvas Interactions in modo professionale su un sito in produzione, ecco una checklist operativa in 7 punti.

1. Audit dei plugin sostituibili. Prima di partire, identifica quali plugin di terze parti (popup, modal, form multi-step) possono essere sostituiti da Cross-Canvas. Su un portfolio tipico ho sostituito 4-6 plugin per sito, con risparmio di 100-200€/anno per cliente in licenze.

2. Mappa dei Canvas necessari. Crea una mappa: quanti Canvas servono, dove vivono, come interagiscono tra loro. Un diagramma su carta o Figma aiuta a visualizzare il flusso.

3. Naming convention. Usa prefissi chiari per i nomi dei Canvas: modal-ai-analysis, panel-help-context, preset-light/dark. Aiuta te e il cliente a orientarsi nel Visual Builder.

4. Test cross-browser. Cross-Canvas funziona bene su Chrome, Firefox, Safari, Edge ma verifica sempre su Safari iOS (a volte le animazioni di show/hide hanno micro-delay).

5. Performance test. Misura TTFB e Largest Contentful Paint con Lighthouse prima e dopo l'implementazione. Accetta che ci sarà un piccolo overhead (5-15ms) ma non deve essere percepibile.

6. Documentazione per il cliente. Crea un documento PDF di 2-3 pagine con screenshot dei pattern implementati e spiegazione di come modificarli. Il cliente deve poter essere autonomo per modifiche semplici.

7. Monitoraggio post-lancio. Per le prime 2 settimane, monitora il bounce rate e il tempo medio su pagina. Se Cross-Canvas migliora l'engagement (come dovrebbe), hai un caso studio. Se peggiora, rivaluta il pattern.

Conclusione: Cross-Canvas è un primo passo, non la destinazione

Cross-Canvas Interactions è un pattern potente ma va inquadrato per quello che è: il primo vero pattern no-code di Divi 5 per orchestrare UI complesse. Non sostituisce JavaScript custom per logiche sofisticate, non sostituisce framework come React per applicazioni interattive, non sostituisce plugin specializzati per use case molto verticali.

Quello che sostituisce bene è: plugin popup leggeri, modal contestuali, micro-interazioni di engagement, multi-step form semplici, preset switching cross-page. Per questi casi, è un upgrade significativo rispetto al passato: zero JavaScript, tutto nel Visual Builder, manutenibile dal cliente.

La parte interessante è che Divi 5 è ancora giovane come architettura (la beta è finita da poche settimane, il 20 giugno 2026). Cross-Canvas è una delle prime feature di un percorso che porterà sempre più logica nel Visual Builder. Nei prossimi mesi mi aspetto di vedere: conditional logic nelle Interactions, Canvas template riutilizzabili, integrazione nativa con AI Connectors di WordPress 7.0, e debug visuale degli Interactions. Quando queste feature arriveranno, il pattern diventerà ancora più potente.

Per ora, è un ottimo strumento da avere nella cassetta degli attrezzi della tua agenzia, da usare con cognizione dei suoi limiti, e da proporre ai clienti come vantaggio competitivo della nuova architettura Divi 5.

Riferimenti utili per approfondire

• How To Create Cross-Canvas Interactions In Divi 5 - Elegant Themes Blog (21 giu 2026) - articolo originale Elegant Themes sul pattern Cross-Canvas
• Divi 5 Workspaces per agenzie WordPress multi-ruolo nel 2026 - governance team agenzia con Workspaces Divi 5
• Generare design system WordPress con AI e Divi 5 nel 2026 - generazione design system AI-assisted per Divi 5
• Divi 5 ufficiale: migrazione agenzia 2026 - workflow completo migrazione Divi 4 → Divi 5
• Toolchain agenzia WordPress moderna 2026: guida pratica completa - toolchain agenzia con Bedrock, Sage e Divi 5
• Divi 5.8 moduli terze parti: guida pratica completa 2026 - moduli terze parti Divi 5.8 e quando preferirli a plugin esterni
• What Are Divi 5 Interactions - Elegant Themes Blog - documentazione completa sulle Interactions
• What Are Divi 5 Canvases - Elegant Themes Blog - documentazione ufficiale sui Canvases
• Divi 5 Attribute Management - Elegant Themes Blog - come gestire attributi e preset in Divi 5
• Divi 5 Official Release Announcement (20 giu 2026) - annuncio ufficiale fine beta Divi 5
• Hotjar - Heatmap e session recording - tool per identificare pattern di comportamento utente da usare con Cross-Canvas
• Microsoft Clarity - Free Heatmaps - alternativa gratuita a Hotjar per behavioral analytics

Questa guida è il complemento pratico a Generare design system WordPress con AI e Divi 5 e a Divi 5.8 moduli terze parti: ti mostro come costruire feed custom reali (portfolio agenzia, directory corsi, calendario eventi) usando Loop Builder + Variable Generator + AI in 4 fasi, con un TCO reale confrontato con JetEngine.

Il contesto Divi 5: Divi 5 preset e design system AI, Divi 5 Workspaces per agenzie, Divi 5 Aspect Ratio, Image Framing e Image Preset, Divi 5 SVG Module e AI, Divi 5 Official migrazione agenzia.

Cosa fa esattamente Divi 5 Loop Builder

Il Loop Builder è un toggle presente su qualsiasi modulo, riga o sezione Divi 5. Quando lo attivi, l'elemento smette di essere "statico" e diventa un template che viene ripetuto per ogni risultato della query associata. Le caratteristiche chiave:

• Loop su qualsiasi post type: post, page, product, custom post type, attachment, utenti, term di tassonomia, prodotti WooCommerce.
• Query personalizzabile: filtri per tassonomia, meta, autore, data, status, parent. Ordinamento per qualunque campo. Paginazione nativa.
• Template riciclabile: salvi il template di loop e lo riusi in pagine diverse senza ricostruirlo.
• Dynamic content nativo: ogni proprietà CSS o contenuto può essere legato al post corrente del loop (titolo, immagine, custom field, tassonomia, data, autore).
• Integrazione con Variable Generator: i token del Loop Builder (es. %%posttitle%%, %%postexcerpt%%, %%term_name%%) possono alimentare le Variable del design system.

In pratica: tutto quello che prima richiedeva un plugin "custom post type + custom field + template loop + filtro AJAX" ora è nativo. La differenza è che Loop Builder lavora dentro il Visual Builder, quindi designer e developer possono collaborare sullo stesso canvas.

I 4 scenari in cui Loop Builder batte i plugin terzi

Loop Builder non è la risposta a tutto, ma in 4 scenari specifici è oggettivamente superiore ai plugin dedicati. Vediamoli uno per uno.

Scenario 1: portfolio agenzia con custom post type

Caso reale: agenzia con 80 progetti, ognuno con custom field (cliente, anno, settore, budget, link, testimonial). Con JetEngine: 4 giornate di setup (CPT + meta box + template loop + filtro AJAX). Con Loop Builder: 1 giornata.

Configurazione: vai su Divi → Theme Builder → Add New Template → Body → Archive → scegli il CPT "Progetti" → Loop Builder ON → trascina un modulo "Image" e collegalo al dynamic content "Featured Image". Trascina un modulo "Text" e collegalo al dynamic content "Title". Trascina un modulo "Blurb" per ogni custom field (cliente, anno) e configuralo con %%progetti_cliente%%. Aggiungi un modulo "Filter" di Divi 5 con toggle per tassonomia "Settore". Salva template.

Il risultato: una griglia portfolio filtrabile per settore, con immagine, titolo, cliente, anno, che si popola automaticamente dai CPT. Niente PHP, niente plugin, niente shortcode da ricordare.

Scenario 2: directory corsi con filtri multipli

Caso reale: scuola online con 200 corsi, tassonomie "Categoria" e "Livello", custom field "Durata", "Prezzo", "Docente". Con Toolset: 3 giornate di setup. Con Loop Builder: 1 giornata.

Configurazione: Theme Builder → Single template per "Corso" → Loop Builder su Row → moduli per ogni custom field. Archive template con filtri multipli: modulo "Filter" con supporto tassonomie + range slider per "Prezzo" e "Durata". Loop Builder sulla griglia corsi.

L'integrazione chiave è il modulo "Filter" di Divi 5.8+: supporta range slider per custom field numerici, multi-select per tassonomie, e refresh automatico del loop senza ricaricare pagina. È la stessa UX di Amazon/Subito, nativa in Divi.

Scenario 3: calendario eventi con data dinamica

Caso reale: sito di eventi con 50 eventi/mese, custom field "Data evento", "Location", "Speaker". Con Events Calendar (99 $/anno): 2 giornate + licenza. Con Loop Builder: 0,5 giornate.

Configurazione: CPT "Evento" con custom field "Data evento" (date picker). Loop Builder su archive con modulo "Text" configurato come %%eventi_data%% formattato l d F Y. Modulo "Divider" con classe condizionale che nasconde eventi passati (Loop Builder ha un conditional display nativo basato su data meta). Modulo "Button" con link al single template dell'evento.

Il calendario "month view" vero e proprio richiede ancora Events Calendar, ma se il tuo bisogno è una lista eventi filtrabile per mese futuro, Loop Builder copre il 90% del caso d'uso.

Scenario 4: WooCommerce con custom product type

Caso reale: e-commerce con prodotti che hanno custom field aggiuntivi (es. "Materiale", "Certificazioni", "Scheda tecnica PDF"). WooCommerce nativo non gestisce questi meta con template visuali. Con WooCommerce Product Add-Ons (49 $/anno): 1 giornata + licenza. Con Loop Builder: 2 ore.

Configurazione: Theme Builder → Single product template → Loop Builder su Row → moduli "Text" per ogni custom field collegati via dynamic content. Modulo "Button" con link al PDF della scheda tecnica. Modulo "Image" per le "Certificazioni" (gallery filtrata per custom field).

Pipeline AI-assisted in 4 fasi

La parte più interessante del Loop Builder è l'integrazione con AI per accelerare la creazione di template complessi. Ecco la pipeline che uso in agenzia, in 4 fasi.

Fase 1: brief e raccolta custom field

Prima di toccare Divi, definisci cosa vuoi mostrare. Una sessione di 30 minuti con il cliente per mappare:

• Quali custom field servono (testo, numero, immagine, file, relazione).
• Quali tassonomie (categorie, tag, gerarchie).
• Quali filtri UX vuoi offrire all'utente finale.

Output: una tabella campo | tipo | obbligatorio | filtro UX | dynamic content token.

Fase 2: prompt AI per generare la query e i moduli

Con il brief in mano, genera un prompt strutturato per Claude o ChatGPT che produca la lista dei moduli Divi con i loro dynamic content token. Ecco un template pronto:

Sei un dev WordPress esperto di Divi 5. Devi creare un template Loop Builder per un custom post type "[NOME_CPT]" con i seguenti custom field: [LISTA]. Tassonomie: [LISTA]. Filtri UX richiesti: [LISTA].

Produci:
1. Query Loop Builder in formato JSON (tax_query, meta_query, orderby, posts_per_page).
2. Lista moduli Divi nell'ordine ottimale (riga 1: immagine full-width, riga 2: titolo + custom field in colonne 3-9, ecc.).
3. Per ogni modulo indica il dynamic content token da usare (es. %%post_title%%, %%cpt_cliente%%).
4. Eventuali conditional display (es. mostrare il modulo "Certificazioni" solo se il custom field non è vuoto).

Output tipico: un blocco JSON + elenco moduli lungo 20-40 righe, pronto per essere incollato nella sezione Dynamic Content di Divi.

Fase 3: costruzione template in Visual Builder

Apri Divi → Theme Builder → Add Template → scegli il CPT → Loop Builder ON. Trascina i moduli nell'ordine suggerito dall'AI, collega i dynamic content token via Content → Dynamic Content → [token]. Per i filtri, trascina un modulo "Filter" e configuralo con le tassonomie e i range slider richiesti.

Tempo medio: 1-2 ore per template completo con 8-12 moduli.

Fase 4: ottimizzazione e Variable Generator

Una volta che il template è funzionante, usa il Variable Generator (vedi Generare design system WordPress con AI e Divi 5) per wrappare i colori, i font e gli spacing in variabili. Esempio:

# Prompt per Variable Generator
Genera 6 variabili colore per il portfolio:
- portfolio-bg: bianco puro
- portfolio-card-bg: grigio 50 (HSL 0 0% 96%)
- portfolio-title: grigio 900 (HSL 220 13% 18%)
- portfolio-accent: blu elettrico (HSL 220 90% 56%)
- portfolio-meta: grigio 500 (HSL 220 9% 46%)
- portfolio-hover: blu scuro (HSL 220 90% 40%)

Incolla l'output nel Variable Generator e avrai un design system coerente su tutti i loop template del sito, modificabile in un punto solo.

Confronto TCO: Loop Builder vs JetEngine vs Toolset

Il punto operativo è il costo reale. Ecco il TCO a 24 mesi per un'agenzia media con 30 siti attivi, ognuno con 1-2 feed custom:

A 24 mesi, Loop Builder fa risparmiare all'agenzia tra 5.000 e 6.000 € in licenze e tra 150 e 240 ore di lavoro tecnico, anche considerando l'override del costo di licenza Divi (che hai già perché usi Divi 5). Il break-even è immediato: dal primo sito.

Limiti e quando NON usare Loop Builder

Loop Builder non è la risposta a tutto. Ci sono 5 scenari in cui un plugin dedicato resta superiore:

• Query SQL complesse con join tra CPT. Loop Builder supporta metaquery e taxquery ma non JOIN tra tabelle custom. Se devi fare query su tabelle create da plugin esterni, JetEngine è ancora più flessibile.
• Frontend filter con URL semantici (es. /portfolio/?settore=design&anno=2025). Loop Builder supporta filtri AJAX ma gli URL rimangono sporchi (?filter_settore=design&filter_anno=2025). JetEngine ha un sistema di permalink custom che Loop Builder non replica.
• Conditional logic granulare. Loop Builder ha conditional display per modulo, ma è limitato a "campo vuoto/non vuoto" e "data maggiore/minore di". JetEngine ha un sistema di conditional logic con operatori logici (AND, OR, nested) che Loop Builder non raggiunge.
• Submission form front-end. Se ti serve un form per aggiungere CPT dal frontend con logica condizionale, devi usare JetEngine Form o Gravity Forms. Loop Builder è solo display.
• REST API personalizzate. JetEngine espone endpoint REST API custom per ogni CPT. Loop Builder no.

La regola pratica: se ti serve solo visualizzare CPT/tax con filtri UX, Loop Builder copre il 90% dei casi e ti fa risparmiare migliaia di euro. Se ti serve editare CPT dal frontend o logica condizionale complessa, resta su JetEngine.

Roadmap di adozione per agenzia

Per un'agenzia con 20-30 siti Divi, ecco una roadmap realistica in 6 settimane:

1. Settimana 1: aggiorna tutti i siti a Divi 5.8+ (richiesto per Loop Builder). Verifica compatibilità template esistenti.
2. Settimana 2: identifica i 5 siti con custom post type gestiti via JetEngine/Toolset. Analizza quali sono convertibili al 100% Loop Builder, quali no.
3. Settimana 3: converti 1 sito pilota. Misura tempo di conversione e qualità del risultato.
4. Settimana 4: forma il team sulla pipeline AI-assisted in 4 fasi. Crea template di prompt riutilizzabili.
5. Settimana 5: converti gli altri 4 siti identificati. Disattiva e rimuovi i plugin sostituiti (dopo 30 giorni di coesistenza per verifica).
6. Settimana 6: documenta il pattern "Loop Builder standard" per i prossimi progetti. Aggiorna l'offerta commerciale: "feed custom inclusi" invece di "feed custom + costo plugin".

Risultato atteso: 5.000+ € risparmiati in licenze plugin, 100+ ore di lavoro tecnico risparmiate in 24 mesi, offerta commerciale più competitiva.

Le 7 cose che puoi fare oggi

Checklist concreta per partire subito:

1. Verifica la versione Divi: Dashboard → Updates. Se sei sotto 5.8, aggiorna prima in staging.
2. Identifica 1 CPT esistente sul tuo sito (portfolio, eventi, team, case study).
3. Prova Loop Builder sul template archive: attiva il toggle su una riga, collega 2-3 moduli a dynamic content token.
4. Confronta il risultato con il template esistente (gestito da JetEngine o altro plugin). Verifica parità funzionale.
5. Aggiungi il modulo Filter di Divi 5.8+ per la tassonomia principale. Testa il refresh AJAX.
6. Genera il prompt AI per il tuo CPT specifico usando il template della Fase 2. Risparmierai 30-60 minuti nella progettazione.
7. Misura il tempo totale di creazione del feed custom. Su un feed medio il target è 2 ore, contro le 4-6 ore del plugin dedicato.

Conclusione: Loop Builder chiude l'era dei plugin di "custom content"

Per anni il pattern "CPT + custom field + template loop" ha richiesto un plugin dedicato. Il Loop Builder di Divi 5 ribalta questa equazione: lo strumento nativo del page builder copre il 90% dei casi d'uso reali delle agenzie, elimina migliaia di euro di licenze e accelera i tempi di sviluppo del 50%. L'unico vero limite è la logica condizionale complessa, dove JetEngine resta superiore.

Il consiglio operativo: prendi 1 sito pilota con 1 custom post type, convertilo a Loop Builder in 2 ore usando la pipeline AI-assisted, verifica la parità funzionale con il setup precedente. Se il risultato è buono, hai appena trovato 5.000 €+ di saving per i prossimi progetti.

Riferimenti utili per approfondire

• Generare design system WordPress con AI e Divi 5 - come wrappare il Loop Builder in un design system coerente.
• Divi 5.8 moduli terze parti: guida pratica completa 2026 - il contesto del release che ha stabilizzato Loop Builder.
• Divi 5 Workspaces per agenzie WordPress multi-ruolo - governance del team su progetti Loop Builder.
• Divi 5 SVG Module e AI - come generare icone coerenti con il Loop Builder.
• Divi 5 Aspect Ratio, Image Framing e Image Preset - layer immagine per il Loop Builder.
• Divi 5 Official migrazione agenzia - come pianificare la migrazione Divi 4 → 5 senza rompere i custom feed.
• Elegant Themes - Introducing Loop Builder For Divi 5 - annuncio ufficiale del release.
• Elegant Themes - Everything You Need To Know About Divi 5's Loop Builder - guida tecnica completa.
• Elegant Themes Help Center - Loop Builder in Divi 5 - documentazione ufficiale.
• Divi 5.6 Release Notes - bug fix e miglioramenti di Loop Builder nella 5.6.
• JetEngine vs Loop Builder - community comparison - confronto reale dalla community Divi.
• WordPress.tv - Divi Loop Builder workshop - sessioni WordCamp di approfondimento.

FAQ

Loop Builder funziona anche con WooCommerce? Sì. WooCommerce è un custom post type ("product") con tassonomie ("productcat", "producttag") e custom field standard (prezzo, SKU, stock). Loop Builder supporta nativamente prodotti, variazioni, categorie, tag e custom field aggiunti con plugin come ACF o Toolset Types.

Posso usare Loop Builder insieme a JetEngine sullo stesso sito? Sì, ma è sconsigliato per evitare conflitti nella gestione dei template. La strategia consigliata è: scegli una delle due soluzioni per CPT e template, l'altra solo per le feature specifiche (es. JetEngine per le submission form, Loop Builder per il display).

Il dynamic content token funziona con custom field creati con ACF? Sì, Divi 5 ha un'integrazione nativa con Advanced Custom Fields. Il token compare automaticamente nel menu Dynamic Content → ACF Field. Per custom field di Toolset o Pods potrebbe servire un bridge plugin (Meta Box ha integrazione nativa simile).

Quanto è veloce Loop Builder su archivi con 5.000+ post? Le prestazioni dipendono dalla query e dal numero di moduli per template. Su un archivio con 5.000 CPT e template da 8 moduli, il TTFB medio è 200-400 ms con cache object attivo (Redis). Senza cache object può salire a 800-1500 ms. Per archivi enormi (50.000+), consiglio paginazione con cache frammentata.

Loop Builder sostituisce completamente i page builder archive template di Elementor o Bricks? No. Loop Builder è specifico di Divi 5. Se usi Elementor hai il "Loop Grid" (simile ma più giovane come feature), se usi Bricks ha il "Query Loop" nativo (concettualmente simile a Loop Builder). La scelta tra i tre page builder dovrebbe già essere fatta per altri motivi (workflow, ecosystem, performance); Loop Builder non è il discriminante.

Vale la pena convertire un sito Divi 4 a Divi 5 solo per Loop Builder? Sì, se il sito ha 2+ custom post type gestiti via plugin. Il risparmio a 24 mesi (5.000+ € in licenze) supera largamente il costo della migrazione (1-2 giornate di agenzia). Per siti con 0 custom post type, la migrazione non è giustificata da Loop Builder ma può esserlo per altri motivi (preset system, performance, nuovi moduli).

Il contesto è importante. Divi 5 ha impiegato oltre 12 mesi di beta per arrivare alla release ufficiale il 20 giugno 2026, e ora il team di Nick Roach sta accelerando il ritmo di rilascio (circa un major update a settimana). I moduli terze parti sono una risposta diretta a una critica ricorrente: Divi costringeva spesso a usare shortcode nudi per integrare plugin come Gravity Forms, con risultati mediocri a livello di styling e di responsiveness. La 5.8 chiude questa lacuna con moduli nativi che ereditano il sistema di preset, attributi e responsive control di Divi.

Per chi non avesse ancora aggiornato a Divi 5 (la beta è ufficialmente chiusa), il primo passo è la migrazione. Abbiamo già discusso il tema in modo approfondito nella guida ufficiale migrazione agenzia Divi 5. Se invece sei già su Divi 5 ma vuoi capire come sfruttare al meglio i moduli AI e SVG, trovi riferimenti nella guida SVG Module AI e nella panoramica design system AI con Divi 5. La 5.8 estende quel discorso all'integrazione verticale con plugin di terze parti.

I sei nuovi moduli Divi 5.8 in dettaglio

Vediamo i sei moduli uno per uno, con attenzione a cosa fanno, quando sono utili e quando invece è meglio restare sul plugin originale.

Tooltip Module: tooltip accessibili nativi

Il Tooltip Module è il più semplice dei sei: un blocco che mostra un tooltip al passaggio del mouse (o al focus tastiera, se configurato). Cosa lo rende diverso da un tooltip CSS custom:

• Accessibilità WCAG 2.2 integrata (focus management, ARIA roles)
• Responsive positioning automatico (top/bottom/left/right)
• Styling consistente con il preset system Divi 5
• Animazione di ingresso/uscita configurabile

Per la pipeline AI, il Tooltip è ideale per glossari, FAQ compatte, etichette esplicative di acronimi tecnici, micro-copy contestuali in landing page complesse.

Loop Filter Module: filtri dinamici per Query Loop

Loop Filter è il modulo che estende Query Loop con filtri dinamici lato frontend. Esempio classico: portfolio con filtri per categoria, archivio prodotti con filtri per tag/prezzo, archivio articoli con ricerca full-text. Il modulo si appoggia a una tassonomia o a una custom field, e genera automaticamente UI di filtro (checkbox, select, range slider) coerente con il design system Divi.

Per l'AI, Loop Filter è utilissimo per generare archivi tassonomici interattivi senza scrivere JavaScript: prompt → struttura filtri → modulo preconfigurato.

Payment Module: pagamenti integrati senza WooCommerce

Payment è il modulo più controverso. Permette di aggiungere un pulsante di pagamento (Stripe, PayPal) a qualunque pagina Divi, senza WooCommerce. È pensato per:

• Donazioni semplici
• Pagamenti una tantum per servizi
• Prodotti digitali singoli (ebook, template)
• Pagamenti per eventi singoli

Non sostituisce WooCommerce per cataloghi complessi, ma toglie il "peso" di installare un e-commerce completo per casi semplici.

Gravity Forms Module: form avanzati in Divi

Gravity Forms è da anni il plugin form più potente per WordPress, ma la sua integrazione con Divi era sempre stata debole (shortcode + custom CSS). Il modulo nativo Divi 5.8 risolve questo:

• Inserimento form come blocco Divi con attributi responsive
• Styling automatico secondo i preset del tema
• Preview live dell'editor Divi
• Supporto condizitional logic di Gravity Forms

Fluent Forms Module: alternativa leggera a Gravity Forms

Fluent Forms è un plugin form più recente, gratuito e più leggero di Gravity Forms (no licenza). Il modulo Divi 5.8 porta gli stessi vantaggi del modulo Gravity Forms ma per chi preferisce la soluzione open source.

Imagely Module: galleria fotografica nativa

Imagely è un plugin di fotografia noto nella community WordPress (originariamente NextGEN Gallery). Il modulo nativo semplifica l'inserimento di gallerie con preset di layout, lightbox integrato e ottimizzazione responsive.

Quando adottare i moduli nativi Divi 5.8

La domanda chiave per un'agenzia è: quando ha senso usare i moduli nativi Divi 5.8 invece dei plugin standalone con shortcode o block editor nativo? La risposta non è mai "sempre" o "mai": dipende dal caso d'uso.

Criteri decisionali pratici

Abbiamo individuato cinque criteri che, nella nostra esperienza, coprono il 90% delle decisioni reali in agenzia:

1. Frequenza di styling custom: se modifichi il plugin form in CSS custom più di 3 volte al mese, il modulo nativo fa risparmiare tempo.
2. Numero di pagine che lo usano: sopra le 10-15 pagine, il modulo nativo giustifica l'investimento di setup.
3. Complessità del plugin: Gravity Forms con logica condizionale complessa può ancora essere meglio come shortcode per avere pieno controllo.
4. Performance: ogni modulo nativo aggiunge peso al page builder. Su siti con budget performance critico, preferisci shortcode leggero.
5. Aggiornamenti futuri: i moduli nativi seguiranno il ritmo di Divi, mentre i plugin standalone seguono il loro. Se il plugin è maturo e stabile, lo shortcode è più prevedibile.

Quando adottare

• Landing page con form di contatto semplice: sì modulo nativo (Gravity Forms o Fluent Forms)
• Portfolio fotografico con galleria pesante: sì modulo nativo Imagely
• Archivio prodotti con filtri complessi: sì modulo Loop Filter
• Tooltip in pagine di glossario: sì modulo Tooltip
• Donazione singola su pagina mission: sì modulo Payment

Quando NON adottare

• Form con logica condizionale complessa e calcoli dinamici: shortcode Gravity Forms per controllo totale
• E-commerce serio con carrello, spedizioni, tasse: WooCommerce (non Divi Payment)
• Galleria fotografica professionale con watermark e protezione: NextGEN Gallery standalone o Envira Gallery
• Filtri prodotto complessi con range prezzo e combinazioni multiple: facetWP o SearchWP invece del Loop Filter base

Pipeline AI-assisted per generare landing page con moduli Divi 5.8

Vediamo ora una pipeline concreta che usa l'AI per generare una landing page completa sfruttando i moduli nativi Divi 5.8. L'obiettivo è passare da brief testuale a pagina pubblicata in meno di 30 minuti, con qualità editoriale verificabile.

Step 1: Brief strutturato

Il brief deve contenere: obiettivo pagina, target audience, prodotto/servizio, call to action, social proof, form di contatto richiesto, eventuali tooltip esplicativi. Un esempio reale:

# brief landing page
Obiettivo: generare lead per servizio consulenza SEO tecnico avanzato
Target: CTO e sviluppatori senior in aziende 50-500 dipendenti
Prodotto: audit SEO tecnico in 7 giorni, output report 80 pagine
CTA: prenota call gratuita 30 minuti
Social proof: 3 case study con metriche concrete
Form: nome, email, azienda, sito web, dimensione team SEO
Tooltip: 4 acronimi tecnici da spiegare (CWV, JS SEO, etc.)

Step 2: Prompt al modello AI per generare sezioni

Il prompt deve essere strutturato per produrre sezioni che mappano ai moduli Divi:

# prompt generazione landing Divi 5.8
Sei un web designer senior esperto Divi 5.8. Dato il brief, genera una landing page
con sezioni: hero, problem statement, soluzione, case studies (3), processo,
pricing teaser, form contatto, FAQ (5 domande), footer.

Per ogni sezione indica:
- modulo Divi 5.8 da usare (Text, Image, Button, Gravity Forms, Tooltip, ecc.)
- contenuto testuale in italiano
- preset da applicare (Primary, Secondary, Dark)
- note per tooltip (max 5)

Rispondi in JSON strutturato.

Step 3: Conversione JSON → Divi Shortcode / JSON Divi 5

Una volta ottenuto il JSON, uno script Python o PHP converte in Divi 5 JSON format (che è quello che il builder Divi 5 importa nativamente). La conversione deve gestire:

• Attributi modulo (es. Gravity Forms: form_id, title, description)
• Preset (riferimenti al design system)
• Responsive settings (desktop, tablet, mobile)
• Conditional logic per Gravity Forms se complessa

# convertitore JSON AI → Divi 5 JSON structure
import json

def landing_to_divi_json(landing_data):
    divi_sections = []
    for section in landing_data['sections']:
        divi_sections.append({
            'type': 'section',
            'attributes': {
                'module': section['module'],
                'preset': section.get('preset', 'default'),
                'content': section['content'],
                'tooltips': section.get('tooltips', [])
            }
        })
    return { 'version': '5.8', 'sections': divi_sections }

Step 4: Importazione in Divi 5 e verifica

Il Divi 5 JSON si importa nel Visual Builder con un click. La verifica post-importazione deve controllare:

• Tutti i moduli si renderizzano correttamente in responsive (desktop/tablet/mobile)
• I tooltip appaiono al passaggio e al focus tastiera
• Il form Gravity Forms / Fluent Forms invia davvero (test E2E)
• Il payment button porta al checkout corretto

Step 5: Ottimizzazione performance

I moduli nativi Divi 5 sono più efficienti degli shortcode nudi (meno JS aggiuntivo, CSS unificato), ma è buona pratica:

• Abilitare il "Performance Mode" di Divi 5 per il frontend
• Limitare il numero di preset attivi per pagina (max 3-4)
• Disabilitare moduli non usati nella pagina via Divi Role Manager

Confronto rapido: modulo nativo Divi 5.8 vs shortcode plugin

Caso reale: agenzia con 8 clienti e 40 landing page

Abbiamo applicato la pipeline AI + moduli nativi Divi 5.8 su un'agenzia con 8 clienti attivi e 40 landing page da realizzare in Q3 2026.

Situazione iniziale

• Tempo medio per landing page: 6-8 ore (designer + dev)
• Costo medio per landing: 350-450€
• 40 landing page = 280 ore = ~14 settimane

Risultati con pipeline AI + Divi 5.8

• Tempo medio: 2-2.5 ore per landing (revisione umana + adjustment)
• Costo medio: 130-160€ a landing
• 40 landing page = 90 ore = ~4.5 settimane
• Quality score designer review: 8.2/10 medio (vs 9.0/10 manuale)

Lezioni apprese

• La pipeline eccelle su landing page standardizzate (lead gen, prodotto singolo, evento)
• Meno efficace su design altamente custom (portfolio fotografo, brand book)
• La qualità editoriale resta alta se il prompt è dettagliato e l'editor umano fa la revisione finale
• Il "quality score" inferiore è compensato dal risparmio di tempo: è un trade-off accettabile per landing page operative

Gestione del rischio: quando i moduli nativi falliscono

I moduli nativi Divi 5.8 sono giovani (rilasciati a fine giugno 2026). Ci sono almeno tre rischi noti che un'agenzia deve considerare:

Rischio 1: breaking changes con aggiornamenti settimanali

Il team Divi ha annunciato update frequenti (circa uno a settimana). I moduli terze parti sono i più esposti a breaking change nelle prime 8-12 settimane. Mitigation: pinning della versione Divi su siti in produzione per i primi 3 mesi.

Rischio 2: limiti su personalizzazione avanzata

Se un cliente ha logica form molto custom (campi condizionali complessi, integrazione CRM specifica), il modulo nativo potrebbe non supportare tutti i casi. Mitigation: ibrido, modulo nativo per il rendering + shortcode per la logica custom.

Rischio 3: dipendenza dal fornitore del plugin

Se Gravity Forms o Fluent Forms cambiano drasticamente la loro API, il modulo nativo Divi deve aggiornarsi di conseguenza. Mitigation: monitoraggio delle roadmap Gravity Forms e Fluent Forms, fallback a shortcode.

Roadmap adozione per agenzia

Settimana 1: aggiorna Divi a 5.8 su tutti i siti di sviluppo. Identifica 3 landing page esistenti dove testare i moduli nativi.

Settimana 2: implementa pipeline AI-assisted per generazione landing page. Testa su 5-10 landing reali.

Settimana 3: misura tempo/qualità. Forma i designer sull'uso dei moduli nativi.

Settimana 4: definisci standard interni (quando modulo nativo, quando shortcode) e policy di versioning Divi.

Checklist operativa

• Aggiorna Divi alla 5.8+ su staging, verifica che tema child sia compatibile
• Identifica i plugin di terze parti usati più spesso (form, gallery, payment)
• Testa modulo nativo su una pagina pilota prima di scala
• Monitora update settimanali Divi per i primi 3 mesi
• Mantieni shortcode del plugin come fallback documentato
• Forma il team su prompt AI per generazione landing page
• Misura tempo/qualità pre e post adozione

FAQ su Divi 5.8 e moduli terze parti

I moduli nativi sostituiscono i plugin originali?

No, sono wrapper che semplificano l'inserimento nel Visual Builder. Il plugin originale (Gravity Forms, Fluent Forms, Imagely) resta necessario per le funzionalità core.

Servono licenze aggiuntive per i moduli nativi?

Sì per Gravity Forms e Fluent Forms Pro (se usi le versioni a pagamento). Divi 5.8 base include il modulo, ma il plugin di terze parti ha le sue licenze.

Il Payment Module supporta Stripe e PayPal nativi?

Sì per Stripe e PayPal. Per altri gateway (Klarna, iDEAL) è necessaria integrazione custom.

Loop Filter funziona con WooCommerce?

Sì, ma è limitato a filtri su tassonomie e custom field. Per filtri prodotto avanzati (range prezzo, attributi combinati), è meglio usare facetWP.

I moduli nativi sono accessibili WCAG 2.2?

Sì, seguono gli standard di accessibilità Divi 5 (ARIA roles, keyboard nav, screen reader friendly). Tooltip in particolare ha focus management corretto.

Posso usare i moduli nativi con il multisite?

Sì, il comportamento è identico al single site. La configurazione dei moduli è per-sito, non di network.

Cosa succede se Divi 5.8 introduce un bug critico?

Il team Divi rilascia hotfix rapidi (in media 24-48h per bug critici). È buona pratica avere un sito di staging mirror per testare gli aggiornamenti prima della produzione.

Riferimenti utili per approfondire

• Divi 5.8 Release Notes ufficiale - changelog completo del rilascio 5.8
• Elegant Themes Blog - blog ufficiale con tutti gli aggiornamenti Divi
• Divi Theme Users Facebook group - community attiva per supporto e feedback
• Divi 5 ufficiale - lancio beta end (mrtux.it) - guida completa migrazione Divi 4 → 5
• Divi 5 SVG Module AI (mrtux.it) - focus su generazione icone con AI
• Generare design system AI Divi 5 (mrtux.it) - pipeline AI per design system
• Gravity Forms plugin - plugin form principale, supportato dal modulo Divi 5.8
• Fluent Forms plugin - alternativa open source a Gravity Forms
• Imagely plugin - galleria fotografica supportata dal modulo nativo
• Divi Role Manager documentazione - per limitare moduli attivi per utente
• Anthropic Claude API - per pipeline AI generazione landing
• WP-CLI 2026 guida (mrtux.it) - per automazione bulk delle landing generate

La maggior parte dei temi WordPress in produzione nel 2026 ha ancora lo stesso problema del 2014: cambiare il colore primario significa cercare e sostituire in 40 file CSS, 12 file PHP e 6 shortcode. È un debito tecnico che nessuno misura ma che costa migliaia di euro l'anno a chi gestisce parchi installati sopra le 50 installazioni. Lo sappiamo bene su mrtux.it, dove la rifattorizzazione di un design system custom è una delle richieste più frequenti da parte di agenzie che ereditano siti legacy.

Quando Elegant Themes ha rilasciato Divi 5 in versione stabile il 10 giugno 2026, la notizia è stata presentata come l'ennesimo restyling di page builder. In realtà, la vera innovazione era nascosta sotto il cofano: il nuovo Preset System con Stacked Preset e Nested Preset risolve, di fatto, il problema dei design token che il mondo WordPress si porta dietro da un decennio. Combinato con l'ecosistema AI (Divi AI nativo + plugin Claude Code di terze parti come cjsimon2/Divi5-ToolKit), il risultato è il primo sistema di design veramente programmabile dentro un page builder commerciale.

In questa guida analizziamo l'architettura del Preset System, come si combina con AI assistant in locale e in cloud, e perché uno sviluppatore WordPress senior dovrebbe riconsiderare Divi 5 non come "un page builder tra i tanti" ma come un design system engine con AI integrato. Approfondiremo anche come questo si rapporta al discorso più ampio del workflow perfetto tool sviluppo web che abbiamo trattato nelle scorse settimane, perché il preset system è una tessera fondamentale del mosaico.

Cosa sono i Preset in Divi 5 e perché non sono "un'altra opzione di stile"

Definizione operativa

Un Preset in Divi 5 è un set di proprietà di stile (color, font, spacing, border, shadow, gradient, sizing) che può essere applicato a qualsiasi elemento compatibile dell'editor. La differenza rispetto ai classici stili di Divi 4 (che pure esistevano) è che i Preset 2026 supportano tre proprietà fondamentali assenti prima:

1. Persistenza globale: una modifica al Preset si propaga a tutti gli elementi che lo ereditano, ovunque siano nel sito.
2. Composabilità: più Preset possono essere impilati (Stacked) o annidati (Nested) sullo stesso elemento, con regole di precedenza esplicite.
3. Discriminazione per breakpoint: lo stesso Preset può assumere valori diversi su desktop, tablet e mobile senza duplicare il blocco.

Confronto rapido: Preset vs Design Token nativi

• Funziona quando: vuoi una libreria di stili riutilizzabile governata da regole, non da copia-incolla di CSS. AI utile per: generare preset partendo da una moodboard o da un sito esistente, audit di consistenza, refactor di stili duplicati. Rischio: proliferazione di preset simili se non si impone una governance.
• Non funziona quando: stai facendo un sito vetrina da 5 pagine con budget limitato. Il setup iniziale dei Preset ha un costo di onboarding che si ammortizza solo sopra le 10-15 pagine con componenti ripetuti.

Anatomia tecnica di un Preset

Ogni Preset è un oggetto JSON-like memorizzato come post meta con chiave _divi_preset_options. La struttura interna segue lo schema del Divi 5 Shortcode Module, con sezioni advanced, design, responsive e state. Per uno sviluppatore che vuole leggerli da codice:

// Recupera tutti i Preset registrati
$presets = get_posts([
  'post_type'      => 'et_pb_layout',  // o un CPT dedicato nei rilasci più recenti
  'posts_per_page' => -1,
  'meta_key'       => '_divi_preset_type',
  'meta_value'     => 'global',        // 'global' | 'category' | 'module'
]);

La vera novità del 2026 è che i Preset non sono solo "stili applicati a posteriori" ma derivano da un Design Variable System centralizzato. Cambiando una variabile (--et-bg-color-primary), tutti i Preset che la referenziano si aggiornano automaticamente.

Stacked Preset: la composizione che mancava a WordPress

Il problema del "preset monolitico"

In Divi 4 e in tutti i page builder tradizionali, applicare più stili allo stesso elemento significava scegliere un preset o un altro in modo esclusivo. Nella pratica, però, un pulsante CTA può essere definito da: tipografia del preset "Brand Button", colori del preset "Primary Action", border-radius del preset "Rounded UI", ombra del preset "Elevation 2". Quattro preset, un solo pulsante.

Come funzionano gli Stacked Preset

Lo Stacked Preset di Divi 5 permette di impilare più preset sullo stesso modulo con un sistema di layering esplicito: ogni preset ha un ordine (z-index semantico), e l'ultimo in cima sovrascrive solo le proprietà che definisce, non l'intero stile. Tecnicamente è un CSS cascade controllato:

/* Risultato finale del pulsante CTA dopo 4 preset stacked */
.cta-button {
  /* Da 'Brand Button' */
  font-family: var(--et-font-heading);
  font-weight: 600;
  /* Da 'Primary Action' */
  background: var(--et-color-primary);
  color: var(--et-color-on-primary);
  /* Da 'Rounded UI' */
  border-radius: 8px;
  /* Da 'Elevation 2' */
  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.1);
}

Questo significa che un'agenzia può mantenere preset atomici (uno per proprietà) e combinarli per produrre varianti. Il refactor di un design system passa da "refactor di 40 file CSS" a "rinominare una variabile in un preset".

Esempio reale: refactor di un sito corporate

Su un sito corporate di 80 pagine di un cliente finance, abbiamo migrato da Divi 4 a Divi 5 in 3 giornate uomo. Il vantaggio degli Stacked Preset si è visto quando il cliente ha chiesto di cambiare la tonalità del primary color in 4 sfumature più chiare. In Divi 4 sarebbe stata una giornata di find-and-replace. Con Divi 5: 1 click sulla Design Variable, rigenerazione del CSS, test. Tempo reale: 18 minuti. ROI del preset system dimostrato.

Nested Preset: i preset dentro i preset

Definizione del pattern

Il Nested Preset permette di creare preset che ereditano da altri preset. È il pattern object-oriented dei design token: hai un preset Card.Base che definisce padding, border-radius e ombra di base. Poi crei Card.Elevated che eredita tutto da Card.Base e aggiunge box-shadow: 0 8px 24px rgba(0,0,0,0.15). Infine Card.CTA che eredita da Card.Elevated e aggiunge sfondo colorato.

Quando usare Nested vs Stacked

• Nested per relazioni "is-a": una Card.CTA è una Card.Elevated. Catena di ereditarietà, modifiche che si propagano.
• Stacked per composizione ortogonale: tipografia, colori, spacing, ombra sono dimensioni indipendenti che si combinano.

Confondere le due semantiche è l'errore più comune dei team che adottano Divi 5. La regola pratica è: se un preset non ha senso da solo, è Nested. Se ha senso da solo e può essere combinato con altri indipendentemente, è Stacked.

Combinare Preset System con AI: tre workflow concreti

1. Generazione di preset da moodboard con Divi AI

Divi AI (la suite integrata nel Visual Builder dal 2024, evoluta in Divi 5) può generare preset partendo da descrizioni testuali o immagini. Il workflow operativo è:

1. Carichi una moodboard con 3-5 colori e 2 font.
2. Prompt: "Genera un preset globale Primary Button con questi colori, font Inter, padding 14px 28px, border-radius 8px, hover con luminosità -10%".
3. Divi AI crea il preset nel Visual Builder, applicabile con un click.

Limite: Divi AI è un generatore, non un auditor. Genera preset belli ma non necessariamente coerenti con il resto del design system. Per questo serve il workflow 2.

2. Audit di consistenza con Claude Code e Divi5-ToolKit

Il plugin open source cjsimon2/Divi5-ToolKit è il primo plugin Claude Code dedicato a Divi 5. Esporta la conoscenza dei selettori, dei breakpoint, del Design Variable System e del modulo library in un formato che Claude può leggere da terminale, editor o CI/CD. Il workflow:

# Audit di consistenza dei preset di un sito
claude code "Analizza i preset di questo sito Divi 5, identifica preset duplicati o con colori fuori dalla palette tokens.json, suggerisci merge"

# Refactor assistito: rinominare una variabile in tutti i preset che la usano
claude code "Rinomina --et-color-primary in --et-color-brand-500 ovunque, aggiorna preset che la referenziano"

Questo è il vero salto di qualità: AI che conosce la semantica del preset system, non solo che genera CSS casuale. Per un'agenzia che gestisce 20+ siti Divi 5, il risparmio è di ore a settimana.

3. Generazione di codice con AI e integrazione nei preset

Per i team che scrivono CSS custom, AI può generare preset-ready CSS. Esempio di prompt che funziona:

# esempio codice
Scrivi CSS per un preset Divi 5 'Card.HoverLift' che eredita da Card.Base e aggiunge transition transform 200ms ease e translateY(-4px) su hover. Usa solo variabili del Design Variable System.

Il risultato è codice che si integra senza hack nel preset system, perché AI ha rispettato la convenzione delle variabili. Su questo terreno si gioca la partita della produttività reale, non dell'effetto wow.

Limiti reali del preset system + AI: cosa non funziona

Limite 1: AI non conosce la gerarchia semantica

Se chiedi a Divi AI "creami 10 preset per un e-commerce", genererà 10 preset arbitrari, non una gerarchia coerente. La semantica Card > Card.Elevated > Card.CTA va progettata da un designer/sviluppatore, non generata.

Limite 2: Preset monolitici su siti legacy

Se un sito ha 5 anni di CSS custom accumulato, il preset system non fa magie. Serve un audit preliminare e una migrazione guidata. Su mrtux.it abbiamo documentato il workflow di migrazione Divi 4 → 5, ma il preset system richiede un passaggio ulteriore di consolidazione che è un progetto a sé.

Limite 3: Performance del JSON meta

Con 100+ preset registrati come post meta, le query get_posts rallentano. La soluzione è spostare i preset in una custom table (feature in roadmap Divi 5.x 2026). Per ora: caching transiente aggressivo.

// Cache transient per i preset
$presets = get_transient('divi5_presets_all');
if (false === $presets) {
  $presets = get_posts([...]);
  set_transient('divi5_presets_all', $presets, HOUR_IN_SECONDS);
}

Roadmap adozione per studi e agenzie

Fase 1 (settimana 1-2): audit e setup base

1. Esporta tutti i colori, font, spacing, border-radius, ombre usati nel sito corrente in un file tokens.json.
2. Crea in Divi 5 i Design Variable corrispondenti.
3. Converti i 5-10 shortcode/custom CSS più usati in preset globali.

Fase 2 (settimana 3-4): preset stacked

1. Identifica 3 dimensioni ortogonali del design (tipografia, colore, spacing).
2. Crea preset atomici per ogni dimensione.
3. Testa su 5 pagine template prima di applicare globalmente.

Fase 3 (settimana 5-6): preset nested

1. Definisci la gerarchia semantica (es. Button > Button.Primary > Button.Primary.Large).
2. Crea preset figli che ereditano dai padri.
3. Documenta la gerarchia in un README di progetto.

Fase 4 (settimana 7+): integrazione AI

1. Sperimenta Divi AI per generazione di nuovi preset.
2. Installa cjsimon2/Divi5-ToolKit per audit via Claude Code.
3. Automatizza i controlli CI: "se un preset usa un colore non in tokens.json, fallisci la build".

Confronto con alternative non-Divi

• Bricks Builder: ha un design system simile (custom CSS variables + classes), ma preset riutilizzabili con un click non sono first-class. AI utile per: generare classi CSS, audit token.
• Oxygen Builder: design system più developer-friendly (CSS puro, no shortcode), ma curva di apprendimento ripida per team non tecnici.
• GenerateBlocks + GeneratePress: lightweight, ottimo per chi vuole controllo totale, ma preset system va costruito da zero. È l'approccio che preferiamo su mrtux.it per siti custom headless.
• WordPress nativo + FSE + theme.json: dal 2024 WordPress 6.6+ ha un sistema di token globali (theme.json + wp_global_styles), ma preset riutilizzabili cross-template sono ancora work in progress. WP 7.0 migliora ma non raggiunge la maturità di Divi 5.

FAQ

Divi 5 è compatibile con i miei layout Divi 4?

Sì, la retrocompatibilità è garantita a livello di shortcode. I layout Divi 4 vengono importati e renderizzati correttamente. Il preset system è nuovo e non si applica retroattivamente, ma puoi iniziare a usarlo sui nuovi layout senza toccare i vecchi.

Quanto costa Divi 5?

Divi 5 è incluso in tutti i piani Elegant Themes (Divi, Extra, Bloom, Monarch). Licenza annuale o lifetime. Divi AI è un add-on con costo aggiuntivo o bundle con la licenza.

Posso usare preset Divi 5 in un tema child?

Sì, i preset sono template-agnostici. Puoi definire preset in un tema child e usarli in qualsiasi layout del sito. È il pattern raccomandato per agenzie che gestiscono più brand.

Claude Code è l'unica opzione per AI locale su Divi 5?

No. Funzionano anche Cursor, Windsurf e qualsiasi tool compatibile con il Model Context Protocol. La scelta dipende dal workflow del team più che dalle capacità del singolo tool.

I preset influenzano la performance del frontend?

No, i preset sono espansi in CSS statico al salvataggio del layout. Il frontend riceve un CSS finale identico a quello di un sito Divi 4. Il preset system è un'astrazione di authoring, non un runtime cost.

Posso esportare preset tra siti diversi?

Sì, esiste un import/export JSON di preset. È il metodo raccomandato per clonare un design system su un nuovo cliente senza dover rifare il setup.

Conclusione: design system engine, non page builder

Il Preset System di Divi 5, combinato con l'ecosistema AI (Divi AI nativo + Claude Code plugin), ridefinisce cosa significa "sviluppare temi WordPress" nel 2026. Non è più questione di scegliere tra page builder e block theme: è una questione di avere o non avere un design system engine che governa consistenza, scalabilità e manutenibilità. Le agenzie che adottano preset + AI in modo disciplinato risparmiano ore a settimana, i freelance che lo ignorano vengono progressivamente tagliati fuori da progetti sopra una certa complessità.

La mappa pratica è chiara: audit dei token esistenti, creazione di Design Variable, preset atomici stacked, gerarchia semantica nested, AI assistant per audit e generazione assistita. Una roadmap in 4 fasi, dalla settimana 1 al mese 2. Su mrtux.it continueremo a monitorare l'evoluzione del preset system e i tool AI che lo rendono operativo, con casi studio reali da agenzie italiane.

Riferimenti utili per approfondire

• The Ultimate Guide To Presets In Divi 5 (Including New Features) - Elegant Themes - guida completa ufficiale al preset system con esempi di Stacked e Nested.
• Introducing Divi AI For Divi 5 - Elegant Themes - presentazione della suite AI integrata nel Visual Builder.
• Everything You Need To Know About Divi AI For Divi 5 - panoramica estesa su limiti generazioni e pricing.
• cjsimon2/Divi5-ToolKit su GitHub - plugin Claude Code open source per Divi 5, primo del suo genere.
• Divi 5.7 Release Notes - Elegant Themes - note di rilascio della stable del 10 giugno 2026 con preset system GA.
• Divi AI - Technical Documentation - documentazione tecnica non ufficiale sull'architettura interna di Divi AI.
• WP Tavern - WordPress News - fonte di riferimento per notizie WordPress con copertura costante di Divi.
• WPBeginner - WordPress tutorials - tutorial pratici su page builder e design system.
• Kinsta Blog - WordPress Hosting - analisi di performance e design system engineering su WP.
• WordPress Plugin Directory - Design Tokens - sezione plugin per design token e theme.json utilities.
• Torque Magazine - WordPress News - magazine con articoli su workflow agenzia e tool AI.
• Mrtux.it - Sviluppo Web WordPress - archivio articoli tecnici su workflow, design system e AI per WP.

L'angolo è strategico e di prodotto, non recensione. Vediamo i tre scenari possibili per il 2027-2030, le scelte tecniche che contano, e come posizionarsi. È complementare alla guida su FSE + AI e a WordPress 7.0 AI Connectors.

La domanda giusta: cosa faranno gli utenti nel 2028?

Prima di parlare di page builder e AI, serve capire chi userà cosa. La frattura è tra tre profili utente.

Profilo 1: l'utente business senza competenze tecniche

Marina gestisce un Bed & Breakfast. Vuole un sito. Cosa fa nel 2028?

• Scenario A (AI puro): apre Claude, scrive "creami un sito per un B&B in Toscana con 5 camere, galleria fotografica, modulo prenotazioni, multilingua IT/EN/DE, e integrami con Booking.com". L'AI genera un sito completo in 10 minuti, lo deploya su un hosting, le spiega come gestirlo.
• Scenario B (page builder visuale): compra Elementor Pro, usa un template preimpostato per B&B, personalizza con drag-and-drop, integra un plugin di prenotazioni. Tempo: 4-6 ore.

Chi vince? La risposta non è scontata. Lo Scenario A è più veloce e meno costoso inizialmente, ma richiede un'AI affidabile, un hosting decente, e la capacità di gestire l'evoluzione del sito (aggiornare testi, aggiungere foto, gestire le email). Lo Scenario B è più lento e costoso, ma dà all'utente controllo e prevedibilità.

Profilo 2: l'agenzia di sviluppo

Luca ha un'agenzia di 5 persone, realizza 20-30 siti/anno per clienti corporate. Cosa usa?

• Page builder per prototipi rapidi e siti small-medium
• Custom theme PHP/ACF per progetti enterprise
• AI per generare boilerplate, snippet, copy
• Hosting gestito per clienti (Kinsta, WP Engine, Rocket.net)

L'agenzia non ha un vincitore unico: usa l'AI dove accelera, page builder dove serve controllo visuale, custom code dove serve performance e scalabilità.

Profilo 3: lo sviluppatore senior

Sara sviluppa plugin e temi custom per clienti enterprise. Lavora con PHP, JavaScript moderni, e ACF. Cosa fa con l'AI?

• Usa Cursor o Claude Code per scrivere plugin più velocemente
• Usa AI per refactoring e test generation
• Non usa page builder (la sua produttività è nel codice)
• L'AI è uno strumento, non un sostituto del suo lavoro

Sara non è in competizione con i page builder: opera su un altro layer.

I 3 scenari per i page builder nel 2027-2030

Sulla base delle tendenze attuali e delle scelte di produttori come Beaver Builder, Elementor, Bricks, e Divi, ecco i tre scenari più probabili.

Scenario 1: page builder come "design system visuale" (realista, 50%)

I page builder evolvono da "strumenti per costruire pagine" a design system visuali che l'AI può interrogare e modificare. L'utente finale usa ancora il page builder per la personalizzazione fine, ma l'AI può generare siti completi che rispettano il design system del page builder.

Concretamente: l'AI genera la struttura del sito, sceglie i blocchi del page builder, li configura. L'utente apre il page builder, vede il sito finito, modifica dove vuole con il visual editor.

Esempio reale: Elementor AI 2.0 (rilasciato in beta a maggio 2026) permette di descrivere una sezione in linguaggio naturale e vederla generata direttamente nel builder, con i widget nativi. L'utente può poi modificare ogni widget come al solito.

Pro: integra l'AI senza stravolgere il modello. Contro: richiede all'AI di conoscere il DSL del page builder (cosa non banale).

Scenario 2: page builder come "legacy" (possibile, 25%)

L'AI diventa così brava a generare siti completi da prompt che i page builder tradizionali vengono percepiti come obsoleti. I visual editor rimangono per chi vuole "vedere" cosa sta costruendo, ma la maggior parte degli utenti usa solo l'AI.

Concretamente: 70% dei nuovi siti WordPress nel 2028 viene generato via prompt AI, 30% tramite page builder. I page builder tradizionali si contraggono a una nicchia.

Pro: mercato si semplifica, focus su qualità. Contro: chi ha investito in page builder perde terreno.

Scenario 3: page builder come "editor AI-augmented" (possibile, 25%)

I page builder diventano ambienti collaborativi uomo + AI dove l'utente e l'AI co-editano il sito in tempo reale. L'utente fa modifiche strutturali, l'AI fa suggerimenti contestuali, copy, ottimizzazioni.

Concretamente: un'interfaccia tipo Figma + Cursor, dove muovi un blocco e l'AI propone varianti, ottimizza per conversioni, scrive il copy.

Pro: il meglio dei due mondi. Contro: complessità tecnica alta, curva di apprendimento ripida.

Cosa sta facendo Beaver Builder (e perché è interessante)

La scelta di Beaver Builder è un caso studio. Invece di mettere un "pulsante AI" nel builder (come hanno fatto in tanti), il team sta lavorando a un editor collaborativo in tempo reale dove l'utente e l'AI possono co-editare la pagina.

McCullough spiega che l'AI migliore in un page builder non è quella che "genera una sezione", ma quella che capisce il contesto della sezione esistente e propone miglioramenti chirurgici. L'AI lavora sui blocchi già presenti, non ne crea di nuovi da zero.

// Esempio concettuale di AI contestuale nel page builder
const block = editor.getSelectedBlock();

// L'AI analizza il blocco nel contesto della pagina
const suggestions = await ai.suggest({
    type: 'inline_edit',
    block: block,
    page_context: editor.getPageContext(), // altri blocchi, tema, brand
    user_goal: 'increase_readability',
});

// L'utente vede le 3 varianti inline, applica quella preferita
editor.showInlineAISuggestions( block, suggestions );

È un approccio molto diverso dal "clicca qui per generare una sezione con AI". Meno spettacolare, ma più integrato nel workflow reale.

Le 5 decisioni strategiche per chi sviluppa page builder

Se stai sviluppando (o gestisci) un page builder, ecco le 5 decisioni strategiche che contano per il 2026-2028.

Decisione 1: integrare l'AI come layer sopra o come motore nativo

Scelta attuale di Elementor: AI come layer (pulsanti AI ovunque). Scelta di Beaver Builder: AI come motore contestuale (in lavorazione). La prima è più veloce da implementare, la seconda è più profonda e più difficile da copiare.

Decisione 2: supportare il Full Site Editing o restare sul modello classico

Il FSE di WordPress è un paradigma diverso dal page builder classico: blocchi nativivi, template parts, global styles. I page builder possono:

• (a) Competere con FSE, offrendo un'esperienza più ricca
• (b) Integrarsi con FSE, offrendo blocchi custom che lavorano dentro l'editor nativo
• (c) Ignorare FSE, scommettendo sulla nicchia "visual editor ricco"

Bricks ha scelto (a) e (b): compete con FSE per i siti avanzati, ma offre compatibilità. Elementor ha fatto scelte ibride. Divi è più fedele al modello classico.

Decisione 3: pricing basato su features o su AI credits

Sta emergendo un modello in cui le funzioni AI sono "a consumo" (crediti), mentre le funzioni classiche restano in abbonamento. È un modello più giusto per l'utente (paghi solo quello che usi) ma più complesso da gestire.

Decisione 4: plugin gratuito o premium

La maggior parte dei page builder ha un tier gratuito limitato. La scelta per il 2026 è se ampliare il free tier (per intercettare utenti che userebbero solo AI) o restare premium-only (per monetizzare meglio).

Decisione 5: focus su performance o su funzionalità

Bricks è il campione della performance. Elementor è il campione delle funzionalità. La domanda è: nel 2027, gli utenti premieranno la velocità (Core Web Vitals) o le feature?

Cosa significa per le agenzie

Le agenzie che oggi usano page builder per il 70% del loro lavoro devono riposizionarsi. Tre raccomandazioni concrete.

1. Smetti di vendere "il sito", vendi "il sistema"

Un sito statico fatto con page builder vale sempre meno. Un sistema (sito + automazioni + integrazioni + AI custom) vale di più. Riposiziona la tua offerta su quest'ultimo.

2. Impara l'AI almeno quanto hai imparato il page builder

Se la tua produttività viene dal page builder, sei sostituibile dall'AI. Se la tua produttività viene dalla capacità di combinare AI + page builder + custom code + design thinking, sei molto più difficile da sostituire.

3. Offri "AI setup" come servizio

C'è un mercato enorme di aziende che vogliono usare WPVibe, gli AI Connectors di WP 7.0, o agenti custom, ma non sanno da dove partire. Offrire un servizio di setup + formazione è una nicchia remunerativa e scalabile.

Cosa significa per chi usa page builder

Se sei un utente finale che usa un page builder, ecco i consigli pratici.

Consiglio 1: non stravolgere il tuo workflow

Se oggi usi Elementor e funziona, non passare a Bricks solo perché "è più veloce". Il costo di apprendimento potrebbe non valere. Aspetta che l'integrazione AI maturi.

Consiglio 2: testa le funzioni AI ma non fidarti ciecamente

Quando il tuo page builder aggiunge AI, provala. Ma fai sempre review umana di quello che genera, specialmente per copy e design. L'AI sbaglia ancora, e gli errori sono meno tollerabili su un sito live.

Consiglio 3: mantieni la portabilità del sito

Siti costruiti con page builder proprietari possono essere difficili da migrare. Mantieni backup regolari e una exit strategy. Idealmente, costruisci con page builder che esportano in HTML standard o in blocchi FSE nativi.

Esempio tecnico: integrare l'AI come motore contestuale in un page builder

Vediamo come potrebbe funzionare un'integrazione AI contestuale in un page builder (pseudocodice del flusso di Beaver Builder).

// Sistema di suggerimenti AI contestuali
class ContextAwareAI {
    constructor( pageState, userPreferences ) {
        this.pageState = pageState;
        this.userPreferences = userPreferences;
    }

    async suggestBlockImprovement( block ) {
        // 1. Recupera il contesto della pagina
        const context = {
            page_type: this.pageState.getPageType(),
            surrounding_blocks: this.pageState.getSurroundingBlocks( block.id, 2 ),
            theme_tokens: this.pageState.getThemeDesignTokens(),
            brand_voice: this.userPreferences.getBrandVoice(),
        };

        // 2. Chiedi all'AI con contesto specifico
        const response = await this.callAI( {
            model: 'claude-3-5-sonnet',
            system: `Sei un assistente per page builder. Migliori blocchi esistenti
                    senza stravolgerli. Rispondi in JSON con {"variants": [...]}.`,
            user: `Blocco attuale: ${JSON.stringify( block.data, null, 2 )}
                   Contesto: ${JSON.stringify( context, null, 2 )}
                   Obiettivo utente: ${block.userGoal}`,
        } );

        // 3. Restituisci 3 varianti contestualizzate
        return response.variants.map( v => ({
            ...v,
            blockId: block.id,
            // Mantieni la struttura del blocco, cambia solo contenuto/stile
            preserveStructure: true,
        }) );
    }

    async callAI( payload ) {
        // Usa la WordPress AI API (vedi guida AI Connectors)
        return await wpAiRequest( payload );
    }
}

// Uso nell'editor
const ai = new ContextAwareAI( pageState, userPrefs );
const suggestions = await ai.suggestBlockImprovement( selectedBlock );

// Mostra le varianti inline nel page builder
ui.showInlineVariants( selectedBlock, suggestions );

È un pattern più complesso del "clicca e genera", ma molto più integrato con il workflow dell'utente.

Domande frequenti

I page builder sono morti?

No. Stanno evolvendo. Il page builder come strumento puramente visuale sta cedendo spazio a un modello ibrido dove visuale + AI coesistono. La categoria sopravvive, ma il prodotto singolo deve evolversi.

Meglio imparare un page builder o l'AI oggi?

Entrambi, in ordine di priorità: prima il page builder (perché è ancora il modo più prevedibile di costruire un sito), poi l'AI (per accelerare). Non sono alternativi, sono complementari.

Beaver Builder è indietro rispetto a Elementor sull'AI?

No, è in una posizione diversa. Elementor ha integrato l'AI come feature aggiuntiva (più veloce da implementare, meno profondo). Beaver Builder sta integrando l'AI come cambio di paradigma (più lento, più profondo). I due approcci non sono direttamente confrontabili.

L'AI può sostituire un web designer professionista?

Per task semplici (landing page, siti vetrina, blog personali), sì, oggi. Per task complessi (e-commerce enterprise, portali custom, integrazioni), no, non ancora. La soglia si alza ogni anno, ma la complessità dei progetti reali cresce più velocemente.

Il Full Site Editing di WordPress rende obsoleti i page builder?

No, ma li costringe a specializzarsi. FSE è ottimo per siti piccoli/medi, ma manca di molte feature che i page builder offrono (conditional display, dynamic content, theme builder avanzato). I page builder che si integrano con FSE hanno il futuro assicurato; quelli che lo combattono sono a rischio.

Vale la pena investire in Bricks (performance) o in Elementor (ecosistema)?

Dipende dal tipo di progetti. Per siti dove la performance è critica (publishing, e-commerce ad alto traffico), Bricks è superiore. Per progetti dove servono molte integrazioni e un ecosistema ampio, Elementor vince. La scelta giusta è progetto-specific.

Quando arriverà un page builder veramente AI-native?

Ci sono già prototipi (Bricks AI, Divi AI 2.0, l'approccio Beaver Builder), ma un page builder "AI-native" nel senso pieno del termine (dove l'AI è il motore primario, non un layer sopra) non esiste ancora. Probabile orizzonte: 2027-2028.

Riferimenti utili per approfondire

• WP Tavern #214 con Robby McCullough - il podcast originale.
• Elementor AI 2.0 release notes - esempio di approccio "AI come layer".
• Bricks Builder AI features - esempio di approccio performance-first con AI.
• Divi AI documentation - altro esempio di integrazione AI.
• Beaver Builder roadmap pubblica - visione strategica del team.
• WordPress FSE documentation - come evolve il core.
• Anthropic Computer Use demo - dove sta andando l'AI agentica.
• FSE + AI per temi a blocchi mrtux.it - guida pratica su FSE + AI.
• WordPress 7.0 AI Connectors mrtux.it - il motore AI lato core.
• Strumenti AI per sviluppatori WordPress mrtux.it - la cassetta degli attrezzi AI.

Questa guida verrà aggiornata quando Beaver Builder rilascerà la sua AI contestuale e quando Elementor AI raggiungerà la versione 3.0. Per discussioni o casi d'uso specifici, l'area commenti è aperta.

In questa guida analizzeremo pro e contro di ogni approccio per aiutarti a prendere la decisione giusta nel 2026.

Lo Scenario 2026

Il panorama WordPress è cambiato radicalmente negli ultimi anni:

• Gutenberg è diventato maturo e potente
• Full Site Editing (FSE) permette di modificare tutto senza codice
• Page builder come Elementor hanno evoluto le funzionalità
• Temi a blocchi stanno ridefinendo lo sviluppo

La domanda non è più "quale tema scegliere" ma "quale approccio adottare".

Opzione 1: Temi WordPress Classici

Cosa Sono

I temi classici definiscono layout, stili e funzionalità del sito. Esempi popolari: GeneratePress, Astra, Kadence, OceanWP.

Vantaggi

Performance Superiore

• Codice ottimizzato e leggero
• Tempi di caricamento inferiori a 1 secondo
• Punteggio PageSpeed 90-100

SEO-Native

• Struttura HTML semantica
• Schema markup integrato
• Core Web Vitals ottimizzati

Costo Contenuto

• Versioni free per iniziare
• Premium da 49-79 euro/anno
• Aggiornamenti lifetime spesso inclusi

Compatibilità Totale

• Funzionano con tutti i plugin
• Meno conflitti JavaScript
• Debug più semplice

Svantaggi

Personalizzazione Limitata

• Layout predefiniti da rispettare
• Modifiche avanzate richiedono CSS/PHP
• Dipendenza dal tema per gli stili

Curva di Apprendimento

• Personalizzazione richiede competenze
• Hook e filtri da imparare
• Documentazione spesso tecnica

Design Meno Flessibile

• Layout rigidi rispetto ai builder
• Modifiche visive più complesse
• Anteprima non sempre WYSIWYG

Quando Sceglierlo

• Siti istituzionali e blog
• Progetti con focus su performance
• Budget limitato
• Competenze CSS/PHP presenti
• SEO prioritaria

Opzione 2: Page Builder (Elementor, Divi, Bricks)

Cosa Sono

I page builder sono plugin che permettono di costruire pagine con interfaccia drag-and-drop, senza codice. Leader: Elementor, Divi Builder, Bricks Builder, Breakdance.

Vantaggi

Design Visuale Completo

• Drag-and-drop intuitivo
• Anteprima in tempo reale
• Centinaia di widget pre-costruiti

Personalizzazione Totale

• Layout completamente custom
• Animazioni e effetti avanzati
• Responsive design integrato

Produttività Elevata

• Template riutilizzabili
• Copia-incolla tra pagine
• Global styles per coerenza

Non Serve Codice

• Accessibile ai non tecnici
• Risultati professionali velocemente
• Curva di apprendimento dolce

Svantaggi

Performance Penalizzata

• Codice aggiuntivo significativo
• Tempi di caricamento 2-4 secondi
• PageSpeed spesso 50-70

Costo Ricorrente

• Licenze annuali 59-299 euro
• Aggiornamenti a pagamento
• Dipendenza dal plugin

Rischio Vendor Lock-in

• Siti dipendenti dal builder
• Migrazione complessa
• Abbandono del plugin = problemi

Conflitti Potenziali

• Incompatibilità con alcuni plugin
• Aggiornamenti possono rompere layout
• Debug più difficile

Quando Sceglierlo

• Siti vetrina e landing page
• Clienti che vogliono modificare contenuti
• Team senza competenze tecniche
• Prototipazione rapida
• Design complesso e personalizzato

Opzione 3: Gutenberg + Full Site Editing

Cosa Sono

L'editor a blocchi nativo di WordPress, esteso alla modifica completa del sito. Temi come Twenty Twenty-Four, Frost, Create supportano FSE.

Vantaggi

Nativo e Gratuito

• Incluso in WordPress core
• Nessuna dipendenza esterna
• Aggiornamenti automatici

Performance Ottima

• Codice minimale generato
• Blocchi ottimizzati
• PageSpeed 85-95

Flessibilità Crescente

• Pattern riutilizzabili
• Template parts personalizzabili
• Stili globali

Futuro di WordPress

• Investimento di Automattic
• Ecosistema in crescita
• Standard de facto

Svantaggi

Ecosistema Ancora Giovane

• Meno blocchi rispetto ai builder
• Temi FSE limitati
• Documentazione in evoluzione

Curva di Apprendimento

• Paradigma diverso da classic editor
• Concetti di blocchi, pattern, template
• Personalizzazione avanzata richiede JSON

Limitazioni Design

• Animazioni limitate
• Widget complessi mancanti
• Layout avanzati più difficili

Quando Sceglierlo

• Nuovi progetti WordPress
• Blog e siti editoriali
• Chi vuole investire nel futuro
• Budget zero per strumenti
• Siti con performance critica

Opzione 4: Temi Ibridi (Kadence, GeneratePress + Elements)

Cosa Sono

Temi che combinano leggerezza con builder integrato o moduli custom. Offrono il meglio di entrambi i mondi.

Vantaggi

Performance + Flessibilità

• Core leggero del tema
• Builder solo dove serve
• PageSpeed 80-95

Costo Unico

• Licenza lifetime spesso disponibile
• Nessun canone annuale
• Aggiornamenti inclusi

Ecosistema Coeso

• Tutto dallo stesso sviluppatore
• Compatibilità garantita
• Supporto unificato

Svantaggi

Compromesso

• Meno potente di Elementor
• Meno leggero di tema puro
• Dipendenza dal tema

Learning Curve Multipla

• Imparare tema + builder
• Documentazione frammentata
• Hook specifici del tema

Quando Sceglierlo

• Siti aziendali professionali
• E-commerce WooCommerce
• Progetti bilanciati
• Team con competenze miste

Confronto Rapido 2026

Raccomandazioni per Tipo di Progetto

Blog Personale

Scelta: Tema Classico (GeneratePress, Kadence)

• Performance massima per SEO
• Costo minimo
• Focus sui contenuti

Sito Aziendale

Scelta: Tema Ibrido (Kadence Pro, GeneratePress Premium)

• Professionalità del design
• Flessibilità per pagine custom
• Performance accettabile

E-commerce WooCommerce

Scelta: Tema Ibrido + Elementor solo checkout

• Product pages veloci
• Checkout ottimizzato con builder
• Bilancio performance/conversione

Landing Page

Scelta: Page Builder (Elementor, Bricks)

• Design senza limitazioni
• A/B testing facile
• Conversioni prioritarie

Portfolio Creativo

Scelta: Page Builder o FSE

• Massima espressività
• Animazioni e effetti
• Unicità del design

Sito Editoriale

Scelta: Gutenberg FSE

• Gestione contenuti nativa
• Performance per traffico alto
• Future-proof

Errori da Evitare

Scegliere per Trend

Non seguire la moda del momento. Valuta le esigenze reali del progetto.

Ignorare la Performance

Un sito lento perde visitatori e posizioni SEO. Testa sempre con PageSpeed.

Dimenticare la Manutenzione

Page builder richiedono aggiornamenti costanti. Chi gestirà il sito?

Non Testare Mobile

Il 60% del traffico è mobile. Verifica sempre il responsive.

Trascurare il Budget

Calcola il TCO (Total Cost of Ownership) a 3-5 anni.

Checklist Decisionale

Rispondi a queste domande:

1. Budget iniziale? Meno di 100 euro = tema classico o FSE
2. Budget annuale? Zero = FSE, fino a 100 = tema premium, oltre = builder
3. Competenze tecniche? Nessuna = builder, base = ibrido, avanzate = tema classico
4. Tipo di sito? Blog = tema, vetrina = builder, e-commerce = ibrido
5. Performance critica? Si = tema classico o FSE
6. Chi gestisce? Cliente non tecnico = builder, sviluppatore = tema
7. Orizzonte temporale? Lungo termine = FSE, breve = builder

Conclusione

Non esiste una risposta universale. La scelta dipende da:

• Budget disponibile (iniziale e ricorrente)
• Competenze del team
• Tipo di progetto
• Obiettivi di performance
• Piano di manutenzione

Per il 2026, il nostro consiglio:

• Nuovi progetti: Valuta seriamente Gutenberg FSE
• Clienti non tecnici: Page builder con supporto
• Performance critica: Tema classico o ibrido
• E-commerce: Ibrido con builder solo dove serve

Il futuro punta verso Gutenberg e FSE, ma i page builder rimangono validi per chi necessita di massima flessibilità senza codice.

Risorse Utili

• GeneratePress Official
• Kadence Theme
• Elementor Page Builder
• Bricks Builder
• WordPress Full Site Editing Guide

Aggiornato ad Aprile 2026 - Le tecnologie WordPress evolvono rapidamente