Que faire lorsque l'utilisateur ne peut pas accéder au contenu ?

Si vous constatez que vos utilisateurs signalent qu'ils n'ont pas accès à votre contenu protégé alors qu'ils pensent qu'ils devraient y avoir accès, il y a plusieurs choses que vous pouvez vérifier. 

Avant de passer en revue les listes ci-dessous, nous à recommander vivement en utilisant le Plugin de changement d'utilisateur pour vérifier l'accès de vos utilisateurs. Il s'agit d'une manière transparente de vérifier à quoi l'utilisateur a exactement accès sans lui demander son mot de passe. 

Après avoir vérifié que l'utilisateur ne peut effectivement pas accéder au contenu qu'il devrait, voici deux listes d'éléments à vérifier :

Principaux éléments à vérifier - ce que vous devriez pouvoir faire facilement par vous-même

• Vérifiez que l'utilisateur a un abonnement actif. Cela doit être vérifié sur la page MemberPress > Abonnements et sous la colonne active, vous verrez un "Oui" vert. 
• Vérifiez que vous avez correctement configuré votre règle pour le contenu mentionné. Vous devez vous assurer que sur la page d'édition de votre règle, vous avez correctement sélectionné l'adhésion que l'utilisateur a achetée (ainsi que toutes les autres adhésions).
• Vérifiez que la règle protégeant le contenu n'est pas assortie d'un délai d'attente ou d'un délai d'expiration. Si l'utilisateur se trouve en dehors de ces fenêtres, il n'aura pas accès au contenu.
• Vérifier les conflits de règles comme expliqué ici - c'est-à-dire deux règles protégeant le même élément de contenu. Le plus souvent, une règle de type "tout le contenu", "toutes les pages", "tous les messages", etc. peut provoquer un tel conflit. 
• Si vous n'avez pas de règles, essayez d'en ajouter une, vous pourrez toujours la supprimer par la suite si le problème est résolu. Pour en savoir plus, voir : Pourquoi toutes mes pages sont-elles verrouillées si je n'ai pas de règles ?

Éléments secondaires à vérifier - peut nécessiter l'aide de votre hébergeur ou développeur

• En-têtes de mise en cache du navigateur HTTP. L'utilisateur visite une page protégée et un plugin de mise en cache indique au navigateur de mettre cette page en cache (si l'utilisateur la visite à l'avenir, il verra la même chose que ce qu'il voit maintenant). L'utilisateur se connecte ou s'enregistre, retourne sur la page protégée et le navigateur lui montre la version mise en cache de la page au lieu de chercher une nouvelle version maintenant qu'il est connecté. Ce problème peut généralement être résolu en désactivant la mise en cache complète du navigateur dans la configuration de votre plugin de mise en cache. Seuls les éléments statiques tels que CSS, JS, images, polices de caractères, etc. doivent être mis en cache par le navigateur. 
• www vs non-www. Les cookies de connexion de WordPress sont valables sous www ou non-www - mais pas pour les deux. Ainsi, si l'utilisateur se connecte sous une URL www, puis navigue vers une page qui n'est pas www, il sera considéré par WordPress comme déconnecté. La mise en place d'une redirection .htaccess pour forcer l'un ou l'autre corrige généralement ce problème.
• http vs https - similaire au point précédent, sauf que les cookies de connexion ne sont valables que sous http ou https. mais pas les deux. Si l'utilisateur se connecte sous https, puis navigue vers une URL http, il sera à nouveau considéré comme déconnecté. Si vous disposez d'un certificat SSL/TLS (https) sur votre site, il est recommandé de passer en https intégral sur l'ensemble du site. Le site Plugin SSL vraiment simple est idéal pour cela. Veillez cependant à mettre à jour vos URL Webhook ou IPN pour utiliser https au niveau de la passerelle, si elles sont actuellement configurées pour utiliser http.