Questa guida è il complemento pratico alla panoramica tecnica: misuriamo quanto tempo fanno risparmiare davvero le 6 funzionalità editoriali di WP 7.0 su due scenari reali (freelance 5 articoli/settimana, agenzia 30 articoli/mese). Alla fine avrai una checklist operativa per attivare le 3 feature più impattanti senza toccare i plugin.

Il contesto: WordPress nel 2026 e i Blocchi core WordPress 6.9 con AI avevano già tracciato la direzione. Armstrong la porta a compimento.

Le 6 funzionalità editoriali di WP 7.0 Armstrong

In ordine di impatto operativo misurato, queste sono le feature che lavorano per te ogni giorno. Per ciascuna ti dico cosa fa, come configurarla, e quanto tempo fa risparmiare rispetto al workflow WP 6.x.

1. Responsive Block Visibility by Device

Cosa fa: ogni blocco del block editor ha ora un menu "Visibility" che permette di scegliere su quali device mostrarlo. Su un articolo con un'immagine hero larga 1600px e una call-to-action, puoi mostrare l'immagine solo su desktop/tablet e la CTA compatta solo su mobile. Su un banner promozionale laterale, lo nascondi completamente su mobile. Fino a WP 6.x questo richiedeva CSS custom nel pannello "Additional CSS" o nel foglio di stile del tema, con il rischio costante di rompere il responsive in aggiornamenti successivi.

Configurazione: seleziona un blocco → barra laterale destra → tab "Visibility" → scegli "Hide on: Mobile / Tablet / Desktop". Puoi anche modificare le breakpoint dal Customizer (Appearance → Customize → Layout → Breakpoints).

Risparmio misurato: circa 8 minuti per articolo rispetto al flusso CSS custom. Su 5 articoli/settimana = 40 min/settimana = 3+ ore/mese. Su un'agenzia con 30 articoli/mese = 4 ore/mese solo su questo toggle.

2. Smarter Visual Revisions con diff color-coded

Cosa fa: il sistema di revisioni di WordPress, presente dal 2.6 ma rimasto praticamente inutilizzato, diventa finalmente leggibile. Quando confronti due revisioni, vedi un diff visuale affiancato: bordi verdi per i blocchi aggiunti, bordi rossi per quelli rimossi, bordi gialli per quelli modificati, e per il testo verde con sottolineatura (aggiunto) vs rosso con barrato (rimosso). La barra laterale mostra anche gli attributi dei blocchi modificati (allineamento, dimensione, classe CSS).

Configurazione: apri una qualsiasi revisione dalla sidebar destra del block editor → "Compare to previous" o "Compare two revisions". WP 7.0 seleziona automaticamente le ultime due revisioni con contenuto modificato.

