Cosa sono i custom post type e perché scelgo Metabox per gestirli

Un sito WordPress nasce quasi sempre con due contenitori, pagine e articoli, e per un po’ bastano. Se però arriva il momento in cui il cliente vuole un catalogo prodotti, una sezione portfolio o un elenco di eventi con data e location, allora quei due contenitori cominciano a non bastare più.

Il problema di solito si presenta dopo un po’ di tempo che il sito è online, quando qualcuno prova magari a filtrare i progetti per anno, o vuole un’immagine di copertina diversa da quella del blog, e si accorge che sta chiedendo a un blog di comportarsi come un database.

Un custom post type è un contenitore che WordPress non include di serie

Un custom post type, CPT per chi mastica già l’ambiente, è un tipo di contenuto che definisci tu, con la sua etichetta nel menu di WordPress, i suoi campi, la sua URL, il suo template. “Progetti” diventa un contenitore a sé, separato dagli articoli, con una struttura pensata apposta per quello che deve contenere.

La differenza si vede già nell’URL: un progetto finisce su tuosito.it/progetti/nome-progetto invece che infilato tra gli articoli del blog e in backend compare una voce di menu propria invece di una categoria nascosta dentro Articoli.

WordPress applica anche la sua gerarchia dei template in automatico: se crei un file single-progetto.php o archive-progetto.php nel tema, WordPress li usa da solo per la scheda singola e per l’elenco, senza bisogno di if annidati dentro single.php per capire che tipo di contenuto stai mostrando.

Non è un trucco quanto l’uso che WordPress prevede quando un contenuto smette di essere editoriale e diventa strutturato. E non vale solo per cataloghi o portfolio: testimonianze, membri del team, FAQ, persino le sedi di un’azienda con più negozi sono tutti candidati naturali a diventare un CPT invece che un altro tag.

Creare un custom post type evita di piegare i contenuti a una struttura che non gli appartiene

Il vantaggio è evidente appena provi a interrogare quei contenuti.

Con tutto infilato dentro Articolo e una tassonomia improvvisata, ogni query diventa un filtro su categorie che non sono nate per quello. Ti ritrovi nella maggior parte dei casi a scrivere condizioni tipo “se la categoria è progetti e l’anno nel titolo contiene 2025”. Una follia se il sito diventa strutturato.

Con un CPT dedicato la query parte pulita: new WP_Query(['post_type' => 'progetto', 'orderby' => 'meta_value', 'meta_key' => 'progetto_anno']) e hai già tutti i progetti ordinati per anno, semplice e pulito.

Anche le tassonomie migliorano. Puoi creare una tassonomia “Cliente” o “Settore” dedicata ai progetti, separata dalle categorie del blog, invece di far convivere nello stesso elenco i tag degli articoli e quelli dei progetti. E l’archivio si comporta meglio di suo: WordPress genera già una pagina di listing coerente con quel tipo di contenuto, senza bisogno di ripulire un archivio categoria che non c’entra nulla con quello che devi fare.

C’è un ulteriore beneficio: chi cura i contenuti trova una voce di menu dedicata, con il suo nome, la sua icona, il suo elenco. Tutto più ordinato e di facile gestione.

Un custom post type si registra anche senza nessun plugin

Registrare un CPT non richiede nessun plugin. WordPress mette a disposizione register_post_type(), e nella sua forma più semplice basta questo:

php

function laura_registra_progetti() {
    register_post_type('progetto', [
        'label' => 'Progetti',
        'public' => true,
        'has_archive' => true,
        'supports' => ['title', 'editor', 'thumbnail'],
        'menu_icon' => 'dashicons-portfolio',
    ]);
}
add_action('init', 'laura_registra_progetti');

Con queste poche righe hai già un tipo di contenuto a sé, visibile nel menu, con la sua pagina archivio. Se vuoi che le etichette in amministrazione parlino italiano corretto (“Aggiungi nuovo progetto” invece del generico “Aggiungi nuovo”) serve un array labels più esteso. Vale la pena farlo perché è quello che il tuo cliente legge ogni giorno nel pannello e gli facilita non poco la vita.

Un dettaglio che può fregarti se sei alle prime armi: dopo aver registrato un nuovo post type, le pagine dei progetti restituiscono un 404 finché non salvi una volta i permalink da Impostazioni, oppure non richiami flush_rewrite_rules() all’attivazione del tema o del plugin.

Per un progetto piccolo, con due o tre campi in croce, questo può bastare per ANNI!

Un custom post type funziona finché il progetto resta piccolo

Il problema arriva quando quei campi cominciano a moltiplicarsi. Cliente, anno, categoria, link esterno, galleria immagini: ogni nuovo campo significa aprire di nuovo il codice, aggiungere un meta box a mano con add_meta_box(), gestire il salvataggio con un hook su save_post, validare l’input, sanificarlo.

Ogni meta box scritto a mano si porta dietro il nonce per verificare che il salvataggio arrivi davvero dal form giusto, il controllo sui permessi con current_user_can(), l’escape in output con esc_html() o esc_url() a seconda del campo. Sono tutte cose che vanno fatte, per sicurezza, e che vanno riscritte identiche ogni volta che aggiungi un campo.

Per te diventa un inferno. Chi cura i contenuti non ha nessuna interfaccia per compilare quei campi, li vede solo se qualcuno gliel’ha costruita, e ogni piccola modifica richiesta dal cliente, aggiungere un campo “in evidenza sì/no”, torna ad essere un mezzo dramma.

Una tip: Metabox è il mio salvavita!

Per i campi custom uso Metabox. Non è Advanced Custom Fields, che forse resta lo standard più diffuso e probabilmente il primo nome che chi lavora con WordPress associa a questo genere di plugin.

La scelta è editoriale e tecnica. Metabox nasce interamente gratuito e open source, con le funzioni avanzate (relazioni tra contenuti, logica condizionale, invio dal frontend) vendute come estensioni singole invece che come un abbonamento Pro che sblocca tutto insieme. Se hai un’agenzia che lavora su decine di siti in parallelo, pagare solo l’estensione che quel progetto usa davvero ti pesa economicamente meno che una licenza comprata per una funzione su cinque che magari ti troverai a usare.

Attenzione: non è un giudizio su ACF, che resta eccellente, ha una community enorme e un ecosistema di integrazioni con page builder e plugin terzi che Metabox, più giovane, non ha ancora del tutto raggiunto. Se il tuo stack si appoggia già ad ACF in tre punti diversi, non lo cambierei. Ma partendo da zero, l’approccio configuration-first di Metabox si sposa meglio con il modo in cui lavoro io.

Metabox restituisce a chi scrive il controllo che il codice da solo non dà

La differenza principale, rispetto a scrivere ogni meta box a mano, è che Metabox restituisce a chi scrive un’interfaccia vera. Testo, numero, immagine, galleria, select, campo di relazione tra contenuti diversi, gruppo di campi ripetibile, sono tutti gestiti da un pannello che compare nell’editor senza che nessuno debba toccare codice per usarlo.

Il campo gruppo è quello che uso più spesso e che il codice a mano rende più fastidioso da replicare: per un progetto con più “specifiche tecniche” o più “componenti inclusi”, invece di limitarmi a un campo testo unico dove il cliente scrive tutto su una riga, gli do un blocco che può ripetere quante volte serve, ognuno con il suo nome e la sua descrizione. Con la logica condizionale, poi, un campo può comparire solo se un altro è impostato in un certo modo.

Semplicemente chi cura i contenuti apre il progetto, vede i campi con le loro etichette, li compila, salva.

Un box Metabox si configura in codice

La parte che per me fa la differenza è come si configura.

Metabox offre un builder visuale, comodo per chi lavora su un solo sito o preferisce vedere subito il risultato, ma sui progetti che replico su più siti registro i meta box via codice, con il filtro rwmb_meta_boxes:

php

add_filter('rwmb_meta_boxes', function ($meta_boxes) {
    $meta_boxes[] = [
        'title' => 'Dettagli progetto',
        'post_types' => ['progetto'],
        'fields' => [
            [
                'name' => 'Cliente',
                'id' => 'progetto_cliente',
                'type' => 'text',
            ],
            [
                'name' => 'Anno',
                'id' => 'progetto_anno',
                'type' => 'number',
            ],
            [
                'name' => 'Galleria',
                'id' => 'progetto_galleria',
                'type' => 'image_advanced',
            ],
        ],
    ];
    return $meta_boxes;
});

Quando il pattern “progetto con cliente, anno e galleria” si ripete su un altro sito, copio il blocco, cambio quello che serve, faccio il commit. Su decine di siti con strutture ricorrenti, questa differenza tra ricostruire a click e riusare codice è un vantaggio ENORME.

Il resto, dal recupero dei valori in template con rwmb_meta() alla gestione delle relazioni tra post type diversi con l’estensione MB Relationships, segue la stessa logica, creando una struttura scritta una volta e riusata potenzialmente all’infinito.

Chiaro che non è la soluzione universale. Per un sito con due campi custom, register_post_type() da solo resta la scelta più diretta, e complicare le cose con un plugin in più non porterebbe nessun vantaggio reale. Ma appena i campi diventano più di tre o quattro, o appena chi scrive i contenuti deve poterli gestire da solo, il salto di qualità si sente.

Se anche tu lavori con Metabox, o hai fatto una scelta diversa per gestire i campi custom, mi interessa sapere come te la sei cavata!