Une taxonomie « Auteur invité » existe déjà sur le type de contenu article. Le site accueille maintenant un nouveau type de contenu, etude-de-cas, et la même notion d’auteur invité doit s’y appliquer aussi. Faut-il redéclarer la taxonomie de zéro, avec le risque de dupliquer sa configuration à deux endroits différents du code ?
La réponse tient en une fonction dédiée à exactement ce cas : register_taxonomy_for_object_type(). Elle ne crée rien de nouveau ; elle se contente de relier une taxonomie déjà enregistrée à un type de contenu supplémentaire, sans dupliquer la moindre ligne de configuration.
Pourquoi éviter de redéclarer la taxonomie
Rien n’empêche techniquement d’appeler deux fois register_taxonomy() avec le même identifiant mais des arguments object_type différents à chaque appel. Mais cette approche disperse la configuration de la taxonomie — ses libellés, sa visibilité, ses capacités — en plusieurs endroits du code, avec le risque bien réel qu’une modification future n’en touche qu’un seul, faisant diverger silencieusement le comportement entre les deux points d’enregistrement.
Centraliser la déclaration de la taxonomie à un seul endroit, puis relier les types de contenu au fur et à mesure des besoins, garde le code plus lisible et plus facile à faire évoluer.
Utiliser register_taxonomy_for_object_type()
La fonction accepte deux arguments : l’identifiant de la taxonomie déjà déclarée, et l’identifiant du type de contenu auquel l’attacher. Elle doit être appelée après que les deux éléments existent, généralement sur le hook init, avec une priorité suffisante pour s’exécuter après leurs déclarations respectives :
add_action( 'init', function () {
register_taxonomy( 'auteur_invite', array( 'article' ), array(
'label' => 'Auteur invité',
'public' => true,
'hierarchical' => false,
'show_in_rest' => true,
) );
} );
add_action( 'init', function () {
register_taxonomy_for_object_type( 'auteur_invite', 'etude_de_cas' );
}, 20 );
La priorité 20 sur le second appel garantit que la taxonomie et le type de contenu etude_de_cas sont déjà enregistrés au moment où le lien se crée. Sans cette précaution, la fonction échoue silencieusement : elle renvoie false si l’une des deux entités n’existe pas encore, sans lever d’erreur bloquante.
Vérifier que le lien a bien été créé
La fonction renvoie un booléen, qu’il est utile de vérifier au moins pendant le développement :
$resultat = register_taxonomy_for_object_type( 'auteur_invite', 'etude_de_cas' );
if ( ! $resultat ) {
error_log( "Impossible de relier auteur_invite à etude_de_cas : vérifier l'ordre d'enregistrement." );
}
On peut aussi confirmer le lien après coup en interrogeant get_object_taxonomies( 'etude_de_cas' ), qui renvoie la liste des taxonomies désormais associées au type de contenu.
Retirer un lien devenu inutile
La fonction symétrique, unregister_taxonomy_for_object_type(), permet de retirer un lien précédemment établi sans toucher à la déclaration de la taxonomie elle-même. Ce cas se présente typiquement quand un type de contenu évolue et n’a plus besoin d’une taxonomie qui lui était auparavant rattachée :
add_action( 'init', function () {
unregister_taxonomy_for_object_type( 'auteur_invite', 'etude_de_cas' );
}, 20 );
Une différence à ne pas confondre
register_taxonomy()crée la taxonomie elle-même, avec toute sa configuration (libellés, visibilité, capacités, gestion de l’API REST).- Le paramètre
object_typepassé àregister_taxonomy()définit les types de contenu associés dès la création. register_taxonomy_for_object_type()n’intervient qu’après coup, pour ajouter un type de contenu supplémentaire à une taxonomie déjà existante, sans modifier sa configuration d’origine.
Confondre les deux mène parfois à des déclarations redondantes de la même taxonomie, avec des libellés ou des réglages qui finissent par diverger d’un appel à l’autre au fil des modifications successives du projet.
Centraliser chaque taxonomie dans une seule fonction de déclaration, puis multiplier les appels à
register_taxonomy_for_object_type()pour chaque type de contenu additionnel, rend le code beaucoup plus simple à auditer six mois plus tard.
En résumé
Cette fonction reste discrète dans la documentation, éclipsée par register_taxonomy() elle-même, mais elle règle proprement un besoin fréquent dès qu’un projet grandit et qu’une même notion de classification doit s’appliquer à plusieurs types de contenu. Le réflexe à retenir : une seule déclaration de taxonomie, autant de liens que nécessaire ensuite.
