Custom post type e tassonomie WordPress: strutturare i contenuti come un architetto
I custom post type sono il modo più potente di estendere WordPress oltre blog e pagine. Come crearli correttamente, quando usare una tassonomia personalizzata invece di una categoria, e perché register_post_type nel posto sbagliato è il bug più comune che rallenta l'admin.
I custom post type sono la caratteristica che trasforma WordPress da un blog a un CMS vero. Un sito di servizi con un custom post type 'case studies' strutturato bene è infinitamente più gestibile di un sito dove i case studies sono pagine con una categoria. Un e-commerce dove i prodotti sono un CPT con tassonomie personalizzate (marca, categoria, tag tecnici) è più performante di uno dove tutto è appiattito su post e pagine. La differenza non è estetica — è architettura dell'informazione.
Il problema è che la maggior parte dei custom post type che vediamo in produzione sono registrati male. Il hook sbagliato, i capability non dichiarate, i rewrite slug non configurati, i supporti mancanti. Il risultato è un admin lento, URL brutti, e una struttura che non scala. La registrazione corretta richiede attenzione ai dettagli — e i dettagli sono quelli che nessuno controlla.
Registrare un custom post type correttamente
La registrazione avviene con register_post_type nell'hook init. L'errore più comune è usare l'hook sbagliato (init va bene, ma alcuni lo mettono in admin_init, che non registra il CPT per le richieste del frontend). L'altro errore è non dichiarare le capability, che rende il CPT invisibile agli utenti non-admin:
add_action( 'init', 'wpplanet_register_case_studies' );
function wpplanet_register_case_studies() {
$labels = array(
'name' => 'Case Studies',
'singular_name' => 'Case Study',
'add_new' => 'Aggiungi nuovo',
'add_new_item' => 'Aggiungi nuovo case study',
'edit_item' => 'Modifica case study',
'new_item' => 'Nuovo case study',
'view_item' => 'Visualizza case study',
'search_items' => 'Cerca case studies',
'not_found' => 'Nessun case study trovato',
'not_found_in_trash' => 'Nessun case study nel cestino',
'menu_name' => 'Case Studies',
);
$args = array(
'labels' => $labels,
'public' => true,
'has_archive' => true,
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'show_in_rest' => true, // abilita Gutenberg + REST API
'menu_position' => 20,
'menu_icon' => 'dashicons-portfolio',
'supports' => array(
'title', 'editor', 'thumbnail', 'excerpt',
'custom-fields', 'revisions', 'page-attributes',
),
'taxonomies' => array( 'settore', 'cliente' ),
'rewrite' => array(
'slug' => 'case-studies',
'with_front' => false,
),
'capability_type' => 'case_study',
'map_meta_cap' => true,
);
register_post_type( 'case_study', $args );
}Tassonomie personalizzate: quando usarle
Le tassonomie personalizzate sono il modo corretto di organizzare i contenuti quando le categorie e i tag nativi non bastano. Un case study ha bisogno di 'settore' (gerarchica come le categorie) e 'tecnologia' (piatta come i tag). Usare le categorie nativi per questo confonde la struttura — le categorie sono per i blog post, non per i case studies. La registrazione:
// Tassonomia gerarchica (come le categorie)
add_action( 'init', function() {
register_taxonomy( 'settore', 'case_study', array(
'labels' => array(
'name' => 'Settori',
'singular_name' => 'Settore',
'search_items' => 'Cerca settori',
'edit_item' => 'Modifica settore',
'add_new_item' => 'Aggiungi nuovo settore',
),
'hierarchical' => true, // come le categorie
'show_admin_column' => true,
'show_in_rest' => true,
'rewrite' => array( 'slug' => 'settore' ),
) );
} );
// Tassonomia piatta (come i tag)
add_action( 'init', function() {
register_taxonomy( 'tecnologia', 'case_study', array(
'labels' => array(
'name' => 'Tecnologie',
'singular_name' => 'Tecnologia',
'add_new_item' => 'Aggiungi tecnologia',
),
'hierarchical' => false, // come i tag
'show_admin_column' => true,
'show_in_rest' => true,
'rewrite' => array( 'slug' => 'tecnologia' ),
) );
} );Il flush dei rewrite: il bug più comune
Quando registri un CPT o una tassonomia nuova, le regole di rewrite di WordPress vanno rigenerate. Se non lo fai, i permalink del CPT restituiscono 404. Il modo corretto è flush_rewrite_rules una sola volta dopo la registrazione — mai a ogni page load:
// Flush dei rewrite SOLO all'attivazione del tema/plugin
// MAI in init a ogni page load — rallenta il sito
add_action( 'after_switch_theme', 'wpplanet_flush_rewrites' );
register_activation_hook( __FILE__, 'wpplanet_flush_rewrites' );
function wpplanet_flush_rewrites() {
wpplanet_register_case_studies();
flush_rewrite_rules();
}
// Alternativa: flush manuale via WP-CLI
// wp rewrite flush
// o dalla admin: Impostazioni → Permalink → SalvaQuando NON usare un custom post type
Non tutto è un CPT. Se hai tre o quattro contenuti di un tipo, un CPT è sovrainvestimento — usa le pagine. Un CPT ha senso quando hai decine o centinaia di contenuti dello stesso tipo che richiedono una struttura dedicata. Se hai tre case studies, usa le pagine con un template. Se ne hai trenta, usa un CPT con tassonomie. La soglia è empirica — ma sotto i dieci contenuti di un tipo, un CPT aggiunge complessità senza valore.
I custom post type sono architettura dell'informazione. Usati bene, trasformano WordPress in un CMS su misura. Usati male, creano un admin confuso, URL brutti, e una struttura che nessuno capisce. La differenza tra i due esiti non è il plugin o il tema — è la cura con cui registri il CPT, dichiari le tassonomie, e configuri i rewrite. Dettagli, non grandi scelte.
Codice pulito, prestazioni e dipendenze ridotte al minimo.
Sviluppo WordPress personalizzato: temi leggeri, plugin su misura e integrazioni API senza appesantire il sito.
Articoli correlati
Ricerca interna WordPress e linking strategico: far trovare i contenuti che Google non indicizza
Leggi
Child theme WordPress: perché modificare il tema padre è l'errore più costoso
Leggi