Le WordPress d'aujourd'hui, décodé pour les développeurs

Astuces

Distinguer un badge « invité d’honneur » réservé aux événements confirmés

Annoncer un intervenant avant confirmation finale expose à un badge affiché à tort. Un statut d'événement validé conditionne désormais l'affichage du badge « invité d'honneur » sur la fiche.

Par WordPress Développement • 16 mai 2022 • 5 min de lecture • Aucun commentaire
Distinguer un badge « invité d'honneur » réservé aux événements confirmés

Quelle différence entre un intervenant « pressenti » et un intervenant « confirmé » sur la fiche d’un événement professionnel ? Pour un organisateur de conférences B2B dans le secteur de la logistique, cette nuance avait un coût réel : un badge « invité d’honneur » s’affichait automatiquement dès qu’un nom était renseigné dans le champ correspondant, sans distinction entre une intervention simplement annoncée et une intervention réellement validée par contrat.

Un intervenant annoncé trop tôt s’était finalement désisté, laissant le badge affiché plusieurs semaines sur une fiche devenue inexacte. La correction ne portait pas sur le champ de nom lui-même, mais sur l’ajout d’un statut d’événement distinct, qui conditionne désormais strictement l’affichage du badge.

Deux statuts, deux vérités différentes

Le champ personnalisé statut_intervenant_honneur prend deux valeurs possibles : annonce et confirme. Seule la seconde valeur déclenche l’affichage du badge, tandis que la première continue d’afficher le nom de l’intervenant sans mention particulière.

function ch_render_metabox_invite_honneur( $post ) {
    $statut = get_post_meta( $post->ID, 'statut_intervenant_honneur', true ) ?: 'annonce';
    ?>
    <p>
        <label>
            <input type="radio" name="statut_intervenant_honneur" value="annonce" <?php checked( $statut, 'annonce' ); ?> />
            Intervention annoncée, non confirmée
        </label><br />
        <label>
            <input type="radio" name="statut_intervenant_honneur" value="confirme" <?php checked( $statut, 'confirme' ); ?> />
            Intervention confirmée par contrat
        </label>
    </p>
    <?php
}
L'essentiel à retenir : Le badge dépend du statut de l'événement, pas de la fiche de l'intervenant ; Deux statuts distincts : annoncé et confirmé ; Un seul filtre d'affichage à modifier pour toute correction

Afficher le badge uniquement sur confirmation

Le gabarit de fiche événement reste simple : un seul conditionnel autour du badge, aucune duplication de logique ailleurs sur le site puisque toutes les fiches passent par le même fichier single-evenement.php.

<?php
$statut = get_post_meta( get_the_ID(), 'statut_intervenant_honneur', true );

if ( 'confirme' === $statut ) :
    ?>
    <span class="badge-invite-honneur">Invité d'honneur confirmé</span>
    <?php
endif;
?>

Ce choix a une conséquence directe et souhaitée : si un intervenant se désiste après confirmation, il suffit de repasser le statut à annonce — ou de retirer le champ s’il quitte totalement la fiche — pour que le badge disparaisse instantanément, sans intervention sur le gabarit lui-même.

Historiser les changements de statut

L’organisateur souhaitait aussi garder une trace des changements de statut, utile en cas de contestation ou de question d’un partenaire sur la chronologie d’une confirmation. Un simple tableau ajouté en métadonnée, alimenté à chaque changement, répond à ce besoin sans complexité excessive.

add_action( 'save_post_evenement', function ( $post_id ) {
    static $deja_traite = array();
    if ( isset( $deja_traite[ $post_id ] ) ) {
        return;
    }
    $deja_traite[ $post_id ] = true;

    $ancien_statut = get_post_meta( $post_id, 'statut_intervenant_honneur', true );
    $nouveau_statut = sanitize_text_field( $_POST['statut_intervenant_honneur'] ?? '' );

    if ( $nouveau_statut && $nouveau_statut !== $ancien_statut ) {
        $historique = get_post_meta( $post_id, 'historique_statut_honneur', true ) ?: array();
        $historique[] = array( 'statut' => $nouveau_statut, 'date' => current_time( 'mysql' ) );
        update_post_meta( $post_id, 'historique_statut_honneur', $historique );
    }
} );

Pourquoi ne pas simplement retirer le nom en cas de désistement

Une question revient souvent avec ce genre de dispositif : pourquoi ne pas simplement effacer le nom de l’intervenant en cas de désistement, plutôt que de gérer un statut séparé ? La réponse tient à la communication de l’organisateur, qui préfère souvent conserver une mention neutre (« intervention en cours de reprogrammation ») plutôt qu’une disparition silencieuse, plus difficile à justifier auprès des partenaires ayant déjà relayé l’annonce initiale.

  • Le statut annonce peut afficher une mention discrète « sous réserve de confirmation », utile pour gérer les attentes du public sans induire en erreur.
  • Le passage à confirme peut déclencher automatiquement une notification à l’équipe communication, via une action personnalisée dédiée, séparée de l’affichage du badge lui-même.
  • Un statut supplémentaire desiste peut être ajouté ultérieurement si le besoin s’en fait sentir, sans remettre en cause la structure déjà en place.

Un badge affiché par erreur coûte souvent plus cher en crédibilité que l’absence totale de badge : mieux vaut un statut explicite qu’une présomption de confirmation.

Ce mécanisme ne traite volontairement pas la gestion des cachets des intervenants, qui relève d’un processus contractuel et comptable distinct, suivi séparément par l’organisateur en dehors du site.

Pour aller plus loin

Le même principe de statut explicite, plutôt que de présomption fondée sur le simple remplissage d’un champ, s’applique à bien d’autres badges d’un site événementiel : partenaire officiel, sponsor confirmé, atelier complet. Dans chaque cas, séparer la donnée de contexte (le nom, le titre) du statut qui déclenche l’affichage évite les badges qui mentent par excès de confiance dans un champ rempli trop tôt.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi