Cosa sono gli shortcode di WordPress? Una guida pratica

Gli shortcode di WordPress sono brevi snippet di testo racchiusi tra parentesi quadre (come [contact-form] o [gallery ids="1,2,3"]) che WordPress sostituisce con contenuto dinamico quando renderizza un post o una pagina. Sono stati introdotti in WordPress 2.5 (2008) e per oltre un decennio sono diventati il modo dominante in cui i plugin aggiungevano output complesso al contenuto. Dal rilascio dell'editor a blocchi Gutenberg in WordPress 5.0 (2018), gli shortcode hanno un successore: i blocchi. Ma gli shortcode non spariranno. Funzionano ancora, milioni di siti ne dipendono e molti plugin continuano a distribuirli insieme o al posto dei blocchi.

Come si presenta uno shortcode di WordPress?

Lo shortcode di base è un nome tra parentesi quadre:

[gallery]

WordPress lo vede nel contenuto del post, cerca l'handler registrato per gallery, esegue la funzione PHP e sostituisce il tag con qualsiasi HTML l'handler emetta. Il visitatore vede una galleria; l'editor vede [gallery].

Gli shortcode possono prendere parametri (chiamati attributi):

[gallery ids="42,43,44" columns="3" link="file"]

E possono avvolgere contenuto (chiamati shortcode avvolgenti):

[highlight color="yellow"]Testo importante[/highlight]

L'handler dello shortcode riceve gli attributi e il contenuto interno, li elabora in PHP, e restituisce l'HTML da inserire nella pagina. Il visitatore non vede mai le parentesi; vede l'output renderizzato.

Qual è la differenza tra uno shortcode e un blocco Gutenberg?

Entrambi producono contenuto dinamico; differiscono in dove e come quel contenuto viene generato.

• Gli shortcode sono lato server. Il tag tra parentesi quadre rimane nel contenuto del post memorizzato nel database. Quando la pagina è richiesta, WordPress fa il parse del contenuto, trova lo shortcode, esegue l'handler PHP, e sostituisce l'output. La vista dell'editor mostra sempre la sintassi grezza con le parentesi.
• I blocchi sono memorizzati come HTML renderizzato (con commenti di metadati). Quando salvi un post nell'editor a blocchi, il plugin del blocco genera l'HTML finale e lo memorizza nel database. L'editor mostra un'anteprima live del blocco renderizzato, non un tag. Sul frontend, non viene eseguito PHP per renderizzare la maggior parte dei blocchi; l'HTML viene servito direttamente.

Conseguenze pratiche:

• Performance. I blocchi sono più veloci sul frontend perché non c'è uno step di parse-e-sostituisci. Gli shortcode innescano una scansione regex di ogni post a ogni render.
• Esperienza di modifica. I blocchi mostrano come apparirà l'output renderizzato mentre modifichi. Gli shortcode mostrano solo il tag; visualizzi in anteprima il risultato.
• Portabilità. Se disattivi il plugin che fornisce un blocco, l'HTML memorizzato di solito rimane visibile (congelato alla versione dell'ultimo salvataggio). Se disattivi il plugin che fornisce uno shortcode, il tag tra parentesi rimane nel contenuto come testo puro, che di solito sembra rotto.
• Riusabilità. Gli shortcode possono essere aggiunti ovunque venga eseguito PHP, inclusi widget, template ed excerpt. I blocchi sono progettati per l'area dell'editor a blocchi, anche se "Blocchi Riutilizzabili" e il movimento FSE (full-site editing) stanno colmando quel divario.

Quali shortcode integrati di WordPress sono ancora distribuiti nel core?

Il core di WordPress ha storicamente distribuito una manciata di shortcode. Al 2026, i sopravvissuti nel codebase:

• [gallery] — Galleria di immagini. Ancora usata dall'editor classico e come fallback quando il blocco Galleria viene convertito.
• [caption] — Avvolge un'immagine con una didascalia. Per lo più sostituito dal blocco Immagine ma ancora emesso in alcuni workflow.
• [audio] e [video] — Player HTML5 nativo per media auto-ospitati.
• [embed] — Forza un URL a essere embed via l'handler oEmbed. Raramente necessario perché WordPress auto-embed la maggior parte degli URL.
• [playlist] — Playlist audio e video. Uso di nicchia.

La grande maggioranza degli shortcode in qualsiasi sito WordPress reale viene da plugin e temi, non dal core.

Che tipi di plugin usano gli shortcode?

Cinque categorie coprono quasi tutto l'uso reale degli shortcode:

