# Verrouiller la suppression d’un praticien avec un rendez-vous futur rattaché

> Sur un annuaire de cabinet médical, supprimer une fiche praticien ne devrait jamais laisser un patient face à un rendez-vous fantôme.

- Auteur : WordPress Développement
- Publié le : 2022-08-07
- Mis à jour le : 2022-08-07
- Catégorie : Astuces
- URL : https://www.wpmoderne.fr/tips/verrouiller-suppression-praticien-rendez-vous-futur-rattache/

## L’essentiel

- Vérifier les rendez-vous liés avant toute suppression
- Bloquer via before_delete_post et un message clair
- Proposer une réaffectation plutôt qu'un blocage sec

Un CPT `praticien` relié à un CPT `rendez_vous` par un champ meta `_praticien_id` : c'est la structure la plus courante pour gérer un cabinet pluridisciplinaire dans WordPress. Elle fonctionne très bien tant que personne ne supprime une fiche praticien qui a encore des rendez-vous à venir. Le jour où cela arrive, la fiche disparaît, mais les rendez-vous restent en base, pointant vers un `post_id` qui n'existe plus.

Ce genre d'incident est rarement provoqué par malveillance. C'est un remplaçant qui part, un stagiaire qui fait le ménage dans la liste des utilisateurs, un import mal filtré. Le résultat est le même : un patient reçoit un rappel de rendez-vous pour un praticien qui n'apparaît plus nulle part sur le site, et le secrétariat découvre le problème au téléphone, en direct.

## Ce qu'on voit en pratique

Sur la plupart des installations, la suppression d'un praticien passe par l'écran standard de gestion des contenus, sans aucune vérification préalable. WordPress exécute la suppression, déclenche le hook `before_delete_post`, puis `deleted_post`, sans jamais se soucier des entités qui référencent ce praticien ailleurs dans la base. Rien dans le cœur ne relie automatiquement un CPT à un autre par une clé étrangère au sens SQL du terme : c'est entièrement à la charge du développeur.

Quand la vérification manque, trois symptômes reviennent systématiquement : des rendez-vous affichés avec un nom de praticien vide dans le back-office, des notifications automatiques encore envoyées pour un rendez-vous devenu incohérent, et une réconciliation manuelle fastidieuse pour retrouver qui aurait dû être notifié du changement.

## Pourquoi c'est un problème

Dans un cabinet médical, un rendez-vous orphelin n'est pas qu'un défaut d'affichage : c'est un patient qui se déplace pour rien, ou à l'inverse un praticien remplaçant qui n'est jamais informé qu'un créneau lui était en réalité destiné. La confiance dans l'outil de planification s'érode vite dès qu'un secrétariat découvre ce genre d'incohérence, et le réflexe naturel devient de tout vérifier à la main avant chaque suppression, ce qui annule tout le bénéfice de l'automatisation.

> L'essentiel à retenir : Vérifier les rendez-vous liés avant toute suppression ; Bloquer via before_delete_post et un message clair ; Proposer une réaffectation plutôt qu'un blocage sec

## Quoi faire

La correction tient dans un hook, à condition de l'attacher au bon endroit. `before_delete_post` s'exécute avant la suppression effective et accepte de bloquer l'opération en levant une exception filtrée par WordPress via `wp_die()` dans le contexte admin, ou plus proprement en interceptant la capacité de suppression avec `map_meta_cap`.

```
add_filter( 'user_has_cap', function( $allcaps, $caps, $args ) {
    if ( empty( $args[0] ) || 'delete_post' !== $args[0] ) {
        return $allcaps;
    }

    $post_id = $args[2] ?? 0;
    if ( 'praticien' !== get_post_type( $post_id ) ) {
        return $allcaps;
    }

    $rdv_futurs = get_posts( array(
        'post_type'   => 'rendez_vous',
        'meta_key'    => '_praticien_id',
        'meta_value'  => $post_id,
        'meta_compare'=> '=',
        'date_query'  => array(
            array( 'column' => 'meta_value', 'after' => 'now', 'inclusive' => true ),
        ),
        'fields'      => 'ids',
        'numberposts' => 1,
    ) );

    if ( ! empty( $rdv_futurs ) ) {
        foreach ( $caps as $cap ) {
            $allcaps[ $cap ] = false;
        }
    }

    return $allcaps;
}, 10, 3 );
```

Ce filtre neutralise la capacité de suppression pour ce praticien précis dès qu'un rendez-vous futur lui est rattaché, quel que soit l'écran par lequel passe l'administrateur : liste des contenus, action groupée, ou même une suppression déclenchée par une requête REST. C'est ce dernier point qui compte le plus : bloquer uniquement le bouton dans l'interface ne protège rien contre un script ou une extension tierce qui appelle `wp_delete_post()` directement.

### Afficher un message utile plutôt qu'un blocage muet

Un blocage silencieux frustre plus qu'il ne protège. Sur l'écran d'édition du praticien, un message contextuel via `admin_notices` doit expliquer pourquoi la suppression est refusée et, idéalement, lister les rendez-vous concernés avec un lien direct vers chacun. Le secrétariat peut alors décider en connaissance de cause : annuler les rendez-vous, les réaffecter à un confrère, ou attendre qu'ils passent.

- Lister les rendez-vous bloquants avec date et patient dans la notice admin
- Proposer un lien direct « réaffecter à » pointant vers l'outil de duplication de planning
- Ne jamais transformer ce garde-fou en blocage permanent : une fois les rendez-vous traités, la suppression doit redevenir possible sans intervention développeur

> Un garde-fou qui n'explique rien finit systématiquement contourné à coups de suppression forcée en base ; mieux vaut un message clair qu'une protection qu'on désactive par lassitude.

## En résumé

Le cœur de WordPress ne connaît pas la relation métier entre un praticien et ses rendez-vous : il faut la matérialiser explicitement, et la faire respecter au niveau des capacités plutôt qu'au niveau de l'affichage. Un filtre sur `user_has_cap`, une requête `date_query` bien ciblée sur les rendez-vous à venir, et une notice qui explique la situation suffisent à éliminer ce type d'incident sans complexifier l'interface pour l'équipe administrative.