Quando nel 2026 si parla di WordPress 7.0 AI Connectors la maggior parte delle guide si ferma alla schermata di configurazione e all'elenco dei provider supportati. Il Bridge layer, che è il componente architetturale centrale introdotto con WordPress 7.0 e approfondito da Kinsta nella sua analisi architetturale "WordPress AI integration: Architecture and a real-world example" pubblicata nell'agosto 2026, resta quasi sempre sullo sfondo. Eppure è esattamente lì che si decide la qualità di un plugin AI: un Bridge layer trattato come una semplice funzione di passaggio verso un provider API produce un plugin fragile, con costi imprevedibili e comportamenti diversi per ogni connettore. Trattato come una interfaccia contract-driven con capability distinte, retry, telemetria e gestione della concorrenza, diventa la base per plugin AI che reggono anni di produzione.

Nei prossimi paragrafi attraversiamo il Bridge layer come lo tratterebbe uno sviluppatore senior: cos'è davvero, quali sono gli errori classici di chi scrive il primo plugin AI, come costruire un caso reale audio-to-text che usa il Bridge per trascrizione Whisper e sintesi vocale ElevenLabs, e come progettare il plugin per scalare su siti con migliaia di utenti senza bucare il budget. Non serve imparare una nuova SDK proprietaria: serve solo capire cosa promette il Bridge e cosa invece tocca ancora a te.

Questo articolo completa il quadro iniziato con la guida ai Connectors di WordPress 7.0 e il pattern ufficiale Plugin Team 2026 basato su MCP e abilities, portandolo dal piano architetturale al piano del codice di plugin pronto per un repository pubblico.

Cos'è davvero il Bridge layer (e perché non è un wrapper)

Il Bridge layer è la superficie PHP uniforme introdotta con WordPress 7.0 che permette a qualsiasi plugin di inviare istruzioni, prompt, file multimediali e strutture dati verso un provider AI senza conoscere i dettagli del protocollo del provider stesso. La confusione nasce dal fatto che, nel core, wp_ai_request() sembra una semplice funzione di chiamata. In realtà è il punto di accesso a una pipeline con cinque responsabilità distinte: serializzazione del payload nel formato atteso dal Connector attivo, applicazione dei limiti (rate limit, token cap, dimensione file), instradamento verso il Connector selezionato, gestione della risposta (incluso streaming per modelli che lo supportano) e propagazione degli errori con una gerarchia di eccezioni specifica (WP_AI_Quota_Exceeded, WP_AI_Safety_Blocked, WP_AI_Transient_Error e così via).

Quando il Bridge è usato come un wrapper - ovvero come se fosse una chiamata diretta a OpenAI o Anthropic - il plugin si lega a un singolo provider e perde la portabilità che i Connectors promettono. Quando invece il Bridge è usato come un contratto - chiedendo al Bridge una capability ("trascrivi questo audio in testo", "sintetizza 700 caratteri di testo in voce") senza imporre quale provider la esegua - il plugin diventa portabile tra provider, sopravvive a cambi di connettore e può essere testato contro un Connector mock senza dipendere da una chiave API live.

Da un punto di vista più ampio, il Bridge layer è il componente che permette al core di WordPress di esporre la capacità AI come una risorsa del sistema operativo, non come un hack applicativo. Questa è la stessa logica che muove l'Abilities API introdotta con WordPress 6.9: una volta che esiste un contratto standard, plugin diversi possono esporre funzionalità compatibili senza che ognuno reimplementi l'integrazione con il provider.

I tre errori classici del primo plugin AI

La maggior parte dei plugin AI scritti nella prima metà del 2026 cade in uno o più di tre errori che avrebbero potuto essere evitati ripensando il Bridge come un contratto. Vediamoli.

1. Chiamare direttamente il Connector invece del Bridge

Il primo errore è pensare che il Bridge sia un optional e che per risparmiare hop di rete convenga chiamare direttamente il Connector attivo. In un'installazione dove il cliente ha configurato OpenAI, funziona. Appena il cliente passa a Claude per ragioni di costo, il plugin si rompe. Il Bridge esiste esattamente per evitare questa dipendenza: il tuo plugin chiede al Bridge una capability ("voglio Whisper Large v3"), il Bridge la instrada verso il Connector opportuno, e tu non sai (e non ti importa) quale provider la sta eseguendo.

