O que fazer quando o usuário não consegue acessar o conteúdo?

Se você estiver descobrindo que seus usuários estão relatando que não estão obtendo acesso ao seu conteúdo protegido quando acreditam que deveriam, há algumas coisas que você pode verificar. 

Antes de examinar as listas abaixo, nós altamente recomendável usando o Plugin de troca de usuário to check your user’s access. This is a seamless way to verify what exactly the user is getting access to without asking for their password. 

Depois de verificar se o usuário realmente não pode acessar o conteúdo que deveria, aqui estão duas listas de itens que você deve verificar:

Itens primários a serem verificados - coisas que você deve ser capaz de fazer facilmente por conta própria

• Verify that the user has an active subscription. This should be checked on the MemberPress > Subscriptions page and under the active column you will see a green ‘Yes’. 
• Verify that you have correctly set up your rule for the content in mention. You need to make sure that on your Rule’s edit page, you have correctly selected the Membership that the user has purchased (along with any other Memberships).
• Verifique se há alguma configuração de gotejamento ou expiração na regra que protege o conteúdo. Se o usuário estiver fora dessas janelas, ele não terá acesso.
• Verifique se há conflitos de regras, conforme explicado aqui – meaning two rules protecting the same piece of content. Most commonly having an ‘all content’, ‘all pages’, ‘all posts’ etc. type rule can cause such a conflict. 
• Se você não tiver regras, tente adicionar uma. Se o problema for resolvido, você sempre poderá excluí-la depois. Para saber mais, consulte: Por que todas as minhas páginas estão bloqueadas se eu não tenho regras?

Itens secundários a serem verificados - pode exigir ajuda de seu host ou desenvolvedor

• HTTP browser caching headers. User visits a protected page, and a caching plugin tells the browser to cache that page (if visited in the future, show the user the same thing they’re seeing now). So the user logs in or registers, goes back to the protected page, and the browser shows them the cached version of the page instead of looking for a new version now that they’re logged in. This can usually be resolved by disabling full page browser caching in your caching plugin’s configuration. Only static items like CSS, JS, images, fonts , etc. should be cached by the browser. 
• www vs. não-www. Os cookies de login do WordPress são bons em www ou não-www - mas não para ambos. So if the user logs in under www URL, then browses to a page that is non-www – they’ll be seen by WordPress as logged out. Putting a .htaccess redirect to force one or the other usually fixes this.
• http vs https - semelhante ao ponto acima, exceto pelo fato de que os cookies de login só são válidos em http ou https mas não ambos. If the user logs in under https – then browses to an http URL – they’ll be seen as logged out again. If you have an SSL/TLS certificate (https) on your site, it’s recommended to go full https on the entire site. The Plug-in SSL realmente simples is great for that. Be sure to update your Webhook or IPN URL’s to use https at the gateway though, if they’re currently set to use http.