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 les droits d'accès de votre utilisateur. C'est un moyen très simple 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 dispose d'un abonnement actif. Pour cela, rendez-vous sur la page MemberPress > Abonnements : dans la colonne ‘ Actif ’, vous verrez s'afficher un « Oui » en vert. 
• Vérifiez que vous avez correctement configuré votre règle pour le contenu en question. Vous devez vous assurer que, sur la page de modification de votre règle, vous avez correctement sélectionné l’abonnement que l’utilisateur a souscrit (ainsi que tout autre abonnement).
• 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 contenu. Le plus souvent, ce sont les règles du type ‘ tout le contenu ’, ‘ toutes les pages ’, ‘ tous les articles ’, etc. qui peuvent être à l'origine d'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 HTTP de mise en cache du navigateur. L'utilisateur consulte une page protégée, et un plugin de mise en cache indique au navigateur de mettre cette page en cache (si l'utilisateur revient sur cette page plus tard, lui afficher le même contenu que celui qu'il voit actuellement). Ainsi, lorsque l'utilisateur se connecte ou s'inscrit, puis revient sur la page protégée, le navigateur lui affiche la version mise en cache de la page au lieu de rechercher 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 de la page entière dans la configuration de votre plugin de mise en cache. Seuls les éléments statiques tels que les fichiers CSS, JS, les images, les polices, 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 via une URL « www », puis accède à une page sans « www », WordPress considérera qu'il s'est déconnecté. La mise en place d'une redirection via le fichier .htaccess pour forcer l'une ou l'autre des URL permet généralement de résoudre 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 via https, puis accède à une URL http, il sera considéré comme déconnecté. Si vous disposez d'un certificat SSL/TLS (https) sur votre site, il est recommandé d'utiliser le protocole https sur l'ensemble du site. Le Plugin SSL vraiment simple C'est idéal pour cela. Veillez toutefois à mettre à jour vos URL de Webhook ou d'IPN pour qu'elles utilisent le protocole https au niveau de la passerelle, si elles sont actuellement configurées pour utiliser le protocole http.