2. Ignorare i limiti dichiarati dal Connector

Ogni Connector dichiara i propri limiti operativi: token per minuto per il piano scelto, MB per file sul caricamento audio, finestra di contesto del modello selezionato. Il Bridge ti restituisce questi limiti se li chiedi tramite wp_ai_get_connector_capabilities(). Il secondo errore è partire con il payload "a fiducia", sperando che il Connector rifiuti i task troppo grandi. Così si finisce con chiamate che timeout a 60 secondi, crediti bruciati e utenti che si lamentano del plugin, non del Connector.

3. Non implementare retry e idempotenza

Le API AI sono reti unreliable per natura: un errore 429 in fase di rate-limit, un 503 del provider, un 504 del gateway intermedio sono eventi normali, non eccezioni. Il Bridge restituisce questi errori come WP_AI_Transient_Error, con una eccezione che ha una proprietà retry_after con il numero di secondi suggeriti. Il terzo errore classico è non gestire la transient error: il plugin fallisce al primo errore di rete, l'utente clicca di nuovo, e il prompt duplicato finisce per essere eseguito due volte con doppio costo.

Per evitare questi errori, prima di scrivere qualsiasi plugin AI vale la pena rileggere la documentazione ufficiale del Bridge su make.wordpress.org/core e le analisi che il Plugin Team ha pubblicato sui prerequisiti per la review dei plugin AI-assisted nel 2026.

Architettura del nostro plugin di esempio

Per dare concretezza al discorso, costruiamo un plugin reale che fa due cose solo apparentemente banali: trascrive un file audio caricato nella libreria media usando il Bridge layer con modello Whisper, e genera una versione audio sintetica (text-to-speech) di un estratto dell'articolo usando il Bridge con un modello vocale come ElevenLabs. È un caso che migliaia di editori e podcast avrebbero voluto avere nel 2025 ma che potevano implementare solo con chiamate dirette a OpenAI o ElevenLabs.

Il plugin, che chiameremo wp-podcast-bridge, si compone di quattro blocchi. Il primo è un custom post type episode con metadati per trascrizione, lingua di origine, lunghezza audio. Il secondo è un servizio Bridge_Audio_Service che incapsula tutte le chiamate al Bridge, con metodi come transcribe( $attachment_id, $language = 'auto' ) e synthesize( $post_id, $voice_id, $max_chars = 700 ). Il terzo è una classe Cost_Tracker che registra in una tabella custom il consumo di token per episodio, così da poter mostrare al cliente quanto sta spendendo senza dover aprire la dashboard del provider. Il quarto è una interfaccia REST con due endpoint, /wp-podcast-bridge/v1/transcribe e /wp-podcast-bridge/v1/synthesize, protetti da capability checks.

<?php
/**
 * Plugin Name: WP Podcast Bridge
 * Description: Trascrizione Whisper e sintesi vocale via WordPress AI Bridge layer.
 * Version:     1.0.0
 * Requires at least: 6.9
 * Requires PHP: 7.4
 *
 * AI Use Disclosure: questo plugin consuma il Bridge AI layer introdotto
 * con WordPress 7.0 per le capability di trascrizione audio e sintesi vocale.
 * Nessuna SDK proprietaria di provider viene inclusa.
 */

defined( 'ABSPATH' ) || exit;

class Bridge_Audio_Service {

    private const CAPABILITY_TRANSCRIBE  = 'wp_ai.audio.transcribe';
    private const CAPABILITY_SYNTHESIZE  = 'wp_ai.audio.synthesize';