• Moduli di contatto. Contact Form 7 ([contact-form-7 id="123"]), WPForms, Gravity Forms e Formidable espongono tutti moduli via shortcode. Anche quando questi plugin offrono anche blocchi Gutenberg, lo shortcode rimane supportato per la retrocompatibilità.
• E-commerce. WooCommerce usa shortcode per Carrello, Checkout, Il Mio Account e listini prodotti ([products limit="4"]). L'editor a blocchi ora ha blocchi equivalenti, ma gli shortcode dominano ancora perché la maggior parte dei temi è stata costruita intorno a essi.
• Page builder (in modalità legacy). I vecchi Visual Composer, WPBakery e simili producono shortcode massicci annidati quando usati nell'editor classico. Spegnere il page builder lascia un muro di tag [vc_row][vc_column]... come testo puro nel post — un famoso problema di lock-in.
• Tabelle prezzi, slider, accordion. La maggior parte dei plugin "content widget" (Soliloquy, Smart Slider, Easy Pricing Tables) storicamente venivano distribuiti come shortcode. Molti sono ancora attivamente mantenuti ma hanno aggiunto blocchi.
• Siti di membership e apprendimento. MemberPress, LearnDash e simili limitano il contenuto con wrapper di shortcode come [restrict role="member"]...[/restrict].

Come funziona davvero uno shortcode sotto il cofano?

Tre righe di codice plugin creano uno shortcode. Questo esempio minimo registra uno shortcode che emette un'evidenziazione gialla:

add_shortcode('highlight', function ($atts, $content = null) {
    $atts = shortcode_atts([
        'color' => 'yellow',
    ], $atts, 'highlight');

    return '<mark style="background:' . esc_attr($atts['color']) . '">' . do_shortcode($content) . '</mark>';
});

Cosa succede quando WordPress renderizza [highlight color="pink"]Ciao[/highlight]:

1. WordPress esegue il filtro the_content, che include do_shortcode().
2. do_shortcode() usa una regex per trovare i tag shortcode nel contenuto del post.
3. Per ogni corrispondenza, chiama l'handler registrato con gli attributi (['color' => 'pink']) e il contenuto interno ('Ciao').
4. L'handler restituisce una stringa, che sostituisce il tag shortcode nell'output.
5. Il contenuto del post viene poi renderizzato al browser con il tag sostituito.

Il parse regex a ogni render del post è il costo di performance. Su un sito con migliaia di post, senza caching e con shortcode in ogni post, questo si somma. Un page cache (Redis, WP Super Cache) lo risolve memorizzando l'HTML finale renderizzato e saltando il parse.

Quando dovrei ancora usare gli shortcode nel 2026?

Tre casi legittimi:

• Retrocompatibilità. Se il tuo sito usa già shortcode di Contact Form 7, WooCommerce o qualsiasi plugin affermato, continua a usarli. Convertire in massa vecchi post in blocchi è un progetto di più giorni con poco ritorno.
• Fuori dall'editor a blocchi. Widget (in aree widget classiche), excerpt, loop di custom post type, contenuto di page builder, e email inviate via template Mailchimp accettano ancora shortcode ma non blocchi. Gli shortcode funzionano in qualsiasi contesto dove do_shortcode() può essere chiamato.
• Template e codice tema. Mettere echo do_shortcode('[my-form id="3"]'); in un template PHP è un modo a una riga per iniettare output di plugin. I blocchi richiederebbero render di blocco lato server, che è più codice.

Per funzionalità genuinamente nuova su un nuovo sito, preferisci i blocchi. Sono la direzione del core WordPress, hanno una migliore esperienza di modifica, ed evitano l'overhead del parse degli shortcode.

Cos'è il "shortcode bloat" e perché è importante?

Lo shortcode bloat succede quando un sito si affida a dozzine di shortcode da plugin inattivi o disattivati. Seguono due modalità di fallimento:

• Plugin disattivato ma i tag rimangono. Disattivi un plugin slider per testare qualcosa. Ogni pagina che aveva [slider id="3"] ora visualizza il testo letterale "[slider id="3"]" invece di uno slider. La correzione è riattivare il plugin o rimuovere manualmente tutti i tag shortcode dal database, cosa tediosa.
• Migrazione di page builder. Un sito costruito in Visual Composer o WPBakery contiene shortcode annidati come [vc_row][vc_column width="1/2"][vc_column_text]Ciao[/vc_column_text][/vc_column][/vc_row]. Cambiare tema o disattivare il builder rivela tutto questo come testo puro. Questa è la fonte del punto dolente "non posso migrare il mio sito a Gutenberg" che ha intrappolato migliaia di siti.

La prevenzione pragmatica: scegli plugin a cui ti impegni a lungo termine, e preferisci plugin che supportano anche i blocchi così puoi migrare gradualmente. Per siti costruiti prima del 2018, aspettati un vero progetto di migrazione piuttosto che un cambio pulito.

Posso creare il mio shortcode senza scrivere un plugin?

Sì, tre modi:

