6.11 What to do When User Can't Access Content?

If you are finding that your users are reporting not getting access to your protected content when they believe that they should, there are a couple of things that you can check. 

Before going over the lists below, we highly recommend using the User Switching plugin 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. 

Once verifying the user indeed cannot access the content that they should, here are two lists of items you should check:

Primary Items to Check - things you should be able to easily do on your own

• 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 setup 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).
• Verify any Dripping or Expiration's set on the rule protecting the content. If the user is outside of those windows, they will not have access.
• Check for rule conflicts as explained here - 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. 

Secondary Items to Check - may require help from your host or developer

• 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 non-www. WordPress login cookies are good under www or non-www -- but not for both. 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 to the above point, except the login cookies are only good under http or https - but not both. 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 Really Simple SSL plugin 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.