# Masquer les tarifs pour un visiteur déjà identifié comme abonné, sur un média

> Adapter l'affichage du contenu promotionnel selon le statut d'abonnement du visiteur déjà connu, sans construire un mur payant complet côté serveur.

- Auteur : WordPress Développement
- Publié le : 2021-02-23
- Mis à jour le : 2021-02-23
- Catégorie : Astuces
- URL : https://www.wpmoderne.fr/tips/masquer-tarifs-visiteur-abonne-identifie/

## L’essentiel

- Détection du statut sans compte utilisateur WordPress
- Cookie posé par le prestataire d'abonnement externe
- Bascule d'affichage purement front-end

`is_subscriber()` : cette fonction n'existe dans aucun cœur WordPress, et c'est précisément le nœud du problème posé par un média en ligne qui gère ses abonnements via une plateforme tierce, complètement détachée du système de comptes WordPress. La demande de la rédaction restait simple en apparence : qu'un lecteur déjà abonné ne voie plus les encarts « Abonnez-vous pour 4,90 € par mois » sur chaque article, sans pour autant construire un mur payant complet qui bloquerait l'accès au contenu.

La plateforme d'abonnement externe posait déjà un cookie de session côté navigateur une fois le paiement validé. Il ne restait qu'à le lire côté WordPress pour basculer l'affichage — une intégration légère, sans synchronisation de base de données ni création de comptes utilisateurs supplémentaires.

## Le problème : un statut d'abonnement hors de portée de WordPress

Le prestataire de paiement récurrent utilisé n'exposait qu'un webhook de notification d'abonnement et un cookie de session nommé `sub_status`, valorisé à `active` une fois l'abonnement confirmé. Aucune API accessible sans authentification côté serveur, aucun moyen simple de vérifier le statut à la génération de la page en PHP sans appel réseau supplémentaire — ce qui aurait ralenti chaque affichage d'article.

La seule information fiable et immédiatement disponible restait donc ce cookie, lisible côté client en JavaScript.

## Le snippet : bascule d'affichage côté front

Plutôt que de conditionner l'affichage côté PHP, l'encart promotionnel est toujours généré dans le HTML, mais masqué par défaut via une classe CSS, puis révélé ou non selon la lecture du cookie :

> L'essentiel à retenir : Détection du statut sans compte utilisateur WordPress ; Cookie posé par le prestataire d'abonnement externe ; Bascule d'affichage purement front-end

```
function wpm_encart_abonnement( $content ) {
    if ( ! is_singular( 'post' ) ) {
        return $content;
    }

    $encart = '<div class="wpm-encart-abo" style="display:none">'
        . '<p><strong>Abonnez-vous</strong> pour lire nos articles sans limite.</p>'
        . '</div>';

    return $content . $encart;
}
add_filter( 'the_content', 'wpm_encart_abonnement' );
```

```
document.addEventListener('DOMContentLoaded', function () {
    var estAbonne = document.cookie.indexOf('sub_status=active') !== -1;
    var encart = document.querySelector('.wpm-encart-abo');

    if (encart && !estAbonne) {
        encart.style.display = 'block';
    }
});
```

L'encart est présent dans le DOM pour tout le monde — ce qui évite un décalage de mise en page au chargement — mais reste invisible pour les visiteurs déjà reconnus comme abonnés. Le rendu HTML brut, avant exécution du JavaScript, contient toujours la mention : un visiteur qui désactive JavaScript verra l'encart, ce qui reste un comportement par défaut acceptable plutôt qu'une fuite d'information sensible.

## Pourquoi pas côté serveur

Lire le cookie directement en PHP via `$_COOKIE['sub_status']` aurait été plus robuste en apparence, mais brise le cache de page côté serveur : chaque article devient alors non-cachable, ou nécessite un cache fragmenté, ce qui dépassait largement le budget du projet. La bascule côté client permet de conserver un cache de page complet, y compris pour les visiteurs abonnés — seul un petit fragment d'affichage change après coup, sans re-génération serveur.

- Cache de page conservé à l'identique pour tous les visiteurs
- Bascule visuelle après chargement, sans appel réseau supplémentaire
- Aucune donnée sensible transmise au serveur pour cette vérification

## Variantes possibles

Si le cookie du prestataire n'est pas directement exploitable (durée de vie trop courte, domaine différent), une variante consiste à faire poser un cookie WordPress dédié via le webhook de confirmation d'abonnement, avec une durée de validité alignée sur celle de l'abonnement lui-même :

- Webhook du prestataire déclenchant l'écriture d'un cookie côté serveur
- Cookie signé pour éviter qu'un visiteur ne le falsifie lui-même dans son navigateur
- Durée de vie recalculée à chaque renouvellement d'abonnement

Cette variante ajoute une dépendance à un point d'entrée serveur supplémentaire, mais retire toute confiance aveugle envers un cookie tiers dont on ne maîtrise ni le format ni la pérennité.

## En résumé

Masquer un encart promotionnel pour un abonné déjà identifié ne demande ni compte utilisateur WordPress ni mur payant complet : un cookie fiable, une bascule d'affichage côté client, et un encart toujours présent dans le HTML pour préserver le cache. Le vrai mur payant, avec restriction d'accès au contenu lui-même, reste un chantier bien plus lourd, à ne déclencher que si le modèle économique l'exige vraiment.