1. Nel functions.php di un child theme. Aggiungi la chiamata add_shortcode(). Lo shortcode diventa disponibile ovunque sul sito. Funziona ma lo shortcode è legato a quel tema; cambia tema e lo shortcode sparisce.
2. In un mu-plugin custom. Crea wp-content/mu-plugins/my-shortcodes.php e metti lì le tue chiamate add_shortcode(). Sopravvive ai cambi di tema e alla maggior parte degli aggiornamenti. La soluzione più pulita.
3. Tramite un plugin "Code Snippets". Plugin come Code Snippets o WPCode ti permettono di aggiungere PHP tramite l'UI admin. Comodo se non puoi modificare file, ma aggiunge una dipendenza a livello admin per codice che idealmente vive nei file.

Quali sono gli errori comuni con gli shortcode?

• Dimenticare do_shortcode() sul contenuto interno. Se il tuo shortcode avvolge contenuto (shortcode avvolgente), dovresti chiamare do_shortcode($content) sulla parte interna così che gli shortcode annidati funzionino. Senza, [outer][inner][/outer] renderizza solo lo shortcode esterno e lascia [inner] come testo puro.
• Echo dentro l'handler. Gli handler di shortcode devono restituire il loro output, non fare echo. Uno shortcode con echo si renderizza prima del contenuto in cui è embed, rompendo il layout della pagina in modi sottili.
• Dimenticare esc_attr() sugli attributi. Senza escape, i valori di attributo forniti dall'utente possono fuggire dall'HTML e creare vulnerabilità XSS. Escape sempre ciò che emetti.
• Shortcode in widget che non li eseguono. Alcuni tipi di widget classici (come il widget Text base pre-WordPress 4.9) non auto-eseguono shortcode. Correzione: add_filter('widget_text', 'do_shortcode');.
• Tag dentro altri tag che causano confusione di parse. Un attributo shortcode contenente un carattere parentesi quadra ([shortcode label="Click [here]"]) confonde il parser. WordPress gestisce molti casi ma non tutti; usare entità HTML ([ e ]) è il workaround sicuro.
• Aggiungere shortcode a do_shortcode ricorsivamente. Dentro un handler di shortcode, chiamare do_shortcode() su contenuto che contiene lo stesso shortcode crea un loop infinito. WordPress ha protezioni contro questo ma il sintomo è una pagina bianca o un errore di memoria esaurita.

Come trovo ogni shortcode usato sul mio sito?

Tre approcci rapidi:

1. Ricerca nel database. Esegui una query SQL contro wp_posts: SELECT DISTINCT REGEXP_SUBSTR(post_content, '\\[[a-z_-]+') FROM wp_posts WHERE post_status = 'publish';. Elenca ogni tag shortcode che appare nel contenuto pubblicato.
2. WP-CLI. wp shortcode list mostra ogni handler shortcode registrato. Confronta con la lista del database per trovare shortcode che sono usati ma non hanno più un handler attivo (probabilmente da un plugin disattivato).
3. I plugin tipo "Shortcode Cleaner" o "Find My Blocks". Scansionano il contenuto per uso di shortcode e blocchi. Utili prima di disattivare un plugin per vedere quanto ampiamente i suoi shortcode sono usati.

E la sicurezza?

Gli shortcode in sé non sono insicuri; la domanda è cosa fa l'handler con gli attributi. Due modelli di minaccia:

• Un utente non fidato sottomette contenuto contenente shortcode. Se un contributor o subscriber può sottomettere post e lo shortcode esegue codice lato server (come [exec command="..."] da un plugin dev), quello è un percorso di esecuzione arbitraria di codice. Il core di WordPress rimuove gli shortcode dal contenuto sottomesso da utenti a bassi privilegi di default; non disfare questa protezione.
• Gli attributi shortcode sono emessi in modo non sicuro. Uno shortcode scritto male potrebbe fare echo di [badge text="..."] direttamente nella pagina senza escape, permettendo a un admin che modifica un post di iniettare tag script. Mantieni la modifica dei post solo per admin, ed escape sempre i valori di attributo quando scrivi shortcode custom.

Cosa controlla InspectWP

Gli shortcode non sono direttamente parte di un report di sicurezza o performance di InspectWP, ma i loro effetti appaiono in diversi posti. Un sito con shortcode da plugin disattivati ha tipicamente rilievi di "layout rotti" (testo renderizzato contenente parentesi quadre). Un sito con uso pesante di shortcode senza page cache appare come TTFB lento. E un sito dove shortcode di Visual Composer o WPBakery trapelano nell'HTML renderizzato (perché il page builder è rotto o disattivato) appare come errori di render e violazioni di accessibilità. Il pattern raccomandato nel 2026 è continuare a usare shortcode per ragioni legacy, preferire i blocchi per nuovo contenuto, e auditare il sito periodicamente per shortcode i cui handler non sono più registrati.