Qu’est-ce qu’une donnée « vraie » dans une base WordPress ? Un champ personnalisé est_verifie, coché une fois lors de la création d’une fiche praticien, reste vrai indéfiniment dans la base, même si le compte associé change de statut, est suspendu, ou n’a jamais réellement été vérifié par la plateforme médicale qui gérait cet annuaire de professionnels de santé.
C’est exactement ce piège qu’a évité ce projet en refusant d’ajouter un champ personnalisé est_verifie distinct. La vérification d’un praticien, sur cette plateforme, correspond en réalité à l’attribution d’un rôle spécifique, praticien_verifie, créé lors de la validation manuelle du dossier par l’équipe de modération. Le badge affiché sur la fiche publique se contente alors d’interroger ce rôle, jamais un champ séparé.
Pourquoi un champ séparé finit toujours par mentir
Un champ personnalisé de type booléen, une fois coché, ne se met à jour que si quelqu’un pense explicitement à le décocher. Si un compte praticien est suspendu pour manquement, ou si son inscription à l’ordre professionnel expire, rien ne garantit que le champ est_verifie suivra ce changement de statut. Le rôle, en revanche, peut être retiré au même moment que la suspension du compte, dans une seule et même action de modération.
Cette distinction entre donnée déclarative et donnée dérivée d’un état du système est au cœur de nombreux bugs silencieux dans WordPress : un champ qui duplique une information disponible ailleurs devient, tôt ou tard, une source de désynchronisation.
Créer le rôle et vérifier la capacité
Le rôle praticien_verifie hérite des capacités du rôle praticien de base, avec une capacité supplémentaire afficher_badge_verifie, utilisée uniquement pour conditionner l’affichage du badge sur la fiche publique.
add_action( 'init', 'annuaire_creer_role_praticien_verifie' );
function annuaire_creer_role_praticien_verifie() {
if ( get_role( 'praticien_verifie' ) ) {
return;
}
add_role(
'praticien_verifie',
'Praticien vérifié',
array_merge(
get_role( 'praticien' )->capabilities,
array( 'afficher_badge_verifie' => true )
)
);
}
Afficher le badge conditionnellement
Sur la fiche publique du praticien, l’affichage du badge interroge directement la capacité de l’auteur de la fiche, sans jamais lire un champ personnalisé qui pourrait exister par ailleurs pour d’autres raisons.
function annuaire_afficher_badge_verifie( $post_id ) {
$auteur_id = get_post_field( 'post_author', $post_id );
if ( user_can( $auteur_id, 'afficher_badge_verifie' ) ) {
echo '<span class="badge-verifie">Praticien vérifié</span>';
}
}
Ce mécanisme garantit que le badge disparaît automatiquement dès qu’un administrateur repasse le compte au rôle praticien simple, sans nécessiter une seconde action pour décocher un champ devenu obsolète.
Le rôle comme source unique de vérité
Ce principe se généralise : chaque fois qu’une information binaire correspond en réalité à un état attribué par une action d’administration — validation, suspension, promotion — il vaut mieux représenter cet état par un rôle ou une capacité plutôt que par un champ personnalisé parallèle. Le rôle devient alors la source unique de vérité, consultée partout où l’information est nécessaire.
- Un seul point de vérité pour l’état « vérifié », consulté par le badge, mais aussi par les filtres de recherche de l’annuaire.
- La révocation du statut se fait en une seule action de modération, sans risque d’oubli d’un champ annexe.
- Le rôle peut aussi porter des capacités fonctionnelles supplémentaires, comme la publication sans modération préalable.
Où cette approche atteint ses limites
Cette logique suppose que le passage d’un rôle à l’autre reste une action rare, réservée à quelques modérateurs. Si le statut de vérification devait dépendre de multiples critères combinés — diplôme, assurance professionnelle, avis clients — un simple rôle binaire deviendrait insuffisant, et une table dédiée ou une extension de gestion de rôles plus fine serait alors nécessaire, ce qui sort du périmètre traité ici.
En résumé
Avant d’ajouter un champ personnalisé pour représenter un état, il vaut la peine de se demander si cet état ne correspond pas déjà à un rôle ou une capacité existante dans WordPress. Le gain n’est pas seulement technique : c’est aussi la garantie qu’une seule action de modération suffit à faire apparaître ou disparaître un badge, sans jamais laisser un champ dire une chose que la réalité du compte a depuis longtemps démentie.
