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 den Zugang des Benutzers zu überprüfen. Auf diese Weise können Sie nahtlos überprüfen, worauf genau der Nutzer Zugriff hat, ohne nach seinem Passwort zu fragen. 

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

• Überprüfen Sie, ob der Benutzer ein aktives Abonnement hat. Dies sollte auf der Seite MemberPress > Abonnements überprüft werden, und unter der Spalte "Aktiv" sehen Sie ein grünes "Ja". 
• Vergewissern Sie sich, dass Sie Ihre Regel für den zu erwähnenden Inhalt korrekt eingerichtet haben. Sie müssen sicherstellen, dass Sie auf der Bearbeitungsseite Ihrer Regel die Mitgliedschaft, die der Benutzer erworben hat, korrekt ausgewählt haben (zusammen mit anderen Mitgliedschaften).
• Ü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 - d.h. zwei Regeln zum Schutz desselben Inhalts. In den meisten Fällen 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-Browser-Caching-Header. Der Benutzer besucht eine geschützte Seite, und ein Caching-Plugin weist den Browser an, diese Seite zwischenzuspeichern (und dem Benutzer bei künftigen Besuchen dasselbe zu zeigen, was er jetzt sieht). Der Benutzer meldet sich also an oder registriert sich, kehrt zu der 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. Dies lässt sich in der Regel beheben, indem Sie in der Konfiguration Ihres Caching-Plugins das Browser-Caching für die gesamte Seite deaktivieren. Nur statische Elemente wie CSS, JS, Bilder, Schriftarten usw. sollten vom Browser gecacht 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 unter einer www-URL anmeldet und dann eine Seite aufruft, die nichtwww ist, wird er von WordPress als abgemeldet angesehen. Eine .htaccess-Umleitung, die das eine oder das andere erzwingt, behebt dies normalerweise.
• http vs. https - ähnlich wie oben, außer dass die Anmelde-Cookies nur unter http oder https gültig sind - aber nicht beides. Wenn der Benutzer sich unter https anmeldet und dann eine http-URL aufruft, wird er wieder als abgemeldet angezeigt. Wenn Sie ein SSL/TLS-Zertifikat (https) auf Ihrer Website haben, empfiehlt es sich, die gesamte Website auf https umzustellen. Die Wirklich einfaches SSL-Plugin ist dafür hervorragend geeignet. Stellen Sie sicher, dass Sie Ihre Webhook- oder IPN-URLs aktualisieren, um https am Gateway zu verwenden, wenn sie derzeit auf http eingestellt sind.