post_type_exists et taxonomy_exists : vérifier avant d’agir plutôt que d’échouer

Une extension qui enregistre un type de contenu personnalisé — des annonces immobilières, des recettes de cuisine, des offres d’emploi — peut être désactivée à tout moment par un administrateur, sans que le développeur d’une seconde extension qui en dépend en soit informé. Si cette seconde extension continue d’interroger ce type de contenu sans vérification, les requêtes ne remontent simplement plus rien, ou pire, génèrent des avertissements PHP sur des objets absents.

Deux fonctions natives permettent d’anticiper ce cas plutôt que de le découvrir en production : post_type_exists() et taxonomy_exists().

Ce que vérifient exactement ces deux fonctions

post_type_exists( string $post_type ) retourne un booléen indiquant si le type de contenu donné a bien été enregistré via register_post_type() au moment de l’appel. taxonomy_exists( string $taxonomy ) fait de même pour une taxonomie enregistrée via register_taxonomy(). Les deux s’appuient sur les registres internes du cœur plutôt que sur une requête en base de données, ce qui les rend rapides à utiliser même dans un chemin de code appelé souvent.

Un point à garder en tête : ces fonctions ne renseignent que sur l’état courant, au moment précis où elles sont appelées. Un type de contenu enregistré tardivement sur le hook init avec une priorité différente peut ne pas encore exister si la vérification intervient trop tôt dans le cycle de chargement.

Checklist pour une extension dépendante d’un type tiers

1. Ne jamais supposer qu’un type de contenu tiers existe : vérifier avec post_type_exists() avant toute requête ou tout affichage qui en dépend.
2. Placer cette vérification après le hook init, une fois que toutes les extensions ont eu l’occasion d’enregistrer leurs propres types de contenu.
3. Prévoir un message clair côté administration si la dépendance est absente, plutôt qu’un écran vide sans explication.
4. Faire de même pour toute taxonomie associée avec taxonomy_exists(), en particulier avant d’appeler get_terms() ou wp_set_object_terms().
5. Documenter cette dépendance dans le fichier principal de l’extension, pour qu’un futur mainteneur comprenne immédiatement pourquoi la vérification est là.

Un exemple concret : un widget d’annonces

Une extension qui affiche un widget listant les dernières annonces d’un type de contenu annonce_partenaire, enregistré par une extension partenaire distincte, peut échouer proprement ainsi :

function widget_afficher_dernieres_annonces() {
    if ( ! post_type_exists( 'annonce_partenaire' ) ) {
        return sprintf(
            '<p>%s</p>',
            esc_html__( 'Le module Annonces partenaires est requis pour ce widget.', 'widgets-vitrine' )
        );
    }

    $annonces = get_posts( array(
        'post_type'      => 'annonce_partenaire',
        'posts_per_page' => 5,
    ) );

    // Affichage des annonces récupérées…
}

Sans cette vérification, get_posts() avec un type de contenu inexistant ne provoque pas d’erreur fatale — WordPress retourne simplement un tableau vide — mais l’origine du problème reste invisible pour la personne qui gère le site, qui verra juste un widget vide sans comprendre pourquoi.

Le cas des taxonomies liées

Quand une extension dépend à la fois d’un type de contenu et d’une taxonomie associée — par exemple une catégorie de recettes liée à un type recette — il est utile de vérifier les deux séparément, car l’un peut exister sans l’autre selon l’ordre de désactivation des extensions :

if ( post_type_exists( 'recette' ) && taxonomy_exists( 'categorie_recette' ) ) {
    // Le module Recettes est complet, on peut construire la requête.
}

Ce que ces fonctions ne remplacent pas

• Elles ne vérifient pas les capacités de l’utilisateur courant sur ce type de contenu : cela reste le rôle de current_user_can().
• Elles ne garantissent pas qu’il existe des contenus publiés de ce type, seulement que le type lui-même est enregistré.
• Elles ne remplacent pas une vérification de version ou de présence de l’extension partenaire elle-même, utile si le message d’erreur doit être plus précis qu’un simple type de contenu absent.

En résumé

Dépendre d’un type de contenu ou d’une taxonomie enregistrés par une autre extension crée un couplage qui peut se rompre à tout moment, sans avertissement. post_type_exists() et taxonomy_exists() permettent de transformer un plantage silencieux en message clair pour la personne qui administre le site, avec un coût de mise en œuvre minimal : quelques lignes de vérification avant chaque point d’entrée qui dépend de cette relation externe.