Was ist zu tun, wenn der Benutzer nicht auf den Inhalt zugreifen kann?

Wenn Sie feststellen, dass Ihre Nutzer berichten, dass sie keinen Zugriff auf Ihre geschützten Inhalte erhalten, obwohl sie glauben, dass sie es sollten, gibt es einige Dinge, die Sie überprüfen können. 

Bevor wir die nachstehenden Listen durchgehen, sollten wir sehr empfehlenswert unter Verwendung der Plugin zur Benutzerumschaltung 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. 

Nachdem Sie sich vergewissert haben, dass der Benutzer tatsächlich nicht auf den Inhalt zugreifen kann, den er eigentlich sollte, finden Sie hier zwei Listen mit Punkten, die Sie überprüfen sollten:

Wichtigste zu prüfende Punkte - Dinge, die Sie leicht selbst erledigen können sollten

• 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).
• Überprüfen Sie, ob die Regel, die den Inhalt schützt, mit einer Sperrfrist oder einem Ablaufdatum versehen ist. Befindet sich der Benutzer außerhalb dieser Fenster, hat er keinen Zugriff.
• Prüfen Sie auf Regelkonflikte wie erläutert hier – 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. 
• Wenn Sie keine Regeln haben, versuchen Sie, eine hinzuzufügen. Sie können sie danach immer noch löschen, wenn das Problem gelöst ist. Um mehr zu erfahren, siehe: Warum sind alle meine Seiten gesperrt, wenn ich keine Regeln habe?

Zu prüfende sekundäre Elemente - erfordert möglicherweise die Hilfe Ihres Hosts oder Entwicklers

• 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. nicht-wwww. WordPress-Login-Cookies sind gut unter www oder nicht-wwww - aber nicht für beide. 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 - ähnlich wie oben, außer dass die Anmelde-Cookies nur unter http oder https gültig sind - aber nicht beides. 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 Wirklich einfaches 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.