    public function transcribe( int $attachment_id, string $language = 'auto' ): array|WP_Error {
        $file = get_attached_file( $attachment_id );
        if ( ! $file || ! is_readable( $file ) ) {
            return new WP_Error( 'no_file', 'Allegato non leggibile.' );
        }

        // capability check esplicito prima della chiamata al Bridge
        if ( ! wp_ai_current_user_can( self::CAPABILITY_TRANSCRIBE ) ) {
            return new WP_Error( 'forbidden', 'Capability mancante per la trascrizione.' );
        }

        // recupero il Bridge handler
        $bridge = wp_ai_get_bridge();
        if ( is_wp_error( $bridge ) ) {
            return $bridge;
        }

        // payload dichiara la capability, non il provider
        $payload = array(
            'capability' => self::CAPABILITY_TRANSCRIBE,
            'input'      => array(
                'file_path' => $file,
                'language'  => $language,
                'format'    => pathinfo( $file, PATHINFO_EXTENSION ),
            ),
            'options'    => array(
                'max_retries' => 3,
                'timeout'     => 120,
            ),
        );

        $response = wp_ai_request( $payload );

        if ( is_wp_error( $response ) ) {
            $this->log_failure( 'transcribe', $response );
            return $response;
        }

        return array(
            'text'      => $response['text'] ?? '',
            'language'  => $response['language'] ?? $language,
            'segments'  => $response['segments'] ?? array(),
            'provider'  => $response['provider'] ?? 'unknown',
            'cost_usd'  => $response['cost_usd'] ?? null,
        );
    }
}

Questa è la versione completa del Bridge service per la trascrizione. Si noti che nessun riferimento al provider compare esplicitamente: è il Bridge che sceglie, in base al Connector attivo e alla capability richiesta.

Gestione di rate limit, retry e idempotency key

Il Bridge restituisce errori con una gerarchia ricca che non va ignorata. Una WP_AI_Quota_Exceeded significa che l'utente ha esaurito il budget del piano, non c'è retry che tenga: meglio bloccare la coda e mostrare un messaggio chiaro. Una WP_AI_Transient_Error ha invece una proprietà retry_after numerica: rispettarla prima di ritentare.

Nel nostro plugin usiamo un decoratore che avvolge la chiamata al Bridge con un retry esponenziale e una idempotency key derivata da episode_id + step_name + content_hash. In questo modo una stessa richiesta, se ritentata, non genera un doppio addebito sul provider.

<?php
class Bridge_Request_With_Retry {

    private int $max_attempts = 4;

    public function execute( callable $callback, string $idempotency_key ) {
        $attempt = 0;
        $delay   = 1;

        while ( $attempt < $this->max_attempts ) {
            $attempt++;
            $response = $callback();

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

            $error_code = $response->get_error_code();

            // transient error: respect retry_after
            if ( 'wp_ai_transient_error' === $error_code ) {
                $retry_after = (int) $response->get_error_data( 'retry_after' );
                sleep( max( $delay, $retry_after ) );
                $delay *= 2;
                continue;
            }

            // quota esaurita: stop immediato, niente retry
            if ( 'wp_ai_quota_exceeded' === $error_code ) {
                return $response;
            }

            // errore non transitorio: logga e stop
            return $response;
        }

        return new WP_Error( 'max_retries', 'Numero massimo di retry raggiunto.' );
    }
}

Il decoratore non è una scelta di design opzionale. Senza retry intelligente, il plugin fallisce tre volte su dieci in condizioni di reale produzione e l'utente pensa che il Bridge sia inaffidabile, quando invece è il plugin a esserlo.

Cost tracker: spendere meno di quanto si pensava

Un aspetto trascurato del Bridge layer è che il core non espone automaticamente la dashboard dei costi del Connector: lascia al plugin la responsabilità di tracciarli. Un plugin che non traccia nulla finisce per essere un buco nei costi del cliente, e i clienti questo non lo perdonano.

<?php
class Bridge_Cost_Tracker {

    private string $table;

    public function __construct() {
        global $wpdb;
        $this->table = $wpdb->prefix . 'wp_podcast_bridge_costs';
    }

    public function record( int $episode_id, string $capability, array $response ): void {
        if ( empty( $response['cost_usd'] ) ) {
            return;
        }

        global $wpdb;
        $wpdb->insert(
            $this->table,
            array(
                'episode_id'      => $episode_id,
                'capability'      => $capability,
                'provider'        => $response['provider'] ?? 'unknown',
                'cost_usd'        => (float) $response['cost_usd'],
                'tokens_in'       => (int) ( $response['tokens_in']  ?? 0 ),
                'tokens_out'      => (int) ( $response['tokens_out'] ?? 0 ),
                'recorded_at'     => current_time( 'mysql', true ),
            ),
            array( '%d', '%s', '%s', '%f', '%d', '%d', '%s' )
        );
    }

