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

> Une extension tierce désactivée du jour au lendemain, et c'est toute une intégration qui plante en silence. Deux fonctions natives permettent d'échouer proprement.

- Auteur : Clément Hadrot
- Publié le : 2025-02-20
- Mis à jour le : 2025-02-20
- Catégorie : Astuces
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tips/post-type-exists-taxonomy-exists-verifier-avant-agir/

## L’essentiel

- Vérifie l'existence avant toute requête
- Évite des erreurs PHP sur un type de contenu absent
- Fonctions natives, aucune dépendance à ajouter

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

> L'essentiel à retenir : Vérifie l'existence avant toute requête ; Évite des erreurs PHP sur un type de contenu absent ; Fonctions natives, aucune dépendance à ajouter

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.