add_theme_support('post-thumbnails') sans argument active les images mises en avant sur tous les types de contenu publics d’un coup : articles, pages, et tout type personnalisé enregistré avec 'public' => true. C’est rarement le comportement recherché quand un seul type de contenu, par exemple un annuaire de prestataires, doit réellement en bénéficier.
Le problème d’une activation trop large
Activer la fonctionnalité sans restriction, puis masquer la métabox correspondante sur les types de contenu non concernés via un filtre, fonctionne mais reste une solution détournée : la fonctionnalité reste techniquement active partout, avec un simple habillage visuel qui la cache. Un client qui modifie un article via l’API REST ou un import en masse peut malgré tout définir une image mise en avant sur un type de contenu où elle n’a aucun usage prévu par le thème.
La bonne approche : un tableau en second argument
add_theme_support() accepte, pour cette fonctionnalité précise, un tableau de noms de types de contenu en second argument, ce qui restreint réellement l’activation aux seuls types listés.
function monthème_setup() {
add_theme_support( 'post-thumbnails', array( 'prestataire' ) );
}
add_action( 'after_setup_theme', 'monthème_setup' );
Avec cette déclaration, la métabox « Image mise en avant » n’apparaît que sur l’écran d’édition du type de contenu prestataire. Les articles, les pages et tout autre type personnalisé ne proposent tout simplement plus cette option, ce qui simplifie l’interface pour les personnes qui gèrent le contenu au quotidien.
Déclarer le type de contenu correspondant
Ce réglage n’a de sens qu’accompagné d’un type de contenu personnalisé correctement enregistré, avec le support explicite de la vignette dans sa propre déclaration également.
function monthème_type_prestataire() {
register_post_type( 'prestataire', array(
'label' => 'Prestataires',
'public' => true,
'show_in_rest' => true,
'supports' => array( 'title', 'editor', 'thumbnail' ),
'menu_icon' => 'dashicons-groups',
) );
}
add_action( 'init', 'monthème_type_prestataire' );
Le mot-clé thumbnail dans l’argument supports du type de contenu et la déclaration via add_theme_support('post-thumbnails', array(...)) agissent ensemble : le premier autorise le type de contenu à porter une image mise en avant, le second restreint globalement cette fonctionnalité au niveau du thème pour éviter qu’elle n’apparaisse ailleurs.
Afficher la vignette uniquement là où elle est pertinente
- Utiliser
has_post_thumbnail()avant tout affichage, même sur le type de contenu concerné, au cas où l’image n’a pas été renseignée. - Choisir une taille d’image dédiée avec
add_image_size()plutôt que la taille par défaut, pour un rendu cohérent sur la grille d’archive. - Ne pas dupliquer la condition sur d’autres types de contenu : la restriction faite en amont rend cette vérification déjà inutile ailleurs.
<?php if ( has_post_thumbnail() ) : ?>
<?php the_post_thumbnail( 'fiche-prestataire' ); ?>
<?php endif; ?>
Vérifier le résultat au bon endroit
La vérification la plus fiable ne se fait pas au rendu final, mais directement dans l’éditeur : ouvrir un article classique et confirmer que la métabox n’apparaît plus, puis ouvrir une fiche du type de contenu concerné et confirmer sa présence. Une erreur fréquente consiste à ne tester que le type de contenu concerné, sans vérifier que les autres en sont bien exclus.
Un contrôle qui prend moins d’une minute mais évite bien des surprises : ouvrir un brouillon d’article standard juste après cette modification, pour confirmer que la métabox a bien disparu comme prévu.
En résumé
Restreindre post-thumbnails à un type de contenu précis, via son second argument sous forme de tableau, offre un contrôle plus propre et plus fiable qu’une activation globale suivie d’un masquage visuel. Une déclaration correctement ciblée simplifie l’interface d’édition sans laisser subsister de fonctionnalité techniquement active là où elle n’a pas lieu d’être.