    public function monthly_cost_usd(): float {
        global $wpdb;
        $start = gmdate( 'Y-m-01 00:00:00' );

        // somma del costo del mese corrente
        $sum = (float) $wpdb->get_var(
            $wpdb->prepare(
                "SELECT COALESCE(SUM(cost_usd), 0) FROM {$this->table} WHERE recorded_at >= %s",
                $start
            )
        );

        return $sum;
    }
}

Con questa classe, il plugin può mostrare al cliente nel back-office una riga "costo mensile AI: € 12,40 (3,1 ore di audio trascritte, 14 sintesi vocali)" prima ancora che il cliente apra la dashboard del provider. È una funzionalità che vale molto più di qualsiasi ottimizzazione di prestazioni, perché rende il costo un dato anziché un mistero.

Confronto rapido: Bridge vs chiamata diretta al provider

La scelta del Bridge non è solo una questione di eleganza architetturale: nel 2026 chi scrive plugin senza passare dal Bridge layer si espone al rischio concreto di rifiuto al triage del Plugin Team WordPress, che considera esplicitamente la conformità al Bridge un prerequisito di qualità.

Testing del plugin senza chiave API live

Una conseguenza spesso sottovalutata del Bridge layer è che il plugin diventa testabile in CI senza toccare la rete. È sufficiente registrare un Connector di test che implementa la stessa interfaccia ma restituisce risposte statiche.

<?php
class Bridge_Mock_Connector implements WP_AI_Connector_Interface {

    public function slug(): string {
        return 'mock';
    }

    public function supports( string $capability ): bool {
        return in_array( $capability, array(
            'wp_ai.audio.transcribe',
            'wp_ai.audio.synthesize',
        ), true );
    }

    public function execute( array $payload ) {
        if ( 'wp_ai.audio.transcribe' === $payload['capability'] ) {
            return array(
                'text'       => 'Trascrizione di test.',
                'language'   => 'it',
                'provider'   => 'mock',
                'cost_usd'   => 0.0,
                'tokens_in'  => 0,
                'tokens_out' => 4,
            );
        }
        return array();
    }
}

add_filter( 'wp_ai_register_connector', function( $connectors ) {
    if ( defined( 'WP_PODCAST_BRIDGE_TESTING' ) ) {
        $connectors[] = new Bridge_Mock_Connector();
    }
    return $connectors;
} );

Con questo Connector fittizio, il test runner PHPUnit può eseguire tutti i test del plugin senza dipendere da una chiave API, da una connessione internet o dalla disponibilità del provider. È una garanzia enorme per la qualità del plugin su migliaia di installazioni attive.

Dove arriva il Bridge nei prossimi mesi

Il Bridge layer consegnato con WordPress 7.0 è solo la prima iterazione. La roadmap resa pubblica dal core team prevede per il rilascio di WordPress 7.1 (in arrivo il 19 agosto 2026, come annunciato da Kinsta) l'integrazione con la Abilities API introdotta in 6.9, così da permettere ai plugin di esporre capability di alto livello che il Bridge può instradare su più provider in fallback. Questo significa che plugin scritti oggi con un Bridge capability-based saranno già compatibili con la release 7.1 senza modifiche. Plugin che invece chiamano direttamente il provider dovranno essere riscritti o mantenuti manualmente per sempre.

In una prospettiva più lunga, il Bridge layer è anche l'elemento che abilita gli scenari di hosting managed con AI integrata di cui abbiamo parlato nella guida al hosting white-label con AI: se il Bridge è un contratto, un hosting provider può offrire Connector custom, garantire SLA, fatturare a consumo, e disaccoppiare la scelta del provider AI dall'esperienza del cliente finale.

Lista di controllo per un plugin AI Bridge-ready

Prima di rilasciare un plugin che consuma il Bridge layer, vale la pena passare in rassegna questa checklist.