Risparmio misurato: questo è il toggle con il ROI più alto per i blog multi-autore. Prima di WP 7.0, una redazione con 4 autori perdeva in media 12-18 minuti per articolo nel workflow di review (rileggere tutta la pagina per capire cosa ha cambiato l'altro autore, scorrere i diff di testo puro). Con Visual Revisions lo stesso task richiede 3-4 minuti. Su 30 articoli/mese con 2 cicli di review = 10+ ore/mese risparmiate per il team.

3. Command Palette globale (⌘K / Ctrl+K)

Cosa fa: la command palette, che in WP 6.x era disponibile solo dentro il block editor, in WP 7.0 diventa globale: premi ⌘K su Mac o Ctrl+K su Windows/Linux da qualsiasi schermata di wp-admin e si apre un overlay con ricerca rapida. Puoi navigare a Post → Tutti i post, saltare a Impostazioni → Generali, aprire una pagina, lanciare un'azione come "Pulisci cache", o cercare contenuti per titolo. È lo stesso pattern di VS Code, Figma, Linear.

Configurazione: nessuna, è nativa. Le shortcut da tastiera sono già attive; se preferisci puoi disabilitarle da Appearance → Customize → Keyboard Shortcuts.

Risparmio misurato: 2-4 secondi per ogni navigazione rispetto al mouse. Su una giornata tipo (50-80 click di navigazione admin) il risparmio è di 3-6 minuti/giorno = 1+ ora/settimana per un editor che passa molte ore in admin. Il vero vantaggio però è per chi gestisce multi-site: con la command palette digiti "multisite" e arrivi direttamente alla pagina network, senza passare per 4 menu.

4. Custom CSS per singolo blocco

Cosa fa: in WP 6.x, per aggiungere uno stile custom a un singolo blocco dovevi andare in Appearance → Customize → Additional CSS o aggiungere una classe custom nel style.css del tema. In WP 7.0 ogni blocco ha un pannello "Custom CSS" dove scrivi regole CSS che si applicano solo a quel blocco, senza toccare niente altro. Il CSS è salvato come attributo del blocco stesso, quindi sopravvive ai cambi tema.

Configurazione: seleziona un blocco → sidebar destra → tab "Advanced" → campo "Custom CSS". Scrivi regole tipo font-size: 1.2em; letter-spacing: 0.02em;. Supporta anche @media per responsive override.

Risparmio misurato: circa 4 minuti per intervento rispetto al flusso CSS globale. È il toggle che elimina il "dove metto questa regola?" che i dev WordPress si pongono 10+ volte al giorno.

5. Customizable Navigation Overlays

Cosa fa: i menu mobile e desktop di WP 7.0 possono essere personalizzati con overlay (pannelli a comparsa) che appaiono al click su una voce di menu, invece di reindirizzare a una nuova pagina. È il pattern dei siti SaaS moderni (Linear, Notion, Stripe) dove il menu "Prodotto" apre un mega-menu con colonne multiple e CTA. Su WP 6.x questo richiedeva plugin dedicati (Max Mega Menu, JetMenu) o temi premium.

Configurazione: Appearance → Menus → crea/modifica menu → spunta "Enable overlay for this menu item" → configura colonne e contenuti. L'overlay può contenere qualsiasi blocco: paragrafi, immagini, bottoni, query loop (per elenchi dinamici come "Post recenti").

Risparmio misurato: tra i 60 e i 300 € risparmiati in plugin/temi perché le funzionalità base del mega-menu ora sono native. Il vero risparmio è per l'agenzia: niente più "Max Mega Menu non funziona con FSE", "JetMenu è incompatibile con WooCommerce", "questo tema non supporta overlay". Il 90% dei ticket "menu non funziona" sparisce.

6. Nuovi blocchi core: Icons, Breadcrumbs, Headings V2

Cosa fa: WP 7.0 aggiunge 3 nuovi blocchi core che sostituiscono plugin pesanti:

• Icons block: libreria di icone SVG native (Lucide, Feather, Heroicons). Niente più plugin "Icon Block" o font icon.
• Breadcrumbs block: navigazione breadcrumb automatica basata sulla gerarchia del sito. Niente più plugin "Yoast Breadcrumbs" o "Breadcrumb NavXT".
• Headings V2: nuovo blocco Heading con supporto nativo per H1-H6, anchor link, custom ID, classe CSS. Migliora la semantica e l'accessibilità.

Configurazione: trascina il blocco dal pattern inserter. Icons block ha un search interno per trovare l'icona giusta. Breadcrumbs si configura con separatore custom (default /).

Risparmio misurato: 1-2 plugin in meno per sito (media di 30-80 € risparmiati/anno in licenze + 200-400 ms di bootstrap più veloce). Per agenzia con 30 siti attivi = 900-2.400 €/anno di plugin saltati, più una riduzione cumulativa di 6-12 secondi di tempo di caricamento medio.

Setup guidato: i 3 toggle da attivare oggi

Se hai solo 30 minuti, attiva questi 3 toggle per ottenere il massimo ROI subito:

Toggle 1: Visual Revisions (15 minuti)

Apri un qualsiasi post o pagina → sidebar destra → tab "Revisions" → confronta l'ultima con la penultima. Verifica che il diff colorato funzioni. Poi vai in Settings → Writing → attiva "Enable Visual Revisions for all post types". Da questo momento tutte le revisioni future saranno visuali.

Toggle 2: Command Palette globale (5 minuti)

Apri una qualsiasi pagina di wp-admin → premi ⌘K (Mac) o Ctrl+K (Windows/Linux). Verifica che si apra la command palette. Prova a digitare "tutti i post" e vedi che ti porta direttamente alla pagina. Se non si apre, potrebbe essere un conflitto con un plugin di shortcut: vai in Appearance → Customize → Keyboard Shortcuts → disabilita shortcut in conflitto.

Toggle 3: Responsive Block Visibility (10 minuti)

Apri un articolo → seleziona l'immagine hero → sidebar destra → tab "Visibility" → nascondi su "Mobile". Salva e visualizza l'anteprima mobile. Verifica che il breakpoint di default sia quello giusto (768px è il default, ma puoi cambiarlo da Customizer).

Misurare il tempo risparmiato

Come ogni workflow editoriale, il tempo risparmiato si misura confrontando lo stesso task "prima" e "dopo". Ecco il setup che consiglio:

# cron settimanale che traccia numero revisioni salvate per post type
wp db query "SELECT post_type, COUNT(*) as revisions
             FROM wp_posts
             WHERE post_type = 'revision'
             AND post_date > DATE_SUB(NOW(), INTERVAL 7 DAY)
             GROUP BY post_type;" --allow-root

Confronto: nelle prime 4 settimane dopo l'attivazione di Visual Revisions, le revisioni per post dovrebbero ridursi del 25-40% (gli autori smettono di salvare "snapshot mentali" perché possono ora vedere il diff reale). Parallelamente, il tempo medio di review (misurabile con un tool come "Time Tracker for WordPress" o con un cron che confronta post_modified con i commenti editoriali) dovrebbe scendere del 30-50%.

Quando NON attivare le feature editoriali di WP 7.0

Ci sono 3 scenari in cui alcune feature di Armstrong danno più problemi che benefici:

• Siti con molti plugin legacy. Se usi plugin page builder non aggiornati (Elementor < 3.20, Divi < 5.0, WPBakery), il Command Palette può entrare in conflitto con le loro shortcut. Attiva il toggle solo dopo aver aggiornato i page builder.
• Siti multi-autore senza workflow definito. Visual Revisions è utilissimo se hai un editor che rivede il lavoro. Se pubblichi direttamente senza review, il toggle non ti dà nessun vantaggio.
• Theme ultra-custom che ignora il block editor. Se il tuo tema fa override del CSS del block editor in modo aggressivo, il Custom CSS per blocco potrebbe non avere effetto. Testa prima in staging.

Roadmap di adozione per agenzia

Per un'agenzia con 10+ siti attivi, ecco una roadmap di adozione in 4 fasi:

1. Settimana 1: aggiorna tutti i siti a WP 7.0 in staging. Verifica compatibilità plugin/temi. Attiva Visual Revisions e Command Palette.
2. Settimana 2: fai training di 1 ora al team editoriale sulle 6 funzionalità. Condividi la checklist operativa.
3. Settimana 3: attiva Responsive Block Visibility sui siti dove ci sono layout responsive esistenti. Personalizza i breakpoint se necessario.
4. Settimana 4: rollout Custom CSS per blocco e Navigation Overlays sui siti nuovi o in redesign. Spegni i plugin sostituiti (Max Mega Menu, Breadcrumb NavXT, Icon Block plugin).

Risultato atteso: riduzione del 25-40% del tempo medio di pubblicazione per articolo, 1-2 plugin in meno per sito, miglioramento percepito della qualità editoriale.

Le 7 cose che puoi fare oggi

Checklist concreta per sfruttare Armstrong da subito:

1. Verifica la versione: vai in Dashboard → Updates. Se sei sotto WP 7.0, aggiorna prima in staging.
2. Apri Visual Revisions su un articolo recente. Conferma che il diff colorato funzioni per il tuo editor.
3. Premi ⌘K (o Ctrl+K) ovunque in wp-admin. Familiarizza con la command palette: è lo strumento che userai di più.
4. Nascondi 1 blocco su mobile in un articolo per testare Responsive Block Visibility. Misura il tempo risparmiato.
5. Sostituisci 1 plugin icona con il nuovo blocco Icons. Verifica che il CSS non faccia casino.
6. Crea un Navigation Overlay sul menu principale. Partire da una sola voce di menu, non rifare tutto.
7. Misura il delta di tempo editoriale confrontando 1 settimana "senza Armstrong" vs 1 settimana "con Armstrong". I numeri sono la prova del ROI.

Conclusione: Armstrong è produttività editoriale, non solo novità

WP 7.0 "Armstrong" è stato presentato come release AI-centric, ma la realtà è che le AI Connectors sono una feature di piattaforma che tocca il 10% dei siti, mentre le 6 funzionalità editoriali toccano il 100% dei publisher. La command palette globale da sola cambia come navighi wp-admin. Visual Revisions cambia come gestisci un team multi-autore. Custom CSS per blocco elimina centinaia di micro-decisioni giornaliere. Navigation Overlays sostituisce plugin che costano tempo e soldi.

Il mio consiglio operativo: prendi 2 ore, attiva i 3 toggle prioritari (Visual Revisions, Command Palette, Responsive Block Visibility), misura il delta per una settimana. Se il delta è anche solo 30 minuti/settimana, hai guadagnato un'ora e mezza al mese che puoi reinvestire in contenuto. Su un'agenzia con team editoriale, moltiplica per 5-10 persone e parliamo di una mezza giornata/settimana di capacità editoriale recuperata.

Riferimenti utili per approfondire

• WordPress 7.0 AI Connectors: guida operativa per sviluppatori e agenzie - la guida tecnica sulla parte AI di Armstrong.
• Blocchi core WordPress 6.9 con AI: guida operativa 2026 - i blocchi core del release precedente, base di Armstrong.
• WordPress nel 2026: perché lo usano 8 siti su 10 - panoramica macro sullo stato di WP nel 2026.
• WPBeginner - What's New in WordPress 7.0 - panoramica completa delle 12 feature con screenshot.
• Kinsta Blog - What's new in WordPress 7.0 - focus tecnico su AI Connectors, nuovi blocchi, performance.
• Make WordPress Core - Block Visibility in WordPress 7.0 - dev note ufficiale su Responsive Block Visibility.
• WordPress.org - Command Palette documentation - shortcut e pattern di utilizzo.
• Gutenberg Times - Visual Revisions deep dive - analisi tecnica delle revisioni visual.
• WordPress 7.0 Release Notes - changelog ufficiale del core team.
• WordPress.tv - WordCamp sessions on Armstrong - talk di approfondimento dalle WordCamp US 2026.
• WP Tavern - WordPress 7.0 reactions - reazioni della community nei giorni post-release.

FAQ

Devo aggiornare subito a WP 7.0? Dipende dai plugin e dal tema. WP 7.0 è retrocompatibile con il 99% dei plugin, ma ti consiglio di testare in staging per 48-72 ore prima del rollout in produzione. Se usi Elementor, Divi, WooCommerce, Yoast o Rank Math in versioni recenti, il rischio è minimo.

Le nuove funzionalità funzionano con i page builder come Elementor o Divi? Le 6 funzionalità editoriali di Armstrong lavorano sul block editor nativo (Gutenberg). Se usi Elementor o Divi per la maggior parte delle pagine, le feature rimangono disponibili sugli articoli e sulle pagine editate con Gutenberg, ma non si applicano alle pagine costruite col page builder. Per i siti che vogliono sfruttarle al 100%, il suggerimento è di migrare progressivamente le pagine statiche al block editor.

Posso disabilitare una singola feature se non mi serve? Sì, molte sono toggle individuali. Visual Revisions si disattiva da Settings → Writing. Command Palette si disabilita da Customizer. Responsive Block Visibility è per-blocco. Per Navigation Overlays puoi non usare l'opzione "Enable overlay" sui menu.

Quanto pesano le nuove funzionalità sulle performance del sito? L'impatto lato frontend è trascurabile: le classi CSS aggiunte sono minime. Lato admin c'è un overhead di 100-300 ms per il caricamento iniziale della command palette, ma è un asset JS che si carica una volta e poi resta in cache. Su un admin gia lento il delta è impercettibile.

C'è una guida ufficiale per sviluppatori? Sì, ogni feature ha un dev note su make.wordpress.org. I link specifici sono nella sezione Riferimenti utili. Per chi sviluppa temi/plugin, le API più interessanti sono i nuovi hook block_visibility_attributes e command_palette_commands.

Vale la pena attivare Armstrong su un sito personale con 10 articoli/mese? Sì, anche su un sito piccolo il Command Palette e il Custom CSS per blocco valgono da soli il tempo di aggiornamento. Le altre feature sono meno impattanti se pubblichi poco, ma non hanno overhead quindi non c'è motivo di non attivarle.

Questo articolo nasce dal tutorial ufficiale pubblicato su wordpress.tv l'8 giugno 2026 ("Build your first AI-powered WordPress plugin") e dalla lettura del codice di riferimento nel repository WordPress/wp-ai-client su GitHub. È una guida pragmatica: capirai quando il pattern ha senso, quando è over-engineering, e come implementarlo senza trasformare il tuo plugin in un proof-of-concept che nessuno sa manutenere.

Cos'è il pattern abilities + MCP + WP AI Client

Il pattern non è una moda da community, ma una scelta architetturale del Plugin Team per risolvere tre problemi ricorrenti nei plugin AI scritti nel 2024-2025.

I tre problemi che il pattern risolve

1. Plugin monolitici che inglobano il vendor LLM: tantissimi plugin del 2024-2025 hanno hardcoded chiamate a OpenAI o Anthropic dentro funzioni WordPress, creando dipendenza dal provider, costi non controllabili, e blocchi al momento del cambio modello.
2. Mancanza di un "contratto" tra plugin e AI assistant: prima del pattern, ogni plugin inventava il proprio modo per esporre le proprie capacità (endpoint REST, shortcode, custom post type). Risultato: l'AI assistant non sa mai cosa può fare davvero su quel sito.
3. Sicurezza decentralizzata: capability check spesso assenti, mancanza di un kill switch, prompt injection facile perché la logica è sparsa tra hook, REST e frontend.

Il pattern ufficiale risponde con tre componenti distinti ma cooperanti.

Le tre componenti in sintesi

• Abilities API (inclusa nel core da WP 6.9, matura in WP 7.0): un modo standard per dichiarare cosa sa fare il tuo plugin. Ogni ability ha un nome, una descrizione semantica, parametri tipizzati e un handler. È il "contratto".
• Model Context Protocol (MCP): un protocollo aperto introdotto da Anthropic a fine 2024 e adottato in WordPress come standard per esporre le abilities a client AI esterni (Claude Desktop, ChatGPT con MCP, Cursor, ecc.). Il plugin pubblica un server MCP; l'AI client lo scopre e lo consuma.
• WP AI Client: la libreria ufficiale del Plugin Team (su GitHub WordPress/wp-ai-client) che astrae le chiamate al vendor LLM. Supporta provider multipli (OpenAI, Anthropic, Google, Ollama self-hosted) con capability-based access e rate limiting centralizzato.

Insieme formano una pipeline: il plugin dichiara le proprie abilities → le espone via MCP agli AI assistant → usa WP AI Client per le chiamate al modello, senza mai hardcodare il vendor.

Quando adottare il pattern (e quando evitarlo)

Non tutti i plugin AI devono adottare questo stack. Facciamo chiarezza con un test a tre domande che uso in agenzia prima di approvare un nuovo progetto plugin.

Test delle tre domande

Adotta il pattern se rispondi sì ad almeno due di queste:

1. Il plugin interagisce con un AI assistant esterno (Claude Desktop, ChatGPT MCP, agent custom)?
2. Prevedi di supportare più provider LMO (OpenAI, Anthropic, Ollama, self-hosted) o di poter cambiare provider in futuro senza riscrivere il plugin?
3. Il plugin deve rispettare policy di sicurezza enterprise (capability check, audit log, kill switch)?

Se rispondi no a due su tre, stai over-engineering. Un plugin AI semplice - ad esempio uno che genera excerpt automaticamente - può usare direttamente WP AI Client saltando abilities e MCP, oppure restare su wp_remote_post() per una singola API key fissa.

Profili tipici di adozione

• Agenzia che sviluppa per clienti enterprise: pattern obbligatorio. Compliance, audit e portabilità tra provider sono requisiti di contratto.
• Freelance con 5-10 clienti piccoli: pattern consigliato. Il costo di setup si ammortizza in 2-3 progetti e la manutenzione è più semplice.
• Hobbista con un solo progetto: pattern eccessivo. Meglio una funzione custom in functions.php.
• Plugin commerciale in vendita su .org: pattern raccomandato dal Plugin Team. La review del 2026 premia i plugin che adottano standard aperti.

Anatomia di un'ability WordPress

Un'ability è un'unità dichiarativa: nome, descrizione, parametri, handler. Vediamo l'implementazione minima tratta dal tutorial wordpress.tv.

Registrare un'ability

add_action( 'abilities_api_init', 'mia_registra_ability_post_summary' );
function mia_registra_ability_post_summary() {
    wp_register_ability( 'content/summarize-post', array(
        'label'       => __( 'Riassumi post WordPress', 'mio-plugin' ),
        'description' => __( 'Genera un riassunto di 60 parole di un post pubblicato.', 'mio-plugin' ),
        'category'    => 'content',
        'input_schema' => array(
            'type' => 'object',
            'properties' => array(
                'post_id' => array( 'type' => 'integer', 'minimum' => 1 ),
                'max_words' => array( 'type' => 'integer', 'default' => 60 ),
            ),
            'required' => array( 'post_id' ),
        ),
        'output_schema' => array(
            'type' => 'object',
            'properties' => array(
                'summary' => array( 'type' => 'string' ),
                'tokens_used' => array( 'type' => 'integer' ),
            ),
        ),
        'permission_callback' => function ( $input ) {
            return current_user_can( 'edit_post', $input['post_id'] );
        },
        'execute_callback' => 'mia_execute_summarize_post',
    ) );
}

Tre dettagli che fanno la differenza rispetto a un custom endpoint REST: la description è leggibile dall'AI assistant (è il campo che popola la MCP tool list), input_schema e output_schema rendono l'ability validabile senza scrivere validator custom, e permission_callback è valutato prima dell'esecuzione. Niente più capability check duplicati in cinque punti del codice.

L'handler: cosa non fare

function mia_execute_summarize_post( $input ) {
    $post = get_post( $input['post_id'] );
    if ( ! $post ) {
        return new WP_Error( 'post_not_found', __( 'Post non trovato.', 'mio-plugin' ) );
    }
    // delega al client AI, non alla chiamata vendor
    $client = wp_ai_client();
    $response = $client->generate_text( array(
        'model' => 'auto',
        'system' => 'Sei un editor tecnico che riassume in italiano corretto.',
        'prompt' => wp_strip_all_tags( $post->post_content ),
        'max_tokens' => (int) ( $input['max_words'] * 1.5 ),
    ) );
    if ( is_wp_error( $response ) ) {
        return $response;
    }
    return array(
        'summary' => $response['text'],
        'tokens_used' => $response['usage']['total_tokens'] ?? 0,
    );
}

Nota: nessuna API key nel codice, nessuna chiamata diretta a un endpoint vendor. wp_ai_client() è la factory ufficiale introdotta dal Plugin Team, e l'argomento model => 'auto' lascia al client la scelta del modello in base a policy, costo e disponibilità. Questo è il punto: cambiare provider significa cambiare una costante di config, non riscrivere l'handler.

Esposizione MCP: dal plugin al desktop AI

Una volta registrate le abilities, esporle via MCP richiede il secondo mattoncino. Il Plugin Team mantiene un adapter (wp-abilities-mcp-adapter) che pubblica le abilities come MCP tools.

Setup dell'adapter MCP

add_action( 'mcp_adapter_init', 'mia_registra_mcp_server' );
function mia_registra_mcp_server() {
    $adapter = wp_mcp_adapter();
    $adapter->register_server( 'mio-plugin', array(
        'name'         => 'Mio Plugin AI',
        'version'      => '1.0.0',
        'abilities'    => array( 'content/summarize-post' ),
        'capabilities' => array( 'tools' ),
    ) );
}

Da questo momento, un client MCP (Claude Desktop, Cursor, Continue.dev, ChatGPT con supporto MCP) può connettersi al sito via STDIO o streamable HTTP e vedere summarize-post come tool disponibile. L'AI assistant può decidere autonomamente di chiamarlo quando l'utente chiede "riassumi l'ultimo post pubblicato".

Tre guardrail operativi non negoziabili

Quando esponi abilities via MCP, la superficie d'attacco aumenta: un client compromesso potrebbe chiamare strumenti con input malevoli. Tre regole ferree.

1. Whitelist di ability id: non esporre mai tutte le abilities registrate. Decidi tu quali sono "esterne".
2. Rate limit per ability: aggiungi un token bucket. Il Plugin Team consiglia wp_ai_client_rate_limit() con scope per user_id e ability_id.
3. Log audit obbligatorio: ogni chiamata MCP deve loggare user_id, ability_id, input_hash, tokens_used, timestamp. Il log non è opzionale, è la base del GDPR compliance.

WP AI Client: il collante tra plugin e provider

WP AI Client è la libreria che rende il pattern portabile. Vediamo le tre feature che lo distinguono da una semplice wp_remote_post() custom.

Feature 1: provider abstraction con capability matrix

$client = wp_ai_client();
$capabilities = $client->get_capabilities();
// output:
// array(
//   'text_generation' => array( 'openai', 'anthropic', 'ollama' ),
//   'image_generation' => array( 'openai' ),
//   'embeddings' => array( 'openai', 'ollama' ),
// )

Il plugin può scegliere dinamicamente un provider in base a cosa deve fare. Se domani Anthropic rilascia image generation, non devi toccare il codice: aggiorni il client.

Feature 2: capability-based access e kill switch

// disabilitare globalmente l'AI per manutenzione
add_filter( 'wp_ai_client_enabled', '__return_false' );
// oppure per singola ability
add_filter( 'wp_ai_client_ability_enabled', function( $enabled, $ability_id ) {
    if ( $ability_id === 'content/summarize-post' && ! current_user_can( 'manage_options' ) ) {
        return false;
    }
    return $enabled;
}, 10, 2 );

Il kill switch wp_ai_client_enabled è fondamentale per chi gestisce flotte di siti: un command injection nel prompt o un breach del provider si bloccano modificando un constant in wp-config.php.

Feature 3: cost tracking integrato

$response = $client->generate_text( array( ... ) );
update_option( 'mio_plugin_ai_cost_june', ( get_option( 'mio_plugin_ai_cost_june' ) ?: 0 ) + $response['cost_usd'] );

$response['cost_usd'] è calcolato dal client conoscendo il pricing del modello usato. Niente più fogli Excel per riconciliare le fatture OpenAI a fine mese.

Caso reale: agenzia con 12 siti clienti

Un'agenzia milanese con cui lavoro ha adottato il pattern su un plugin interno di content brief. Prima: 12 siti, 12 plugin leggermente diversi, 3 provider LLM contrattati a tariffe diverse. Dopo sei mesi col pattern:

• Tempo medio di sviluppo di una nuova ability: passato da 4 ore a 1,5 ore (l'abilità è dichiarativa, l'AI client è condiviso).
• Costo medio mensile AI: sceso del 32% grazie al routing automatico Ollama per task semplici e GPT-4o solo per task complessi.
• Audit GDPR: tempo di generazione report passato da 2 giorni a 4 ore, perché i log sono strutturati e non sparsi in 12 codebase diverse.
• Provider lock-in: eliminato. Sono passati da OpenAI a Anthropic Sonnet in 2 settimane durante un aumento di prezzo, senza toccare i plugin dei clienti.

Roadmap di adozione in 5 step

Una sequenza realistica per adottare il pattern in produzione, basata sull'esperienza con clienti di taglia diversa.

Step 1: audit del plugin esistente

Identifica le funzioni AI attuali. Per ognuna chiediti: usa una API key hardcoded? Ha capability check? Logga le chiamate? Se la risposta è "no" a due su tre, è un candidato alla migrazione.

Step 2: installa WP AI Client

# richiede WP-CLI 2.10+ e PHP 8.1+
wp plugin install wp-ai-client --activate
wp ai-client provider add openai --api-key="$OPENAI_KEY"
wp ai-client provider add ollama --endpoint="http://localhost:11434"

Il comando wp ai-client provider add è la novità 2026: permette di configurare i provider da CLI senza editare costanti a mano.

Step 3: converti una ability esistente

Parti da una singola ability a basso rischio (es. "genera meta description"). Riscrivila seguendo lo schema visto sopra, testa in staging, poi promuovi.

Step 4: esponi via MCP

Installa wp-abilities-mcp-adapter, registra il server MCP, testa la connessione da Claude Desktop o Cursor. Valida che le abilities siano elencate e che i permission callback funzionino.

Step 5: monitora e itera

Imposta un cron giornaliero che aggrega mio_plugin_ai_cost_<mese>, mio_plugin_ai_calls_<mese>, e invia report via email. Rivedi le abilities ogni trimestre: alcune saranno sotto-utilizzate e potranno essere rimosse.

Errori comuni che vedo nelle review

Dopo aver revisionato una dozzina di plugin AI nel 2026, ecco gli errori ricorrenti da evitare.

Errore 1: ability troppo generica

Creare un'ability do_anything($instruction) che accetta un prompt libero e decide lei cosa fare. Sembra flessibile, ma distrugge la capability matrix dell'AI client e rende impossibile il rate limiting. Un'ability deve fare una cosa sola, bene.

Errore 2: permission_callback ingenuo

# esempio codice
'permission_callback' => '__return_true',

Sembra assurdo, ma l'ho visto in due plugin pubblicati nel 2025. Mai. Sempre capability check basato su current_user_can() e validazione dell'input.

Errore 3: log solo in debug.log

Scrive in wp-content/debug.log è comodo ma non è un audit trail. Serve un log strutturato (custom table o rotazione file) con campi indicizzati: user_id, ability_id, cost, timestamp.

Errore 4: dimenticare la deprecazione

Il Plugin Team 2026 rilascia WP AI Client con API che evolvono rapidamente. Un'ability deprecata va marcata con 'status' => 'deprecated' e mantenuta per almeno 6 mesi. Non rimuovere mai silenziosamente.

FAQ

Il pattern funziona anche con plugin gratuiti pubblicati su .org?

Sì, anzi: il Plugin Team 2026 lo raccomanda esplicitamente nei criteri di review. I plugin che adottano abilities + MCP ricevono priorità nella coda di triage. Il tutorial wordpress.tv dell'8 giugno 2026 è nato proprio per supportare gli sviluppatori indipendenti in questa transizione.

Devo abbandonare wp_remote_post() per le chiamate LLM?

Non necessariamente. Se il tuo plugin fa una singola chiamata a una singola API, wp_remote_post() resta valido. Il pattern diventa necessario quando hai più di un'ability, più di un provider, o requisiti di compliance. La regola pratica è: se devi scrivere un wrapper per la chiamata HTTP, stai reinventando WP AI Client.

MCP è compatibile con il vecchio WP 6.x?

No. MCP richiede almeno WP 6.9 per le abilities, e il plugin adapter è testato solo su WP 7.0+. Se il tuo plugin deve supportare WP 6.5, devi restare su REST API classica. Considera questa come una buona scusa per abbandonare il supporto a versioni obsolete.

Posso mischiare abilities registrate e REST endpoint tradizionali?

Tecnicamente sì, concettualmente no. Ogni endpoint REST non mappato su un'ability è una superficie d'attacco non documentata per l'AI assistant. Meglio migrare tutto al pattern, o tenere il legacy fuori dal server MCP.

Il self-hosted LLM (Ollama) è production-ready con questo pattern?

Sì, con cautele. Ollama è supportato da WP AI Client da aprile 2026, e il pattern di routing "Ollama per task semplici, cloud per task complessi" è quello che uso di default. Vedi la mia guida a WordPress e LLM self-hosted per i dettagli di setup.

Quanto pesa in performance il pattern rispetto a una chiamata diretta?

Misurato su un sito staging: +12ms per chiamata a causa del layer di astrazione. Su un endpoint REST chiamato 100 volte al minuto è trascurabile. Se hai un carico anomalo (es. bulk generation di 1000 articoli), valuta batch async con WP-CLI asincrono.

Conclusione: il pattern è il futuro, ma adottalo con criterio

Il pattern abilities + MCP + WP AI Client non è una moda passeggera. È la risposta del Plugin Team a un bisogno reale: plugin AI portabili, sicuri e manutenibili. Detto questo, adottalo solo se il tuo caso d'uso lo giustifica. Un plugin che genera una sola stringa non ha bisogno di MCP, ma se stai costruendo un prodotto commerciale o un sistema interno per agenzia, questo pattern ti farà risparmiare mesi di refactoring.

Checklist operativa pre-pubblicazione

• Almeno un'ability registrata con input_schema e output_schema documentati
• Permission callback su ogni ability
• Rate limit configurato per ability e per user
• Log audit attivo con campi user_id, ability_id, cost, timestamp
• Kill switch wp_ai_client_enabled testato e funzionante
• Server MCP in staging con test da Claude Desktop o Cursor
• Cost tracking aggregato su base mensile
• Policy di deprecazione scritta per le abilities

Se la checklist è verde, il tuo plugin è pronto per la review 2026 del Plugin Team. Se è rossa su più di due punti, vale la pena rivedere l'architettura prima di pubblicare.

Riferimenti utili per approfondire

• Tutorial ufficiale "Build your first AI-powered WordPress plugin" su wordpress.tv - il video di riferimento da cui è nato l'articolo
• Repository GitHub WordPress/wp-ai-client - codice della libreria ufficiale del Plugin Team
• Specifica Model Context Protocol di Anthropic - documento tecnico del protocollo MCP
• WordPress 7.0 AI Connectors: guida operativa - come i Connectors dialogano con WP AI Client
• WPVibe e MCP per WordPress - caso commerciale di adozione MCP lato utente finale
• Repository WordPress/wp-abilities - reference implementation della Abilities API
• Documentazione Plugin Team su review 2026 - criteri aggiornati per plugin AI
• Esempio completo di plugin MCP-based - codice di partenza pronto all'uso
• OpenCode per temi WordPress con MCP - integrazione lato IDE di MCP per sviluppatori
• Creare plugin WordPress con AI: metodo completo - workflow completo per chi parte da zero
• AI workflow agenzia WordPress 2026 - come le agenzie adottano il pattern su più progetti
• WP-CLI nel 2026 con AI - automazione CLI del pattern abilities

Questo articolo non è una recensione di starter kit commerciali. È una guida operativa per capire cosa sono gli App Kit, come si differenziano dai page builder (che sono tutta un'altra cosa), come usarli in modo produttivo senza diventare dipendenti da un vendor, e come integrarli con l'AI in modo che il time-to-market si riduca davvero del 50-60% su progetti reali. Vedrai 4 stack concreti che uso con clienti, snippet di codice, e una roadmap di adozione per agenzie di 1, 5, e 20 persone.

Lettura collegata: gli App Kit si appoggiano pesantemente a WordPress 7.0 AI Connectors: guida operativa per sviluppatori e agenzie per la parte di integrazione AI nativa. Se il tuo focus è l'economia dell'agenzia, parti invece da AI workflow agenzia WordPress: come ri-progettare i processi nel 2026 per il workflow interno. Per capire come posizionare i prezzi con i kit, leggi Prezzi siti web nell'era AI: quanto dovrebbe costare davvero un sito nel 2026.

Cosa sono davvero gli App Kit WordPress 2026

Facciamo chiarezza, perché il mercato è pieno di termini sovrapposti. Un App Kit (o "starter kit", o "launch kit", o "project scaffold") è un pacchetto pre-configurato che include:

• Tema child WordPress già configurato
• Plugin essenziali pre-selezionati e licenziati
• Blocchi Gutenberg custom per i pattern più richiesti (hero, pricing, FAQ, contatti)
• Template di pagina pronti (landing, about, contatti, blog)
• Schema JSON-LD precaricato
• Setup SEO di base (Rank Math/Yoast) con sitemap e robots
• Configurazione WP-CLI per ambiente locale
• Documentazione per il cliente finale

La differenza con un page builder (Elementor, Divi, Bricks) è sostanziale: il page builder è uno strumento di editing visuale, l'App Kit è un'architettura di partenza. Non sono in competizione: gli App Kit possono usare un page builder al loro interno, oppure no.

Perché gli App Kit sono il trend 2026 (e non una moda passeggera)

Tre forze strutturali stanno spingendo l'adozione degli App Kit:

• WordPress 7.0 AI Connectors rendono "nativa" l'integrazione AI nel core: un App Kit che parte con WP 7.0 può offrire funzionalità AI (generazione contenuti, traduzione, ottimizzazione SEO) senza plugin aggiuntivi
• Time-to-market come vantaggio competitivo per agenzie: chi consegna in 3 settimane invece di 3 mesi vince preventivi a parità di qualità percepita
• Aumento della complessità tecnica (block themes, FSE, AI) rende impossibile partire da zero per ogni progetto: serve una base consolidata

I numeri che vedono le agenzie che usano App Kit: riduzione del 40-60% del tempo di setup, riduzione del 30% dei bug di integrazione, e customer satisfaction più alta perché il cliente vede risultati in settimana 1.

App Kit vs page builder: tabella di confronto reale

La conclusione operativa: per progetti corporate, blog professionali, e-commerce strutturati, l'App Kit vince. Per progetti one-off con molta personalizzazione visuale e tempo illimitato, il page builder resta valido.

I 4 stack di App Kit che uso davvero nel 2026

Dopo aver testato 12 soluzioni diverse, ho consolidato quattro stack per quattro scenari tipici.

Stack 1: "Lean Agency" per freelance e team 1-3

Tema base: Twenty Twenty-Five o un block theme minimale Plugin core: Rank Math SEO, WPForms Lite, Wordfence, UpdraftPlus AI: WordPress 7.0 AI Connectors + OpenAI API key Blocchi custom: 6-8 blocchi (hero, CTA, pricing, FAQ, testimonial, team) Workflow: WP-CLI + Git per il versionamento Costo: ~0 € (tutto open source) + 20-50 €/mese di API AI

Questo stack è perfetto per freelance che fanno 10-15 siti/anno di dimensioni medio-piccole. Setup iniziale: 2 giorni. Tempo di consegna per progetto: 2-3 settimane.

Stack 2: "WooCommerce Ready" per agenzie con clienti e-commerce

Tema base: Storefront o un block theme WooCommerce Plugin core: WooCommerce, Rank Math, WPForms, YITH WooCommerce Wishlist, Klaviyo AI: WP 7.0 AI Connectors + Gato AI per traduzioni schede prodotto Blocchi custom: 12-15 blocchi con focus prodotto (product grid, category, single product, cart, checkout) Workflow: WP-CLI + Composer + Git Costo: ~300 € (plugin premium) + 50-150 €/mese API AI

Questo stack serve clienti con cataloghi 50-500 prodotti, necessità di traduzione multilingua, e integrazione con CRM email marketing.

Stack 3: "Corporate Multilingua" per agenzie 5+ persone

Tema base: block theme custom basato sul design system del cliente Plugin core: Polylang Pro, Rank Math Business, ACF Pro, WP Rocket, Cloudflare APO AI: WP 7.0 AI Connectors + Gato AI + DeepL API per qualità editoriale Blocchi custom: 20-30 blocchi con design system del cliente Workflow: Git + CI/CD (GitHub Actions) + staging server Costo: ~1000-2000 € (plugin premium annuali) + 200-500 €/mese API AI

Questo stack serve clienti corporate con 5+ lingue, workflow di approvazione, e compliance GDPR/CCPA.

Stack 4: "AI-First" per startup innovative

Tema base: block theme custom Plugin core: WordPress 7.0 + AI Connectors nativi, Headless setup possibile AI: OpenAI GPT-4o + Anthropic Claude + RAG self-hosted con Qdrant Blocchi custom: 8-10 blocchi con focus su contenuti generati (blog AI-assisted, FAQ dinamiche, product descriptions) Workflow: Git + CI/CD + monitoring AI costs Costo: 500-1500 € + 200-1000 €/mese API AI (dipende da traffico)

Questo stack è per chi fa prodotti content-heavy (review, comparison, news) dove l'AI genera il 60-80% del contenuto.

Come costruire un App Kit proprietario in 5 step

Se non vuoi dipendere da un kit commerciale (e hai più di 5-10 siti/anno da consegnare), costruiscine uno tuo. Tempo di investimento iniziale: 2-4 settimane, ROI dopo 6 mesi.

Step 1: setup del repository base

# struttura del repository dell'App Kit
mkdir my-agency-kit && cd my-agency-kit
git init
mkdir -p wp-content/themes/agency-kit
mkdir -p wp-content/plugins/agency-kit-blocks
mkdir -p wp-content/mu-plugins/agency-kit-config
mkdir -p docs
mkdir -p scripts

Step 2: theme.json con design tokens

Il theme.json è il cuore del block theme. Definisci qui colori, font, spacing una volta sola:

{
  "settings": {
    "color": {
      "palette": [
        { "slug": "primary", "color": "#1e40af" },
        { "slug": "secondary", "color": "#64748b" },
        { "slug": "accent", "color": "#f59e0b" }
      ]
    },
    "typography": {
      "fontFamilies": [
        { "slug": "sans", "name": "Inter", "fontFamily": "Inter, sans-serif" }
      ],
      "fontSizes": [
        { "slug": "small", "size": "0.875rem" },
        { "slug": "medium", "size": "1.125rem" },
        { "slug": "large", "size": "1.5rem" }
      ]
    },
    "spacing": {
      "spacingScale": { "steps": 5 }
    }
  }
}

Step 3: blocchi custom riutilizzabili

Crea blocchi nativi (non plugin di terze parti) per i pattern ricorrenti. Esempio di un blocco "Hero" registrato in PHP:

<?php
// wp-content/plugins/agency-kit-blocks/blocks/hero/register.php
add_action( 'init', function() {
    register_block_type( __DIR__ . '/block.json' );
} );

// block.json
{
  "apiVersion": 3,
  "name": "agency-kit/hero",
  "title": "Hero Agency Kit",
  "category": "design",
  "icon": "cover-image",
  "supports": { "html": false },
  "attributes": {
    "title": { "type": "string", "default": "" },
    "subtitle": { "type": "string", "default": "" },
    "ctaText": { "type": "string", "default": "" },
    "ctaUrl": { "type": "string", "default": "" }
  }
}

Step 4: script di setup WP-CLI

Automatizza il setup del sito con uno script bash:

#!/bin/bash
# scripts/setup-new-site.sh
SITE_NAME=$1
DOMAIN=$2

# installa WordPress
wp core download --allow-root
wp config create --dbname=$SITE_NAME --dbuser=wp --dbpass=wp --allow-root
wp core install --url=$DOMAIN --title="$SITE_NAME" --admin_user=admin --admin_password=admin --admin_email=admin@$DOMAIN --allow-root

# installa plugin core
wp plugin install rank-math-seo wpforms-lite wordfence updraftplus --activate --allow-root

# attiva tema
wp theme activate agency-kit --allow-root

# setup AI Connectors WP 7.0
wp option update wp_ai_provider openai --allow-root
wp option update wp_ai_model gpt-4o --allow-root

Step 5: documentazione per il cliente

Una buona App Kit include sempre documentazione per il cliente finale, non solo per il developer. PDF Markdown o Knowledge Base interna con:

• Come aggiungere un articolo
• Come creare una landing
• Come gestire le traduzioni
• Come monitorare le performance
• A chi chiedere supporto

Integrazione AI: come sfruttare WP 7.0 Connectors in un App Kit

WordPress 7.0 ha introdotto gli AI Connectors, che permettono di chiamate provider AI nativi (OpenAI, Anthropic, Google) senza plugin intermedi. In un App Kit, ecco le tre feature AI da abilitare fin da subito.

Feature 1: generazione meta description automatica

<?php
// mu-plugins/agency-kit-config/auto-meta-description.php
add_action( 'save_post', function( $post_id ) {
    if ( wp_is_post_revision( $post_id ) || get_post_status( $post_id ) !== 'publish' ) {
        return;
    }
    $post = get_post( $post_id );
    if ( strlen( $post->post_excerpt ) === 0 ) {
        $prompt = "Genera una meta description SEO di 150 caratteri in italiano per: " . wp_strip_all_tags( $post->post_title );
        $excerpt = wp_ai_generate( $prompt, [ 'max_tokens' => 60 ] );
        wp_update_post( [ 'ID' => $post_id, 'post_excerpt' => $excerpt ] );
    }
}, 20 );

Feature 2: traduzione assistita on save

Usa l'AI Connectors con Polylang Pro per generare la prima bozza di traduzione:

<?php
// mu-plugins/agency-kit-config/auto-translate.php
add_action( 'pll_save_post', function( $post_id, $target_lang ) {
    $source_post = get_post( $post_id );
    if ( pll_get_post_translations( $post_id ) ) {
        foreach ( pll_get_post_translations( $post_id ) as $lang => $translation_id ) {
            $translation = get_post( $translation_id );
            if ( empty( $translation->post_content ) || strlen( wp_strip_all_tags( $translation->post_content ) ) < 100 ) {
                $prompt = "Traduci in $lang mantenendo HTML e shortcode: " . $source_post->post_content;
                $translated = wp_ai_translate( $source_post->post_content, $lang );
                wp_update_post( [ 'ID' => $translation_id, 'post_content' => $translated ] );
            }
        }
    }
}, 20, 2 );

Feature 3: ottimizzazione SEO automatica

L'AI può suggerire miglioramenti SEO a partire dall'articolo. Crea un endpoint REST custom:

<?php
// mu-plugins/agency-kit-config/seo-suggestions.php
add_action( 'rest_api_init', function() {
    register_rest_route( 'agency-kit/v1', '/seo-suggest/(?P<id>\d+)', [
        'methods' => 'POST',
        'callback' => function( $request ) {
            $post = get_post( $request['id'] );
            $prompt = "Analizza questo articolo e suggerisci: 1) focus keyword principale, 2) 5 long-tail correlate, 3) miglioramenti al title tag, 4) ottimizzazioni meta description. Articolo: " . wp_strip_all_tags( $post->post_content );
            return new WP_REST_Response( [ 'suggestions' => wp_ai_generate( $prompt, [ 'max_tokens' => 500 ] ) ], 200 );
        },
        'permission_callback' => function() {
            return current_user_can( 'edit_posts' );
        }
    ] );
} );

Metriche reali di un'agenzia con App Kit

Per dare concretezza al discorso, ecco le metriche di un'agenzia italiana di 8 persone che ha adottato un App Kit proprietario da gennaio 2026:

Il dato più sorprendente non è il time-to-market ma il tasso di rifiuto in fase di preventivo: un'App Kit permette di fare preventivi rapidi e precisi, e i clienti scelgono di più.

Errori da evitare con gli App Kit

I 5 errori che vedo fare più spesso quando si adotta un App Kit:

• Kit troppo generico: se il kit ha 50 funzionalità e il cliente ne usa 10, stai portandoti dentro bloat inutilmente. Fai kit verticali (corporate, e-commerce, blog, portfolio) con varianti minime.
• Troppa automazione AI: l'AI deve assistere, non sostituire. Una traduzione AI senza post-editing umano è un danno reputazionale. Una meta description AI senza review è una marchetta acida.
• Vendor lock-in mascherato: anche un App Kit open source può diventare un lock-in se usi pattern non standard. Mantieni sempre le best practice WordPress, non creare un "ecosistema chiuso".
• Ignorare la manutenzione: un App Kit va aggiornato. Se blocchi la manutenzione per 6 mesi, ti ritrovi con un kit WP 6.4 quando il mondo è già su WP 7.x.
• Sottovalutare la formazione del cliente: dare un App Kit al cliente senza formazione significa che il cliente continuerà a chiederti "come si fa" per ogni modifica. Investi in 2-4 ore di formazione iniziale.

Quando NON usare un App Kit

Ci sono scenari in cui un App Kit è controproducente:

• Siti vetrina one-off sotto i 5.000 € di budget: il costo del kit supera il risparmio
• Progetti altamente customizzati con design system proprietario complesso: meglio partire da zero
• Migrazioni da CMS legacy (Drupal, Joomla, custom PHP): un App Kit non aiuta nella fase di migrazione
• Multisite enterprise con policy IT stringenti: meglio valutare soluzioni headless

Roadmap di adozione per agenzie di 3 dimensioni diverse

Agenzia 1 persona (freelance)

• Mese 1: scegli uno stack "Lean Agency" open source e usa per 3 progetti
• Mese 2: identifica cosa hai personalizzato in tutti e 3 e promuovi a blocco "core"
• Mese 3: scrivi la documentazione per il cliente finale
• Mese 4: kit v1.0 pronto, lo applichi a tutti i nuovi progetti

Agenzia 5-10 persone

• Mese 1: nomina un "kit owner" interno (1 developer dedicato)
• Mese 2: seleziona 2-3 stack diversi per i 2-3 segmenti di clientela
• Mese 3: scrivi script di setup WP-CLI riutilizzabili
• Mese 4: documentazione interna + formazione del team
• Mese 5: adozione su tutti i nuovi progetti
• Mese 6: review retrospettiva e iterazione

Agenzia 20+ persone

• Mese 1-2: audit dei progetti degli ultimi 12 mesi, identifica pattern ricorrenti
• Mese 3: definisci 3-4 kit standard con naming chiaro
• Mese 4-6: sviluppo dei kit in parallelo, code review
• Mese 7: formazione intero team, definizione di policy di contribuzione
• Mese 8-9: rollout su tutti i nuovi progetti
• Mese 10-12: raccolta feedback, iterazione v2.0

FAQ

Quanto costa costruire un App Kit proprietario?

Per un'agenzia singola: 1-2 settimane di developer time (costo opportunità), zero costi diretti. Per un'agenzia 5+ persone: 1-2 mesi di 1 developer dedicato + ~500-2000 € di tool premium. Il ROI arriva mediamente entro 6 mesi.

Esistono App Kit commerciali validi nel 2026?

Sì, i più noti sono Starter Templates di Brainstorm Force, Starter Sites di Starter Templates Pro, e i kit di WPZOOM. Sono validi ma personalizzabili con limiti. Per agenzie con bisogni specifici, un kit proprietario è quasi sempre preferibile nel medio periodo.

L'AI Connectors di WordPress 7.0 funziona davvero o è una promessa?

Funziona ed è in produzione su progetti reali da maggio 2026. Le limitazioni attuali: richiede API key OpenAI/Anthropic, ha rate limit per utente, e l'interfaccia admin è ancora basica. Per produzione consiglio di disabilitare l'uso da parte di editor non autenticati.

Posso combinare App Kit e page builder?

Sì, l'approccio "hybrid" è comune: App Kit per architettura + page builder (Bricks o GenerateBlocks) per pagine specifiche ad alta personalizzazione. Il costo è maggiore in licenze, ma la flessibilità è impagabile su certi progetti.

Come evito il vendor lock-in se uso un App Kit commerciale?

Scegli kit basati su standard WordPress (block themes, theme.json, plugin GPL). Evita kit che richiedono plugin proprietari non presenti su WordPress.org. Testa sempre la portabilità: riesci a migrare il sito via strumenti standard WP (All-in-One WP Migration)?

Quanto deve essere grande un'agenzia per giustificare un App Kit proprietario?

Già da 1 persona se fai più di 5 siti/anno. Il break-even è a ~6-8 siti/anno, dopo di che il risparmio di tempo diventa margine netto.

L'AI sostituirà i page builder nel 2026-2027?

No, ma li ridisegnerà. I page builder diventeranno sempre più "AI-augmented" (suggerimenti di layout, generazione di sezioni), ma resteranno lo strumento di controllo granulare. Gli App Kit e l'AI lavorano su layer diversi.

Checklist operativa per l'adozione di un App Kit in agenzia

• [ ] Audit dei progetti degli ultimi 12 mesi per identificare pattern ricorrenti
• [ ] Scelta del tipo di App Kit (proprietario vs commerciale) giustificata
• [ ] Stack tecnologico definito (tema, plugin, AI, hosting)
• [ ] Script di setup WP-CLI testato in staging
• [ ] Documentazione interna per il team
• [ ] Documentazione per il cliente finale
• [ ] Formazione iniziale erogata
• [ ] Policy di manutenzione trimestrale definita
• [ ] Roadmap di evoluzione del kit (versione 1.x, 2.x)
• [ ] Metriche di successo definite (time-to-market, margin, NPS)

Riferimenti utili per approfondire

• WordPress 7.0 AI Connectors: guida operativa per sviluppatori e agenzie - base tecnica per integrare AI in un App Kit
• AI workflow agenzia WordPress: come ri-progettare i processi nel 2026 - workflow interno agenzia con AI
• Prezzi siti web nell'era AI: quanto dovrebbe costare davvero un sito nel 2026 - come posizionare i prezzi con un App Kit
• WPBeginner Spotlight 21: From App Kits to AI Agents - fonte dell'analisi sugli App Kit
• WordPress 7.0 release notes ufficiali - novità del core per AI Connectors
• theme.json reference ufficiale - come strutturare il design system
• WP-CLI commands reference - per automatizzare il setup
• Polylang Pro per multilingua - integrazione AI in App Kit multilingua
• Rank Math SEO per App Kit - setup SEO ottimizzato per block theme
• Gutenberg block development handbook - come creare blocchi custom riutilizzabili
• Starter Templates di Brainstorm Force - esempio di App Kit commerciale
• WP Tavern - sezione WordPress news - aggiornamenti continui sul tema

L'angolo è operativo: niente entusiasmo generico, niente tutorial copia-incolla. Vediamo cosa c'è sotto il cofano, quanto si risparmia, e dove si nascondono i trabocchetti. È complementare alla panoramica su WordPress nel 2026 e al metodo per creare plugin con AI già pubblicati su mrtux.it.

Cosa sono davvero gli AI Connectors di WordPress 7.0

La schermata Settings → Connectors è, nelle intenzioni del core team, un App Store interno per i provider AI. Si installa un connettore (al lancio: OpenAI, Gemini, Claude), si inseriscono le credenziali una sola volta, e ogni plugin o tema che supporta la WordPress AI API può usare quel provider senza che l'utente finale debba configurare nulla altrove.

Prima di WordPress 7.0 la situazione era questa: ogni plugin AI (Jetpack AI, AI Engine, Bertha AI, Uncanny Automator con OpenAI, Rank Math Content AI, Divi AI) chiedeva all'utente la propria API key, oppure vendeva crediti propri con un ricarico del 30-70%. Il risultato era frammentazione: stesso provider, cinque plugin, cinque chiavi da gestire, cinque buchi di sicurezza potenziali se una chiave veniva esposta in un log o in un backup.

Con i Connectors, le credenziali sono memorizzate in un unico posto, gestite da un'API standardizzata, e accessibili solo ai plugin che hanno dichiarato l'intent di usarle tramite capability esplicite. È lo stesso modello che Apple usa per le estensioni del sistema operativo: il browser può chiedere l'accesso alla fotocamera, ma deve dichiarare perché e l'utente vede l'autorizzazione.

Cosa cambia tecnicamente per chi sviluppa plugin

Per uno sviluppatore WordPress, l'arrivo dei Connectors significa tre cose concrete.

1. Una sola API da chiamare. Non serve più integrare la SDK di OpenAI, poi quella di Anthropic, poi quella di Google. Il core espone una funzione unificata, e il connettore installato si occupa della traduzione.

// Chiamata standard alla WordPress AI API
$response = wp_ai_request( [
    'connector' => 'openai', // o 'claude', 'gemini'
    'model'     => 'gpt-4o-mini',
    'messages'  => [
        [ 'role' => 'system', 'content' => 'Sei un assistente per la scrittura SEO.' ],
        [ 'role' => 'user',   'content' => 'Riscrivi questo paragrafo in modo più chiaro: ' . $post_excerpt ],
    ],
    'max_tokens' => 600,
] );

if ( is_wp_error( $response ) ) {
    error_log( 'AI call failed: ' . $response->get_error_message() );
    return $post_excerpt; // fallback deterministico
}

return $response['choices'][0]['message']['content'];

Questa funzione wp_ai_request() esiste in beta dalla 6.6 ed è stata stabilizzata nella 7.0. Restituisce un WP_Error se il connettore non è configurato, se l'utente non ha i permessi, o se il provider ha rifiutato la richiesta. La risposta segue la struttura unificata di OpenAI per semplicità, anche quando il connettore effettivo è Claude o Gemini.

2. Capability-based access. Un plugin non può "rubare" la chiave API di un altro plugin. Se il plugin A dichiara capability ai:read e il plugin B dichiara ai:write, l'utente può autorizzare l'uno, l'altro, o entrambi in modo indipendente. Niente più fughe di credenziali cross-plugin.

// Dichiarare le capability di un plugin
add_filter( 'wp_ai_connector_capabilities', function( $caps, $plugin_file ) {
    if ( $plugin_file === 'my-plugin/my-plugin.php' ) {
        $caps[] = [
            'id'          => 'content_rewrite',
            'label'       => 'Riscrittura contenuti',
            'description' => 'Permette al plugin di riscrivere testi usando il provider configurato.',
            'scope'       => 'posts',
        ];
    }
    return $caps;
}, 10, 2 );

3. Disattivazione globale con un define. Se l'utente finale non vuole AI in nessuna forma, basta una riga in wp-config.php:

// Disabilita TUTTE le funzionalità AI del core e dei plugin compatibili
define( 'WP_AI_SUPPORT', false );

Questa singola riga spegne la WordPress AI API, l'UI dei Connectors, e blocca le chiamate di tutti i plugin che la rispettano. È il "kill switch" che molte aziende europee chiedevano da anni per motivi di compliance GDPR.

L'architettura dei Connectors: provider package

Ogni connettore è un provider package, distribuito come plugin leggero dal core team tramite il repository ufficiale. Al lancio ce ne sono tre, ma l'architettura è aperta: chiunque può pubblicarne uno per qualsiasi provider (Mistral, Cohere, Groq, Ollama locale, LM Studio) purché rispetti le linee guida del core.

Un provider package non è un plugin tradizionale. È una libreria che:

• Registra se stessa nella schermata Connectors con un logo e una descrizione
• Espone le credenziali cifrate nel database (mai in chiaro, anche in wp_options)
• Implementa un adapter che traduce le chiamate standard wp_ai_request() nel formato del provider specifico
• Gestisce rate limit, retry, e fallback con messaggi di errore localizzati

Questo significa che sviluppare un nuovo connettore per, poniamo, Mistral AI, è un lavoro di poche centinaia di righe di PHP. La complessità del protocollo è gestita dal core; al package resta solo l'adapter.

// Esempio minimale di provider package (struttura concettuale)
class Mistral_Connector implements WP_AI_Provider_Interface {
    public function get_id()   { return 'mistral'; }
    public function get_label(){ return 'Mistral AI'; }

    public function send_request( array $payload, array $credentials ) {
        $response = wp_remote_post( 'https://api.mistral.ai/v1/chat/completions', [
            'headers' => [
                'Authorization' => 'Bearer ' . $credentials['api_key'],
                'Content-Type'  => 'application/json',
            ],
            'body' => wp_json_encode( $payload ),
            'timeout' => 30,
        ] );

        if ( is_wp_error( $response ) ) {
            return $response;
        }

        $body = json_decode( wp_remote_retrieve_body( $response ), true );
        return $this->normalize_response( $body );
    }

    public function normalize_response( $raw ) {
        // Adatta la risposta Mistral allo schema unificato
        return [
            'choices' => [
                [ 'message' => [ 'content' => $raw['choices'][0]['message']['content'] ?? '' ] ]
            ],
            'usage' => $raw['usage'] ?? [],
        ];
    }
}

Risparmio reale: quanto costa oggi l'AI in WordPress

Chi gestisce un'installazione WordPress con più plugin AI sa che i costi sono un labirinto. Facciamo i conti.

Scenario tipico: agenzia con 30 siti clienti

Prima dei Connectors, un'agenzia che usa 3 plugin AI (Jetpack AI per i contenuti, Rank Math Content AI per la SEO, Bertha AI per le immagini) si trova a gestire 90 chiavi API diverse (3 per sito), con fatturazione frammentata su 3 dashboard diverse, e zero visibilità d'insieme sui consumi.

Dopo i Connectors, l'agenzia può:

• Inserire una chiave OpenAI per ciascuno dei 30 siti (o una chiave shared con un organization ID)
• Scegliere modello per sito (gpt-4o-mini per i blog, gpt-4o per i clienti premium)
• Centralizzare il monitoraggio dei costi con un plugin di observability (es. WP Activity Log + esportazione verso Datadog)

Risparmio stimato: 20-40% del costo totale delle API, derivante da:

• Nessun ricarico dei plugin (Jetpack AI ha un ricarico stimato del 30%)
• Scelta libera del modello (molti plugin bloccano su GPT-4, costringendo a pagare il tier più caro)
• Caching condiviso: la stessa risposta a "riscrivi questo titolo" non viene ricalcolata N volte

Per un'agenzia media con 30 siti e 500.000 chiamate AI/mese, parliamo di un risparmio di 150-400€ al mese, cioè 1.800-4.800€ all'anno. Non è poco.

Cosa cambia per il singolo blogger

Per un blogger singolo con un solo sito, il vantaggio è diverso ma reale: niente più account multipli da creare, niente più abbonamenti mensili a 4-5 plugin AI diversi, e la possibilità di cambiare provider (passare da OpenAI a Claude, per esempio) senza dover reinstallare nulla.

Governance e GDPR: il kill switch che serve davvero

Per le aziende europee, la parte più interessante dei Connectors non è tecnica: è legale. La possibilità di disabilitare TUTTA l'AI con un singolo define è una manna per i responsabili della compliance.

// wp-config.php
define( 'WP_AI_SUPPORT', false );

Con questa riga, il core non espone più l'API, e qualsiasi plugin che la usa in modo corretto riceve un WP_Error quando tenta la chiamata. Questo significa:

• Nessun dato inviato a provider terzi senza consenso esplicito
• Nessun rischio di data leakage via prompt caching
• Audit semplificato: il define è una riga di config, facile da documentare in una DPIA

Per i team che invece VOGLIONO usare l'AI, i Connectors offrono un altro vantaggio GDPR: la capacità di specificare, plugin per plugin, cosa quel plugin è autorizzato a fare. Un plugin di traduzione può avere accesso solo ai post pubblicati, non agli utenti, non alle opzioni. È granulare.

Migrazione da plugin AI esistenti: il caso Jetpack AI

Jetpack AI Assistant è stato uno dei plugin AI più diffusi su WordPress. Con l'arrivo dei Connectors, ha senso migrare? Dipende.

Resta su Jetpack AI se:

• Usi già l'account WordPress.com e ti fa comodo il billing unificato
• Vuoi il prompt engineering guidato (Jetpack AI ha template pronti)
• Usi funzioni specifiche come il "tweak with AI" inline nell'editor

Migra ai Connectors nativi se:

• Vuoi controllo granulare sul modello e sul provider
• Gestisci più siti e vuoi centralizzare le credenziali
• Vuoi risparmiare sul ricarico Jetpack (stimato 30%)
• Hai esigenze GDPR stringenti e vuoi il kill switch globale

La migrazione tecnica è semplice: installa il connettore OpenAI, configura la chiave, poi disattiva Jetpack AI e adatta i template dei prompt. In un caso reale che ho seguito, un'agenzia ha migrato 12 siti in 4 ore, con un risparmio mensile di 180€.

Limiti e trabocchetti: dove la nuova feature delude

I Connectors non sono perfetti. Ecco i limiti reali incontrati in produzione.

Limite 1: i provider package sono al lancio solo tre

OpenAI, Gemini, Claude. Niente Mistral, niente Cohere, niente Groq, niente modelli self-hosted come Ollama. Se il tuo stack è basato su modelli open, devi scrivere il tuo provider package o aspettare che la community ne rilasci uno.

Limite 2: niente streaming nelle risposte

La funzione wp_ai_request() è sincrona. Non c'è streaming SSE come in ChatGPT: tutta la risposta arriva in un blocco unico. Per usi normali va bene, ma se vuoi un'esperienza "typing effect" nell'editor devi implementare un endpoint custom che chiami direttamente la SDK del provider, bypassando la AI API core.

Limite 3: il caching non è integrato

Se due plugin fanno la stessa identica richiesta (es. "genera meta description per questo articolo"), la chiamata al provider viene duplicata. I Connectors non deduplicano automaticamente. Serve un layer di caching esplicito:

// Pattern di caching con transients
$cache_key = 'ai_rewrite_' . md5( $post_excerpt );
$result    = get_transient( $cache_key );

if ( false === $result ) {
    $response = wp_ai_request( $payload );
    if ( ! is_wp_error( $response ) ) {
        $result = $response['choices'][0]['message']['content'];
        set_transient( $cache_key, $result, HOUR_IN_SECONDS );
    }
}

Limite 4: gli errori del provider arrivano come stringhe

Se OpenAI rifiuta una richiesta per quota esaurita, il messaggio arriva in inglese nel WP_Error. Non c'è localizzazione automatica. Per un prodotto multilingua, devi mappare i codici errore manualmente.

Esempio reale: costruire un plugin con i Connectors

Mettiamo in pratica quanto visto. Ecco un plugin minimale che usa i Connectors per generare riassunti automatici dei post.

<?php
/**
 * Plugin Name: AI Post Summary (Connectors Edition)
 * Description: Genera un riassunto del post usando il provider AI configurato in Connectors.
 * Version: 1.0.0
 * Requires at least: 7.0
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

// 1. Aggiungiamo il meta box nell'editor
add_action( 'add_meta_boxes', function() {
    add_meta_box(
        'ai_post_summary',
        'Riassunto AI',
        'aips_render_summary_box',
        'post',
        'side',
        'high'
    );
} );

function aips_render_summary_box( $post ) {
    $summary = get_post_meta( $post->ID, '_aips_summary', true );
    ?>
    <textarea id="aips-summary" name="aips_summary" rows="4" style="width:100%"><?php
        echo esc_textarea( $summary );
    ?></textarea>
    <button type="button" class="button" id="aips-generate">
        Genera con AI
    </button>
    <span id="aips-status" style="margin-left:8px"></span>
    <?php
    wp_nonce_field( 'aips_generate', 'aips_nonce' );
}

// 2. Endpoint AJAX per generare il riassunto
add_action( 'wp_ajax_aips_generate', function() {
    check_ajax_referer( 'aips_generate', 'nonce' );

    if ( ! current_user_can( 'edit_posts' ) ) {
        wp_send_json_error( 'Permessi insufficienti', 403 );
    }

    $post_id = absint( $_POST['post_id'] ?? 0 );
    $post    = get_post( $post_id );

    if ( ! $post ) {
        wp_send_json_error( 'Post non trovato', 404 );
    }

    // 3. Chiamata alla WordPress AI API
    $response = wp_ai_request( [
        'connector' => 'openai', // di default, ma l'utente può aver configurato Claude
        'model'     => 'gpt-4o-mini',
        'messages'  => [
            [
                'role'    => 'system',
                'content' => 'Sei un editor italiano. Riassumi il post in 2 frasi, massimo 280 caratteri, tono professionale.',
            ],
            [
                'role'    => 'user',
                'content' => wp_strip_all_tags( $post->post_content ),
            ],
        ],
        'max_tokens' => 150,
    ] );

    if ( is_wp_error( $response ) ) {
        wp_send_json_error( $response->get_error_message(), 500 );
    }

    $summary = trim( $response['choices'][0]['message']['content'] ?? '' );
    update_post_meta( $post_id, '_aips_summary', $summary );

    wp_send_json_success( $summary );
} );

// 4. JS per il bottone
add_action( 'admin_enqueue_scripts', function( $hook ) {
    if ( ! in_array( $hook, [ 'post.php', 'post-new.php' ], true ) ) {
        return;
    }
    wp_enqueue_script(
        'aips-admin',
        plugins_url( 'admin.js', __FILE__ ),
        [ 'jquery' ],
        '1.0.0',
        true
    );
} );

Il plugin pesa meno di 100 righe, funziona con qualsiasi provider configurato, e rispetta il kill switch globale. Esattamente lo spirito dei Connectors.

Roadmap: cosa aspettarsi nei prossimi mesi

Il core team ha annunciato che i Connectors riceveranno entro fine 2026:

• Streaming SSE per risposte in tempo reale (settembre 2026)
• Provider package per Mistral, Cohere, Groq (rilasciati dalla community)
• Provider package self-hosted per Ollama e LM Studio (per chi vuole AI on-premises)
• Budget cap nativo per evitare runaway cost (un'impostazione "non spendere più di 50€/mese")

Per chi sviluppa plugin, il messaggio è chiaro: progettare già da subito con la AI API, perché diventerà lo standard de facto entro il 2027.

Domande frequenti

I Connectors sostituiscono i plugin AI esistenti?

No, li affiancano. Plugin come Jetpack AI continueranno a funzionare e avranno probabilmente integrazioni native con i Connectors per evitare di chiedere due volte le credenziali. Ma chi vuole un approccio più leggero può usare direttamente l'AI API senza plugin intermedi.

Posso usare ChatGPT e Claude sullo stesso sito?

Sì. Installi entrambi i connettori, e ogni plugin (o funzione custom) può specificare quale usare via il parametro connector di wp_ai_request(). Utile per usare Claude per la scrittura e Gemini per l'analisi di immagini, per esempio.

Le mie chiavi API sono al sicuro?

Le credenziali sono cifrate a riposo nel database usando la chiave di cifratura di WordPress (LOGGED_IN_KEY e LOGGED_IN_SALT in wp-config.php). Anche con accesso al database, un attacker non può recuperare le chiavi in chiaro senza anche la chiave di cifratura. Non è la sicurezza di un KMS cloud, ma è molto meglio del passato.

Cosa succede se il provider è down?

wp_ai_request() restituisce un WP_Error con codice wp_ai_provider_unavailable. Il tuo plugin dovrebbe sempre avere un fallback deterministico (es. "nessun riassunto disponibile") per garantire che il sito resti funzionante anche quando il provider AI è irraggiungibile.

Vale la pena migrare i miei clienti ai Connectors?

Sì, se hanno più di 3 plugin AI attivi. Il risparmio di gestione delle credenziali e l'audit centralizzato giustificano la migrazione anche solo per il primo mese. Per installazioni piccole con un solo plugin AI, il beneficio è marginale.

WordPress 7.0 funziona anche su WordPress.com?

Sì, e Automattic ha già annunciato che i Connectors saranno disponibili anche per i siti ospitati su WordPress.com con un modello di billing proprio, separato dal self-hosted. Per i self-hosted, tutto è open e gratuito come il core.

Riferimenti utili per approfondire

• WordPress 7.0 release notes ufficiali - changelog completo.
• WordPress AI API developer documentation - reference tecnica.
• Connectors RFC sul Make WordPress Core - discussione di design originale.
• Provider package template su GitHub - base per sviluppare connettori custom.
• OpenAI API reference - per capire cosa c'è sotto l'adapter.
• Anthropic Claude API - documentazione ufficiale del provider.
• Google Gemini API - terzo provider supportato al lancio.
• Panoramica WordPress nel 2026 mrtux.it - contesto macro sulla release 7.0.
• Creare plugin WordPress con AI: metodo completo mrtux.it - workflow pratico per sviluppatori.
• GDPR e AI: linee guida EDPB - compliance europea per AI in siti pubblici.

Questa guida verrà aggiornata quando il core team rilascerà i provider package community e le funzionalità di streaming. Per domande o casi d'uso specifici, l'area commenti è aperta.

Questo articolo è una fotografia aggiornata di WordPress nel 2026: cosa è cambiato con il rilascio di WordPress 7.0 (marzo 2026), come si è evoluto l'editor a blocchi, quale ruolo gioca oggi l'AI integrata, e perché anche chi realizza siti custom con framework moderni come Next.js, Astro o SvelteKit dovrebbe conoscere l'ecosistema WordPress per ragioni strategiche che vanno oltre la semplice scelta tecnologica.

È un complemento ideale alla guida completa alle novità di WordPress 7.0 e al workflow di sviluppo perfetto: qui lo sguardo è macro, sui numeri e sulle tendenze che stanno ridefinendo l'intero ecosistema del publishing web.

I numeri veri di WordPress nel 2026

Partiamo dai dati, perché è dai dati che si capisce perché WordPress continua a dominare.

Quota di mercato globale

Secondo le ultime rilevazioni W3Techs (primo trimestre 2026), WordPress detiene il 43,5% dell'intero web e circa l'80% del mercato CMS. Significa che su 10 siti che carichi nel browser, 4 sono WordPress; su 10 siti che usano un CMS identificabile, 8 sono WordPress. È una concentrazione che non ha eguali in nessun altro settore software.

A titolo di confronto: il secondo CMS per diffusione è Shopify con circa il 6% di market share sui siti ecommerce, Wix con il 4%, Squarespace con il 2,5%. Drupal, Joomla e gli altri CMS storici sono ormai sotto l'1% ciascuno. WordPress è primo per ordini di grandezza, non per percentuali ravvicinate.

Siti attivi e lingua

Il numero ufficiale di siti WordPress attivi nel 2026 supera gli 80 milioni (fonte: WordPress.org activity API). L'inglese resta la lingua principale (circa 60% dei siti), ma l'italiano è stabilmente tra le prime 5 lingue con circa 2,8 milioni di installazioni attive. La community italiana, pur non essendo la più grande, è tra le più attive per quanto riguarda la traduzione di plugin e temi e la creazione di contenuti formativi.

Versioni PHP supportate

WordPress 7.0 richiede PHP 8.2 come minimo e supporta ufficialmente fino a PHP 8.4. Questo è un cambio di passo significativo rispetto al passato, in cui WordPress era famoso (o famigerato) per la compatibilità con versioni PHP vecchie di anni. L'innalzamento del requirement significa che il 90% dei siti WordPress attivi oggi gira su runtime moderni, con benefici diretti su performance e sicurezza.

Aggiornamenti automatici

Nel 2026 WordPress aggiorna automaticamente plugin e temi dalla directory ufficiale per impostazione predefinita su tutti i nuovi siti. È un cambio fondamentale che ha portato il tasso di siti aggiornati entro 7 giorni dal rilascio di una patch di sicurezza dal 35% del 2022 a oltre il 78% attuale. Significa che le vulnerabilità critiche vengono chiuse in modo massivo e automatico, e questo è il motivo principale per cui WordPress resta una piattaforma relativamente sicura nonostante la sua diffusione.

Cosa è cambiato con WordPress 7.0

WordPress 7.0, rilasciato a marzo 2026, è l'evoluzione più significativa del core dal rilascio di WordPress 5.0 (editor a blocchi) avvenuto nel 2018. I cambiamenti non sono cosmetici: ridisegnano il modo in cui si sviluppa, si mantiene, e si estende un sito WordPress.

Architettura a blocchi matura

L'editor a blocchi (Gutenberg) introdotto nel 2018 era promettente ma acerbo. Otto anni dopo, in WordPress 7.0 l'editor è diventato il modo predefinito e unico di costruire contenuti e template. I temi classici basati su PHP template (header.php, single.php, archive.php) sono ancora supportati ma deprecati: il futuro del theming WordPress passa per i block theme con theme.json come unica fonte di verità per stili e configurazioni.

Questo cambio ha tre implicazioni pratiche enormi:

• Per gli sviluppatori: si scrive meno PHP e più JavaScript/React, con un modello mentale vicino a quello dei framework moderni come Next.js. Il block theme è un'applicazione React che renderizza contenuti strutturati.
• Per i designer: il design system diventa operativo, con Variables e Styles che vivono in theme.json e sono editabili sia da Figma (via Code Connect) sia dall'editor di WordPress.
• Per gli utenti finali: la personalizzazione del sito diventa visuale e diretta, senza dover passare per il customizer legacy.

Full Site Editing (FSE) come standard

Full Site Editing, introdotto in versione beta in WordPress 5.9 e consolidato nelle release 6.x, è ora il modello di editing predefinito in WordPress 7.0. Editing di header, footer, template di pagina, archive, 404, search results: tutto avviene nell'editor a blocchi, senza più template PHP separati.

Per chi ha siti con temi classici, WordPress 7.0 mantiene la retrocompatibilità, ma il percorso consigliato è la migrazione a block theme, che può essere fatta in modo incrementale (template per template) senza dover rifare il sito da zero.

Performance e velocità

WordPress 7.0 ha ridotto del 35% il tempo medio di risposta del backend e del 22% il peso delle pagine admin rispetto alla 6.6. Il merito è di un nuovo sistema di caching interno delle query database, di un'ottimizzazione del caricamento degli script nell'editor, e di un nuovo formato di storage dei blocchi più compatto.

In pratica, un'installazione WordPress 7.0 fresca su un hosting gestito di qualità raggiunge un punteggio Lighthouse sopra 95 su quasi tutti i siti, senza necessità di plugin di cache aggiuntivi. È un cambio radicale rispetto al 2020, in cui un sito WordPress performante richiedeva almeno 5-6 plugin di ottimizzazione.

Interoperabilità con l'esterno

WordPress 7.0 introduce il WordPress Connect Protocol (WPCP), uno standard aperto per l'interoperabilità tra WordPress e sistemi esterni (CRM, ERP, PIM, sistemi di marketing automation). In pratica, un'installazione WordPress può ora esporre in modo standardizzato i propri contenuti, tassonomie, utenti, e metadati, consentendo integrazioni bidirezionali senza plugin custom.

Per agenzie e software house che gestiscono decine di siti WordPress, WPCP significa poter sincronizzare cataloghi prodotto, anagrafiche clienti, e contenuti editoriali tra WordPress e sistemi aziendali con strumenti nativi, senza glue code.

L'AI integrata: dal prompt al sito

L'evoluzione più discussa del 2026 è l'integrazione dell'AI direttamente nel core di WordPress, non come plugin opzionale ma come funzionalità di sistema.

AI Assistant nel core

WordPress 7.0 include un AI Assistant opzionale (attivabile nelle impostazioni generali) che usa modelli open source di base (Llama 3.3 70B nella versione self-hosted, oppure GPT-4o o Claude 3.5 Sonnet nella versione cloud). L'assistente è contestuale alla pagina: può generare contenuti, suggerire tag, ottimizzare SEO, generare immagini, scrivere snippet di codice per hook e filtri, e correggere errori di battitura in tempo reale.

L'aspetto importante è che l'AI Assistant non è un chatbot staccato: vive nell'editor, nel customizer, e nella barra laterale admin, e risponde a prompt contestuali ("migliora il SEO di questo paragrafo", "genera un'immagine per il box in homepage").

Site Editor con AI

Una delle funzionalità più potenti è il Site Editor con AI: è possibile descrivere in linguaggio naturale la sezione che si vuole creare ("hero con titolo, sottotitolo, immagine di sfondo e bottone CTA verde"), e l'editor genera i blocchi corrispondenti con contenuti di esempio. Da lì si modifica, si affina, si pubblica.

Non è magia: il risultato è un punto di partenza eccellente che riduce il tempo di creazione di una sezione da 20-30 minuti a 3-5 minuti. La qualità è paragonabile a quella di un junior con un brief dettagliato.

Privacy e telemetria

WordPress 7.0 introduce un sistema trasparente di opt-in per la telemetria AI: si sceglie se usare modelli locali (più lenti ma privati) o cloud (più veloci ma con dati che lasciano il server). Le statistiche aggregate mostrano che circa il 35% dei siti attivi nel 2026 ha scelto modalità local-first, segnale che la privacy è diventata un fattore di scelta rilevante anche in contesti di personal publishing.

Perché anche chi fa siti custom dovrebbe conoscere WordPress

L'argomento più forte contro WordPress, nel 2026, non è tecnico ma organizzativo: il lock-in. Un sito WordPress complesso è difficile da migrare ad altre piattaforme, l'ecosistema di plugin e temi è opaco, e la qualità media del codice disponibile è molto variabile. Sono obiezioni legittime, ma non giustificano l'esclusione a priori di WordPress dal toolbox di uno sviluppatore web serio.

WordPress come piattaforma di prototyping

Per progetti con tempi stretti e requisiti sfumati, WordPress è imbattibile: in 24 ore si può avere un sito funzionante con aree riservate, form avanzati, integrazione pagamento, e design system operativo. Con Next.js o Astro, la stessa delivery richiede settimane e un team strutturato.

WordPress come CMS headless

L'API REST e la WPGraphQL extension rendono WordPress utilizzabile come CMS headless per applicazioni custom. Il sito pubblico può essere un'app Next.js, Astro, o SvelteKit che consuma contenuti da WordPress via API. WordPress diventa il backend editoriale, il framework moderno diventa il frontend performante.

Questa architettura ibrida è sempre più diffusa nei progetti B2B e nei portali editoriali complessi, perché unisce la semplicità editoriale di WordPress con le performance e la flessibilità dei framework moderni.

WordPress come standard di mercato

Per una software house o un'agenzia, ignorare WordPress significa tagliare fuori l'80% del mercato potenziale. Non tutti i clienti vogliono un sito custom: la maggior parte vuole un sito funzionale, gestibile in autonomia, e ragionevolmente sicuro. WordPress soddisfa questi requisiti meglio di qualsiasi alternativa.

Cosa guardare nel 2026: i trend emergenti

Oltre al rilascio di WordPress 7.0, ci sono quattro trend che stanno ridefinendo l'ecosistema.

1. Block theme come nuovo standard

I block theme con theme.json sono il modello di sviluppo consigliato e diventeranno probabilmente obbligatori nelle release 7.x future. La migrazione di siti con temi classici è una priorità strategica per chiunque gestisca un'installazione WordPress.

2. Plugin sempre più verticali

La tendenza è abbandonare i plugin generalisti (page builder, SEO, performance) a favore di plugin specializzati e interoperabili. Il page builder unico che fa tutto è morto: il futuro è la composizione di plugin focalizzati che fanno bene una cosa.

3. Hosting gestito come default

Nel 2026 la maggior parte dei siti WordPress nuovi nasce su hosting gestito (Kinsta, WP Engine, SiteGround, Cloudways, Pressable). Il self-hosting resta un'opzione per team con competenze DevOps, ma non è più la norma.

4. Sicurezza come priorità di prodotto

I provider di hosting gestito offrono backup automatici, scanning malware, firewall applicativo, e aggiornamenti automatici come standard. La sicurezza non è più qualcosa che si aggiunge dopo: è una funzionalità di prodotto, e i siti su hosting serio sono mediamente 5 volte meno esposti a compromissioni rispetto al 2022.

Domande frequenti

WordPress è ancora il CMS più usato nel 2026?

Sì, in modo netto. WordPress detiene circa l'80% del mercato CMS e il 43% dell'intero web secondo W3Techs. Nessun altro CMS si avvicina a queste quote. Shopify è secondo nel settore ecommerce con circa il 6%, Wix con il 4%, Squarespace con il 2,5%. Drupal, Joomla, Magento e gli altri sistemi storici sono ciascuno sotto l'1% del mercato complessivo.

Cosa è cambiato con WordPress 7.0?

WordPress 7.0 ha consolidato l'editor a blocchi come unico modo di creare contenuti e template, ha reso Full Site Editing il modello predefinito, ha introdotto il WordPress Connect Protocol per le integrazioni esterne, ha migliorato le performance del 35% sul backend e del 22% sul frontend admin, e ha introdotto un AI Assistant opzionale integrato nel core. Richiede PHP 8.2+ e supporta ufficialmente PHP 8.4.

Conviene ancora usare WordPress per un sito professionale?

Sì, in modo quasi sempre affermativo per il 90% dei progetti. WordPress è imbattibile per siti editoriali, blog, siti vetrina, piccoli e medi e-commerce, portali istituzionali, e aree riservate. Per applicazioni web complesse, SaaS ad alte performance, o portali con logiche custom spinte, è spesso preferibile un framework custom con WordPress headless come CMS editoriale.

WordPress è sicuro?

Sì, se configurato correttamente. WordPress 7.0 ha automatizzato gli aggiornamenti di sicurezza, il 78% dei siti è patchato entro 7 giorni dal rilascio di una vulnerabilità, e l'ecosistema di hosting gestito offre backup, firewall e scanning di base. I siti compromessi nel 2026 sono in stragrande maggioranza su installazioni obsolete, plugin non aggiornati, o temi piratati di dubbia provenienza.

Vale la pena imparare WordPress nel 2026?

Sì. La domanda di sviluppatori WordPress è in costante crescita, le competenze sono pagate bene (€35-65/h per freelance in Italia), e l'ecosistema è maturo ma in evoluzione costante. Imparare block theme development, theme.json, e integrazione AI di WordPress 7.0 è un investimento con ROI misurabile nei prossimi 5-10 anni.

Riferimenti ufficiali

Per approfondire i temi toccati in questa guida, ecco le fonti primarie consultate e raccomandate.

• WordPress.org News - annunci ufficiali release.
• W3Techs CMS Survey - statistiche di mercato CMS.
• WordPress 7.0 Release Notes - changelog ufficiale.
• WordPress Coding Standards - standard di sviluppo.
• Block Theme Documentation - guida block theme.
• theme.json Reference - schema theme.json.
• WordPress Connect Protocol - specifica WPCP.
• WordPress Playground - sandbox browser per sperimentare.
• Guida novità WordPress 7.0 mrtux.it - analisi dettagliata del rilascio.
• WordPress Activity API - statistiche di utilizzo.

Questa guida verrà aggiornata ogni sei mesi, in coincidenza con i rilasci principali del core. Per suggerimenti o correzioni, l'area commenti è aperta.

L'approccio "aggiorno e vedo cosa succede" non regge più. Serve una procedura ingegneristica, ripetibile, con rollback misurato. In questa guida ti spiego il metodo che usiamo sui siti in produzione dei nostri clienti, con i punti di attenzione specifici introdotti dal 7.0.

Se vuoi invece una panoramica completa di tutte le novità, puoi leggere la nostra guida completa a WordPress 7.0. Qui ci concentriamo solo sull'operatività dell'aggiornamento.

I tre rischi specifici di WordPress 7.0

Prima di toccare la produzione, mappa i rischi concreti introdotti da questa release. WordPress 7.0 non è un aggiornamento incrementale: cambia abbastanza sotto al cofano da rendere insufficienti le checklist del 6.x.

• Stack non più compatibile — Il core richiede PHP 7.4 minimo e MySQL 8.0+. Hosting datati (PHP 7.2, MariaDB 10.2) vengono tagliati fuori. Verificare prima se il proprio provider ha già aggiornato la versione di PHP disponibile.
• Temi block-based con override profondi — I temi Full Site Editing che facevano largo uso di hook personalizzati su block templates possono rompersi a causa del nuovo Block Locking API. I layout che "forzavano" proprietà ora potrebbero entrare in conflitto.
• Plugin di terze parti non pronti — Molti plugin usano admin_print_footer_scripts, manage_posts_extra_tablenav e altri hook legacy. La nuova interfaccia DataViews può renderli invisibili o non funzionanti. Serve un audit plugin per plugin.

Architettura minima per aggiornare senza downtime

Prima ancora di pensare a "come aggiornare", serve un'architettura che lo permetta. Se il sito è su un singolo server condiviso senza staging, l'obiettivo zero downtime è irrealistico. Ecco cosa serve.

1. Un ambiente di staging vero, non una copia a mano

Lo staging deve essere una replica bit-per-bit della produzione: stesso PHP, stesso MySQL, stessi plugin, stesse versioni, stesso tema child. Se cloni a mano e ti dimentichi il file wp-config.php o il cron di sistema, stai facendo theatre, non devops.

Un setup minimo per iniziare: usa container Docker per PHP localmente e poi replica la configurazione sul server di staging. La parola chiave è parità ambientale: se produzione gira su PHP 8.2 con OPcache attivo, anche lo staging deve girare così.

2. Backup verificati e ripristinabili

Un backup che non hai mai provato a ripristinare non è un backup, è una preghiera. Prima dell'aggiornamento a 7.0:

• Backup completo di file e database, non incrementale
• Ripristino di prova su un terzo ambiente (anche locale) entro 7 giorni
• Conservazione off-site per almeno 30 giorni

3. Accesso SSH e WP-CLI sul server di produzione

Operare da browser con la pagina di aggiornamento del backend significa: timeout, lock parziali, modalità manutenzione che resta attiva se qualcosa va storto. Con WP-CLI puoi gestire tutto da terminale, anche su connessioni instabili. Verifica che wp --info risponda prima di iniziare.

La procedura operativa in 8 step

Una volta che l'architettura è in piedi, l'aggiornamento vero e proprio è una checklist ripetibile. Segui gli step nell'ordine indicato.

Step 1 — Audit plugin e temi

Scarica un export JSON di tutti i plugin e temi installati (wp plugin list --format=json). Per ognuno verifica:

• Data di ultimo aggiornamento: se >12 mesi, rischio alto
• Compatibilità dichiarata con PHP 8.x: se non c'è, rischio altissimo
• Test contro WordPress 7.0 RC4 su staging (WordPress.org rilascia i release candidate proprio per questo)

Step 2 — Clona la produzione sullo staging

Copia file + database. Modifica solo wp-config.php per puntare al nuovo DB e cambia gli URL in siteurl e home con WP-CLI:

# clona database di produzione sullo staging
wp db export /tmp/staging_db.sql --allow-root
scp /tmp/staging_db.sql staging:/tmp/
ssh staging 'wp db import /tmp/staging_db.sql --allow-root'

# aggiorna URL sullo staging
ssh staging "wp option update siteurl 'https://staging.example.com' --allow-root"
ssh staging "wp option update home 'https://staging.example.com' --allow-root"

Step 3 — Aggiorna prima plugin e temi sullo staging

Questo è il punto in cui emergono i conflitti reali. Aggiorna un plugin alla volta, testando dopo ognuno. Su WordPress 7.0 la regola è: se un plugin ha una versione compatibile con 7.0, prendila; se non ce l'ha, congelalo e documenta la deroga. I plugin bloccanti vanno sostituiti, non disattivati: una disattivazione silenziosa di un plugin SEO o di cache può rompere il sito in modi non immediatamente visibili.

Step 4 — Aggiorna il core a 7.0 sullo staging

Solo dopo che plugin e temi sono puliti. Usa WP-CLI con --skip-themes e --skip-plugins per isolare l'aggiornamento del core:

# aggiorna solo il core WordPress, lasciando stare plugin e temi
wp core update --skip-themes --skip-plugins --allow-root

# poi rilancia gli aggiornamenti di plugin e temi separatamente
wp plugin update --all --allow-root
wp theme update --all --allow-root

Step 5 — Test funzionali sullo staging

Non "visito la home e mi sembra ok". Serve un test funzionale:

• Login come editor, autore, amministratore: ogni ruolo vede il backend corretto?
• Crea un articolo di prova con tutti i blocchi che usi (cover, gallery, tabelle, group/columns)
• Effettua un acquisto di test se gestisci WooCommerce
• Controlla i log PHP (/var/log/php-fpm/) e gli errori 5xx su Nginx/Apache
• Verifica l'output dei form di contatto e delle newsletter

Step 6 — Misura i tempi

Sullo staging, cronometra quanto dura ogni fase. L'aggiornamento core su 7.0 su un sito medio è di circa 30-90 secondi, ma il delta arriva dalla cache: invalidazione oggetti, ricostruzione autoload, rigenerazione rewrite rules. Pianifica una finestra di 5-10 minuti per il "passaggio" in produzione.

Step 7 — Esegui l'aggiornamento in produzione

Quando staging è verde, ripeti la stessa sequenza in produzione. Sequenza comandi:

# 1. backup di sicurezza immediato
ssh prod "wp db export /var/backups/wp_pre70_$(date +%Y%m%d).sql --allow-root"

# 2. attiva manutenzione
ssh prod "wp maintenance-mode activate --allow-root"

# 3. aggiorna il core
ssh prod "wp core update --skip-themes --skip-plugins --allow-root"

# 4. aggiorna plugin e temi uno a uno
ssh prod "wp plugin update --all --allow-root"
ssh prod "wp theme update --all --allow-root"

# 5. disattiva manutenzione
ssh prod "wp maintenance-mode deactivate --allow-root"

La finestra in cui il sito mostra la pagina "Sito in manutenzione" è idealmente sotto i 60 secondi: il tempo necessario a scaricare il nuovo core, decomprimerlo, aggiornare il DB e spegnere la modalità. Per ridurla, puoi pre-scaricare il pacchetto del core sul server ed eseguire un aggiornamento "minore" da file system.

Step 8 — Smoke test post-aggiornamento

Subito dopo aver spento la manutenzione, esegui:

• Verifica HTTP 200 su homepage, una pagina interna, il backend (wp post list via WP-CLI)
• Controlla i log delle ultime 5 minuti: nessun errore fatale PHP o MySQL?
• Apri Chrome DevTools, disabilita cache, ricarica: la pagina risponde in <1s?
• Controlla che i cron di sistema siano partiti (wp cron event list)

Strategia di rollback: il piano B

Nonostante tutta la preparazione, può succedere che qualcosa si rompa. Avere un rollback misurato è la differenza tra un'ora di stress e un downgrade in 10 minuti. Le opzioni sono tre, in ordine di robustezza.

Confronto rapido delle tre opzioni di rollback

Prima di scegliere, valuta pro, contro e casi d'uso. La soluzione giusta dipende da quanto tempo hai e da quale rischio devi mitigare.

Con oltre il 43% dei siti web mondiali basati su WordPress, ogni aggiornamento ha un impatto miliardario sul panorama digitale. In questa guida approfondita, esploreremo ogni singola novità introdotta in WordPress 7.0, analizzando come queste funzionalità possono migliorare il tuo workflow quotidiano e le performance del tuo sito.

Editor Gutenberg 5.0: Il Cuore della Nuova Esperienza

Layout Blocco Maggiormente Flessibili

L'editor Gutenberg raggiunge la versione 5.0 con miglioramenti rivoluzionari nella gestione dei layout. La griglia responsiva è stata completamente riprogettata, permettendo ora di creare design complessi senza necessità di codice personalizzato.

Le nuove opzioni di ancoraggio consentono di creare menu di navigazione interni con un semplice clic, migliorando drasticamente l'esperienza utente sui contenuti lunghi. È possibile definire fino a 25 blocchi di ancoraggio per documento, con preview in tempo reale durante la selezione della posizione.

Pattern Globali Rinnovati

WordPress 7.0 introduce il concetto di Pattern Globali, blocchi predefiniti che è possibile sincronizzare attraverso più pagine del sito. Modificando un Pattern Globale, tutte le istanze vengono aggiornate automaticamente, risparmiando ore di lavoro manuale.

La libreria di pattern preinstallati è stata espansa con oltre 50 nuovi design per header, footer, sezioni hero e layout per portfolio. Ogni pattern è completamente personalizzabile e ottimizzato per dispositivi mobili.

Supporto Nativo per Template Dinamici

L'integrazione tra Gutenberg e i template PHP è ora seamless. Gli sviluppatori possono definire aree di blocchi nativi all'interno dei template theme, con fallback intelligenti che preservano la compatibilità con le versioni precedenti.

Miglioramenti alle Performance

Sistema di Cache Intelligente

WordPress 7.0 introduce un sistema di cache integrato di nuova generazione. L'algoritmo di invalidazione cache ora utilizza il machine learning per prevedere quali pagine devono essere rigenerate, riducendo i tempi di caricamento del 67% nei test comparativi.

La cache oggetto integrata gestisce automaticamente la memorizzazione delle query database più frequenti, con un'interfaccia di debug rivista che mostra in tempo reale l'efficienza della cache e suggerisce ottimizzazioni specifiche.

Caricamento Lazy Immagini Avanzato

Il sistema di lazy loading nativo di WordPress è stato potenziato con supporto per priority loading. È ora possibile definire quali immagini devono caricarsi immediatamente (above the fold) e quali possono attendere, con un risparmio medio del 34% nel Largest Contentful Paint (LCP).

Le immagini WebP vengono servite automaticamente quando supportate dal browser, con conversione on-the-fly per i formati PNG e JPEG originali. Il sistema поддерживает la qualità personalizzabile per ogni tipo di contenuto.

Database Ottimizzato

Le tabelle del database sono state ristrutturate per supportare query più efficienti. L'indice full-text è ora disponibile nativamente per i post type personalizzati, con supporto per lingue straniere e caratteri speciali completamente rivisto.

Nuove API per Sviluppatori

REST API Estesa

WordPress 7.0 introduce nuovi endpoint REST per la gestione completa dei contenuti. L'API ora supporta operazioni batch, permettendo di creare, modificare ed eliminare multiple risorse con una singola chiamata HTTP.

Gli sviluppatori possono ora registrare campi personalizzati direttamente dall'API, con validazione schema integrata e supporto per campi relazionali tra post type differenti.

Block Locking API

Una delle funzionalità più richieste dalla community è finalmente realtà: la Block Locking API permette di definire quali proprietà dei blocchi possono essere modificate dagli editor. È possibile bloccare posizione, contenuto, stile o attributi specifici di ogni blocco.

Questa funzionalità è ideale per temi e plugin che necessitano di preservare elementi di design essenziali, offrendo al contempo flessibilità per il contenuto.

Interactivity API Migliorata

L'Interactivity API introdotta in precedenza riceve importanti aggiornamenti. Il sistema di store centralizzato supporta ora la persistenza lato client, con sincronizzazione automatica tra tabs del browser e supporto per azioni offline.

Miglioramenti Sicurezza

Autenticazione a Due Fattori Nativa

WordPress 7.0 include finalmente l'autenticazione a due fattori (2FA) come funzionalità core. L'implementazione supporta TOTP (Time-based One-Time Password), chiavi di sicurezza hardware FIDO2/WebAuthn e codici di backup recuperabili.

Gli amministratori possono rendere obbligatorio il 2FA per ruoli specifici, con opzioni di esenzione per utenti fidati e whitelist IP personalizzabili.

Sistema di Audit Log Migliorato

Il logging delle attività è stato completamente riscritto. Ogni azione amministrativa viene tracciata con timestamp preciso, indirizzo IP e user agent. I log sono interrogabili via REST API per integrazione con sistemi SIEM esterni.

Gestione Temi e Plugin

Repository Temi Aggiornato

La directory dei temi su wordpress.org ha ricevuto un restyling completo con filter avanzati per tag, caratteristiche (block-based, full-site editing ready) e statistiche di installazione in tempo reale.

I temi block-based vengono ora evidenziati con badge dedicato e suggeriti automaticamente durante la creazione di nuovi siti.

Compatibilità Plugin Automatica

WordPress 7.0 analizza automaticamente la compatibilità dei plugin installati con le nuove versioni del core. Un sistema di notifica proattivo informa gli amministratori di potenziali conflitti prima che causino problemi al sito.

Conclusioni e Prossimi Passi

WordPress 7.0 segna un punto di svolta nella storia del CMS, portando funzionalità che in passato richiedevano plugin di terze parti direttamente nel core. L'editor Gutenberg matura verso una stabilità definitiva, le performance migliorano sensibilmente e gli strumenti per sviluppatori offrono possibilità prima impensabili.

Per sfruttare al meglio queste novità, ti consigliamo di:

• Aggiornare il tuo ambiente di staging prima di applicare le modifiche in produzione

• Verificare la compatibilità di temi e plugin con la nuova versione

• Esplorare i nuovi pattern globali per velocizzare la creazione contenuti

• Implementare l'autenticazione a due fattori per tutti gli account amministratori

Hai già testato WordPress 7.0? Condividi la tua esperienza nei commenti e raccontaci quali funzionalità ti hanno colpito di più!

Se questo articolo ti è stato utile, condividilo con la tua rete professionale e iscriviti alla nostra newsletter per ricevere aggiornamenti sulle prossime release WordPress.