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 um die Zugriffsrechte Ihres Benutzers zu überprüfen. Auf diese Weise lässt sich nahtlos feststellen, auf welche Inhalte der Benutzer genau Zugriff hat, ohne dass er nach seinem Passwort gefragt wird. 

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

• Stellen Sie sicher, dass der Benutzer über ein aktives Abonnement verfügt. Dies sollte auf der Seite ‘MemberPress > Abonnements’ überprüft werden; in der Spalte „Aktiv“ sollte dort ein grünes „Ja“ angezeigt werden. 
• Überprüfen Sie, ob Sie Ihre Regel für den genannten Inhalt korrekt eingerichtet haben. Sie müssen sicherstellen, dass Sie auf der Bearbeitungsseite Ihrer Regel die Mitgliedschaft, die der Nutzer erworben hat (zusammen mit etwaigen weiteren Mitgliedschaften), korrekt ausgewählt haben.
• Ü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 – das heißt, zwei Regeln, die denselben Inhalt schützen. Am häufigsten kann eine Regel vom Typ ‘alle Inhalte’, ‘alle Seiten’, ‘alle Beiträge’ usw. einen solchen Konflikt verursachen. 
• 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-Caching-Header des Browsers. Ein Nutzer besucht eine geschützte Seite, und ein Caching-Plugin weist den Browser an, diese Seite zwischenzuspeichern (sollte der Nutzer sie später erneut aufrufen, wird ihm derselbe Inhalt angezeigt, den er gerade sieht). Der Nutzer meldet sich also an oder registriert sich, kehrt zur geschützten Seite zurück, und der Browser zeigt ihm die zwischengespeicherte Version der Seite an, anstatt nach einer neuen Version zu suchen, da er nun angemeldet ist. Dieses Problem lässt sich in der Regel beheben, indem Sie das Caching ganzer Seiten in der Konfiguration Ihres Caching-Plugins deaktivieren. Nur statische Elemente wie CSS, JS, Bilder, Schriftarten usw. sollten vom Browser zwischengespeichert werden. 
• www vs. nicht-wwww. WordPress-Login-Cookies sind gut unter www oder nicht-wwww - aber nicht für beide. Wenn sich der Benutzer also über eine URL mit „www“ anmeldet und anschließend zu einer Seite ohne „www“ wechselt, wird er von WordPress als abgemeldet betrachtet. Das Problem lässt sich in der Regel beheben, indem man eine Weiterleitung in der .htaccess-Datei einrichtet, um die Verwendung der einen oder der anderen URL zu erzwingen.
• http vs. https - ähnlich wie oben, außer dass die Anmelde-Cookies nur unter http oder https gültig sind - aber nicht beides. Wenn sich der Benutzer über https anmeldet und anschließend eine http-URL aufruft, gilt er wieder als abgemeldet. Wenn Sie ein SSL/TLS-Zertifikat (https) auf Ihrer Website haben, wird empfohlen, die gesamte Website vollständig auf https umzustellen. Die Wirklich einfaches SSL-Plugin Das eignet sich hervorragend dafür. Achten Sie jedoch darauf, Ihre Webhook- oder IPN-URLs so anzupassen, dass sie https am Gateway verwenden, falls sie derzeit auf http eingestellt sind.