• Il plugin chiama solo wp_ai_request() e mai direttamente il provider.
• Il payload usa la chiave capability per descrivere cosa vuole, non quale provider usare.
• Il plugin gestisce WP_AI_Quota_Exceeded con messaggio chiaro, senza retry.
• Il plugin gestisce WP_AI_Transient_Error con retry_after rispettato.
• Il plugin traccia i costi via Bridge in una tabella custom o tramite opzione.
• Le capability sono verificate con wp_ai_current_user_can() prima di ogni chiamata.
• Il plugin include un Connector mock per i test PHPUnit in CI.
• Il plugin dichiara requires at least: 7.0 nel header del file principale.
• Il plugin documenta nel readme.txt la sezione AI Use Disclosure obbligatoria dal Q4 2026, secondo quanto discusso in AI-use disclosure plugin WordPress.

Domande frequenti

Il Bridge layer sostituisce le SDK dei provider? Sostituisce l'integrazione. Le SDK rimangono dentro il Connector e sono gestite dal core, non dal tuo plugin.

Posso continuare a chiamare direttamente OpenAI dal mio plugin? Tecnicamente sì, ma perderai portabilità, telemetria centralizzata e conformità alle linee guida 2026 del Plugin Team.

Cosa succede se l'utente non ha configurato nessun Connector? Il Bridge restituisce un WP_Error con codice no_connector. Il plugin deve gestirlo esplicitamente e mostrare un messaggio che invita alla configurazione.

Il Bridge è disponibile anche in WordPress 6.9? No. Il Bridge layer è stato introdotto con WordPress 7.0. Per 6.9 esiste la sola Abilities API, che è complementare ma non sostitutiva.

Come posso esporre il mio plugin come Connector per altri plugin? Registrandolo con wp_ai_register_connector() e implementando l'interfaccia WP_AI_Connector_Interface. È il pattern che i Bridge ufficiali di OpenAI, Anthropic e Google hanno seguito.

Riferimenti utili per approfondire

• WordPress 7.0 AI Connectors: guida operativa per sviluppatori e agenzie - panoramica introduttiva sul sistema Connector + Bridge.
• Plugin AI WordPress con MCP e abilities: pattern ufficiale 2026 - come costruire plugin AI che dialogano anche con MCP.
• Abilities API WordPress 6.9: guida operativa 2026 completa - il complemento del Bridge per capability non-AI.
• WordPress Plugin Team 2026: come il triage AI cambia le regole per chi pubblica - linee guida di submission e conformità Bridge.
• Kinsta Blog - WordPress AI integration: Architecture and a real-world example - articolo fonte per l'analisi architetturale del Bridge.
• Kinsta Blog - Getting started with the WordPress Abilities API - guida pratica all'Abilities API di WordPress 6.9.
• Documentazione ufficiale Bridge AI su make.wordpress.org/core - riferimento canonico per signature delle funzioni e gerarchia errori.
• WordPress AI Bridge layer su GitHub - wordPress/wp-ai-client - repository ufficiale con esempi di plugin che consumano il Bridge.
• AI-use disclosure plugin WordPress: come prepararsi al nuovo standard del directory - sezione AI Use Disclosure obbligatoria dal Q4 2026.
• WordPress Hosting AI white-label: integrare AI senza diventare rivenditore OpenAI - come sfruttare il Bridge per scenari hosting managed.

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

Hai mai desiderato aggiungere funzionalità personalizzate al tuo sito WordPress senza dipendere da plugin di terze parti? Creare un plugin wordpress personalizzato ti permette di estendere le capacità del tuo sito in modo pulito, organizzato e riutilizzabile. In questo tutorial plugin wp completo, ti guiderò passo dopo passo nella creazione del tuo primo plugin WordPress, partendo dalle basi fino ad arrivare a implementazioni più avanzate.

Perché Creare un Plugin WordPress Personalizzato

Prima di immergerci nel processo di sviluppo, è fondamentale comprendere perché potresti aver bisogno di un plugin personalizzato. WordPress offre migliaia di plugin gratuiti e premium attraverso il repository ufficiale, ma ci sono situazioni in cui un plugin personalizzato rappresenta la soluzione migliore:

• Esigenze specifiche: Hai requisiti unici che nessun plugin esistente soddisfa completamente
• Prestazioni: Vuoi evitare l’overhead di plugin complessi con funzionalità che non utilizzi
• Manutenzione: Preferisci controllare completamente il codice senza dipendere da sviluppatori terzi
• Sicurezza: Riduci la superficie di attacco eliminando plugin non necessari
• Apprendimento: Desideri comprendere come funziona internamente WordPress

Creare un plugin wordpress significa anche organizzare meglio il tuo codice. A differenza delle funzioni inserite nel file functions.php del tema, un plugin rimane attivo anche quando cambi tema, garantendo la persistenza delle funzionalità.

Prerequisiti per lo Sviluppo di Plugin WordPress

Per seguire questo tutorial plugin wp in modo efficace, dovresti avere familiarità con alcuni concetti fondamentali:

Conoscenze Tecniche Necessarie

• PHP: WordPress è costruito principalmente su PHP, quindi una solida comprensione del linguaggio è essenziale. Devi conoscere variabili, funzioni, array, oggetti e programmazione orientata agli oggetti
• HTML/CSS: Per creare interfacce di amministrazione e frontend
• JavaScript: Per funzionalità lato client e interazioni AJAX
• MySQL: Comprensione base delle query database (WordPress offre astrazioni che semplificano questo aspetto)

Strumenti di Sviluppo Consigliati

• Ambiente locale: Utilizza software come Local by Flywheel, XAMPP o Docker per creare un ambiente di test
• Editor di codice: VS Code, PhpStorm o Sublime Text con estensioni per WordPress
• Version Control: Git per tracciare le modifiche e gestire le versioni del tuo plugin

Struttura Base di un Plugin WordPress

Un plugin wordpress ben strutturato segue convenzioni specifiche che permettono a WordPress di riconoscerlo, attivarlo e gestirlo correttamente. Analizziamo la struttura essenziale:

La Directory del Plugin

Ogni plugin risiede nella directory wp-content/plugins/ di WordPress. Crea una cartella con un nome unico, preferibilmente prefissato per evitare conflitti con altri plugin.

wp-content/
  └── plugins/
      └── mio-plugin-personalizzato/
          ├── mio-plugin-personalizzato.php
          ├── index.php
          ├── README.txt
          └── assets/
              ├── css/
              ├── js/
              └── images/

Il File Principale del Plugin

Il file principale del plugin deve contenere l’header di documentazione che permette a WordPress di identificare il plugin nel pannello di amministrazione. Ecco un esempio di header standard:

<?php
/
Plugin Name: Mio Plugin Personalizzato
Plugin URI: https://esempio.com/mio-plugin
Description: Una breve descrizione delle funzionalità del plugin
Version: 1.0.0
Author: Il Tuo Nome
Author URI: https://esempio.com
License: GPL v2 or later
Text Domain: mio-plugin-personalizzato
Domain Path: /languages
/

Senza questo header, il plugin non apparirà nella lista dei plugin installabili in WordPress.

Guida Passo-Passo: Creare il Tuo Primo Plugin WordPress

Ora che comprendi la struttura base, procediamo con la creazione di un plugin funzionale. In questo esempio, creeremo un plugin che aggiunge un widget per visualizzare informazioni personalizzate nel footer.

Passaggio 1: Creare la Struttura Base

Apri il tuo editor di codice preferito e crea una nuova cartella chiamata mio-plugin-footer. Al suo interno, crea il file principale mio-plugin-footer.php.

Passaggio 2: Definire le Costanti del Plugin

È buona pratica definire costanti per il percorso e l’URL del plugin, facilitando riferimenti successivi:

<?php
// Evita accesso diretto
defined('ABSPATH') or die('Accesso non consentito');

// Costanti del plugin
define('MPF_PLUGIN_DIR', plugin_dir_path(__FILE__));
define('MPF_PLUGIN_URL', plugin_dir_url(__FILE__));
define('MPF_PLUGIN_VERSION', '1.0.0');

Passaggio 3: Creare la Classe del Plugin

