¿Qué hacer cuando el usuario no puede acceder al contenido?

Si descubre que sus usuarios le informan de que no acceden a sus contenidos protegidos cuando creen que deberían hacerlo, hay un par de cosas que puede comprobar. 

Antes de repasar las listas que figuran a continuación muy recomendable utilizando el Plugin de cambio de usuario 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. 

Una vez comprobado que efectivamente el usuario no puede acceder al contenido que debería, aquí tiene dos listas de elementos que debe comprobar:

Puntos principales que debe comprobar: cosas que debería poder hacer fácilmente por sí mismo.

• 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 si hay algún goteo o caducidad establecidos en la regla que protege el contenido. Si el usuario está fuera de esas ventanas, no tendrá acceso.
• Compruebe si hay conflictos de normas como se explica aquí – 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. 
• Si no tienes reglas, prueba a añadir una, siempre puedes borrarla después si se resuelve el problema. Para obtener más información, consulte: ¿Por qué están todas mis páginas bloqueadas si no tengo reglas?

Elementos secundarios que deben comprobarse - puede requerir la ayuda de su anfitrión o desarrollador

• 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 no www. Las cookies de inicio de sesión de WordPress son buenas bajo www o no www - pero no 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 - similar al punto anterior, excepto que las cookies de inicio de sesión sólo son buenas bajo http o https - pero no 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 Plugin SSL realmente sencillo 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.