La programmazione orientata agli oggetti (OOP) mantiene il codice organizzato e previene conflitti con altri plugin:

class Mio_Plugin_Footer {

    /
      Istanza singleton
      @var Mio_Plugin_Footer
     /
    private static $instance = null;

    /
      Ottieni l'istanza singleton
     /
    public static function get_instance() {
        if (null === self::$instance) {
            self::$instance = new self();
        }
        return self::$instance;
    }

    /
      Costruttore - inizializza gli hook
     /
    private function __construct() {
        add_action('wp_footer', array($this, ' mostra_contenuto_footer'));
        add_action('wp_enqueue_scripts', array($this, 'carica_stili'));
    }

    /
      Carica gli stili CSS
     /
    public function carica_stili() {
        wp_enqueue_style(
            'mpf-plugin-styles',
            MPF_PLUGIN_URL . 'assets/css/style.css',
            array(),
            MPF_PLUGIN_VERSION
        );
    }

    /**
      Mostra il contenuto nel footer
     /
    public function mostra_contenuto_footer() {
        echo '<div id="mpf-footer-info">';
        echo '<p>Plugin creato con successo!</p>';
        echo '</div>';
    }
}

// Inizializza il plugin
Mio_Plugin_Footer::get_instance();

#mpf-footer-info {
    background-color: #f8f9fa;
    padding: 20px;
    text-align: center;
    border-top: 3px solid #007bff;
    margin-top: 30px;
}

#mpf-footer-info p {
    margin: 0;
    color: #333;
    font-size: 14px;
}

// Aggiungi il menu nel pannello admin
add_action('admin_menu', function() {
    add_options_page(
        'Impostazioni Mio Plugin',
        'Mio Plugin Footer',
        'manage_options',
        'mpf-settings',
        'mpf_render_settings_page'
    );
});

// Renderizza la pagina delle impostazioni
function mpf_render_settings_page() {
    // Verifica permessi
    if (!current_user_can('manage_options')) {
        return;
    }
    ?>
    <div class="wrap">
        <h1>Impostazioni Mio Plugin Footer</h1>
        <form method="post" action="options.php">
            <?php
            settings_fields('mpf_settings_group');
            do_settings_sections('mpf-settings');
            submit_button();
            ?>
        </form>
    </div>
    <?php
}

// Registra le impostazioni
add_action('admin_init', function() {
    register_setting('mpf_settings_group', 'mpf_footer_text', array(
        'sanitize_callback' => 'sanitize_text_field'
    ));

    add_settings_section(
        'mpf_main_section',
        'Configurazione Footer',
        null,
        'mpf-settings'
    );

    add_settings_field(
        'mpf_footer_text',
        'Testo da visualizzare',
        function() {
            $value = get_option('mpf_footer_text', 'Testo predefinito');
            echo '<input type="text" name="mpf_footer_text" value="' . esc_attr($value) . '" class="regular-text">';
        },
        'mpf-settings',
        'mpf_main_section'
    );
});

// Sanitizzazione dell'input
$testo = sanitize_text_field($_POST['testo']);

// Escape dell'output
echo esc_html($testo);
echo esc_attr($testo);
echo esc_url($url);

// Preparazione query database
global $wpdb;
$risultato = $wpdb->get_var(
    $wpdb->prepare(
        "SELECT  FROM {$wpdb->posts} WHERE ID = %d",
        $id
    )
);

Performance

Evita di caricare risorse su pagine dove non sono necessarie:

// Carica script solo dove necessario
add_action('wp_enqueue_scripts', function() {
    if (is_single()) {
        wp_enqueue_script('mpf-script', MPF_PLUGIN_URL . 'assets/js/script.js', array('jquery'), MPF_PLUGIN_VERSION, true);
    }
});

Compatibilità

Verifica sempre l’esistenza di funzioni prima di usarle per garantire compatibilità con temi e altri plugin:

// Verifica funzioni
if (function_exists('do_blocks')) {
    $content = do_blocks($content);
}

// Verifica classi
if (class_exists('WooCommerce')) {
    // Codice specifico per WooCommerce
}

Hook WordPress: Il Cuore del Plugin

I hook sono fondamentali per l’interazione tra il tuo plugin e WordPress. Comprendere la differenza tra azioni e filtri ti permetterà di manipolare quasi ogni aspetto della piattaforma.

Action Hooks

Le azioni permettono di eseguire codice in specifici momenti:

// Hook durante l'inizializzazione
add_action('init', 'mpf_inizializza_plugin');

// Hook durante il caricamento del footer
add_action('wp_footer', 'mpf_aggiungi_contenuto');

// Hook per caricare risorse
add_action('wp_enqueue_scripts', 'mpf_carica_css');

Filter Hooks

I filtri permettono di modificare dati prima dell’output:

// Modifica il contenuto del post
add_filter('the_content', 'mpf_aggiungi_contenuto_articolo');

// Modifica l'excerpt
add_filter('get_the_excerpt', 'mpf_personalizza_excerpt');

// Modifica il titolo
add_filter('the_title', 'mpf_formatta_titolo');

Debug e Testing del Plugin

Durante lo sviluppo, avrai bisogno di strumenti per identificare e risolvere problemi. Per attivare il debug in WordPress, modifica il file wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Logging Personalizzato

Crea una funzione di logging per tracciare l’esecuzione del plugin:

function mpf_debug_log($messaggio) {
    if (WP_DEBUG === true) {
        error_log('[Mio Plugin] ' . print_r($messaggio, true));
    }
}

Attivazione e Disattivazione del Plugin

WordPress fornisce hook specifici per gestire l’attivazione e la disattivazione del plugin. Questi hook permettono di eseguire operazioni importanti come la creazione di tabelle custom o la pulizia dei dati.

register_activation_hook(__FILE__, 'mpf_attivazione_plugin');

function mpf_attivazione_plugin() {
    // Creare opzioni di default
    add_option('mpf_footer_text', 'Benvenuto nel mio plugin!');

    // Flush rewrite rules se necessario
    flush_rewrite_rules();
}

register_deactivation_hook(__FILE__, 'mpf_disattivazione_plugin');

function mpf_disattivazione_plugin() {
    // Pulizia dati se necessario
    // Non eliminare dati qui per permettere riattivazione
}

Distribuzione del Plugin

Se desideri condividere il tuo plugin wordpress con altri utenti, hai due opzioni principali:

Repository WordPress Ufficiale

Per pubblicare nel repository ufficiale:

1. Registra un account su WordPress.org
2. Crea il file README.txt nel formato richiesto
3. Carica il codice tramite SVN
4. Attendi la revisione del team WordPress

Distribuzione Privata

Per distribuzione privata o commerciale:

1. Comprimi la directory del plugin in formato ZIP
2. Fornisci file di installazione manuale
3. Implementa un sistema di licenze se necessario

Manutenzione e Aggiornamenti

Un plugin richiede manutenzione continua per rimanere sicuro e compatibile:

• Aggiornamenti WordPress: Testa sempre il plugin con le ultime versioni di WordPress
• PHP Evolution: Verifica compatibilità con nuove versioni PHP
• Security Patches: Rimani informato sulle vulnerabilità comuni
• Feedback Utenti: Implementa un sistema di supporto per raccogliere feedback

Conclusione

Creare un plugin wordpress personalizzato è un investimento prezioso per il tuo sito. In questa guida hai imparato le basi fondamentali: dalla struttura di un plugin alla creazione di pagine di impostazioni, dalla sicurezza all’uso dei hook WordPress.

Ricorda che lo sviluppo di plugin è un processo iterativo. Inizia con funzionalità semplici, testa accuratamente, e amplia gradualmente le capacità del tuo plugin. La documentazione ufficiale di WordPress, disponibile sul Codex WordPress, offre risorse aggiuntive per approfondire ogni aspetto.

Se questo è il tuo primo plugin, ti consiglio di iniziare con piccoli progetti prima di affrontare implementazioni complesse. La pratica costante e la lettura del codice di plugin ben sviluppati ti aiuteranno a diventare un sviluppatore WordPress competente.

Hai domande o spunti da condividere sulla creazione di plugin WordPress? Lascia un commento qui sotto, il tuo feedback è sempre gradito!