Backend-Zugriff pro Benutzerstatus

Ich brauche Hilfe!

Wenn ein Mitglied auf meiner Seite nicht mehr zahlt, seine Mitgliedschaft abläuft oder abbricht, erlaubt das Plugin weiterhin den Login-Zugriff auf wp-login.php, das sie direkt an das Backend-Kontrollfeld sendet.

Was ich brauche, ist, dass es ihnen erlaubt ist, sich einzuloggen, aber RESTRCICT Zugriff auf das Backend-Kontrollfeld abhängig von ihrem “Status”. Dies sollte in Sekundenschnelle sinnvoller sein.

Information.

Tabelle: wp_pmpro_memberships_users Feld: user_id Feld: status Daten im Statusfeld: abgebrochen, inaktiv, aktiv, (möglicherweise andere, aber das sehe ich)

Feld “user_id” MATCHES “ID” von “wp-users”

Was ich also brauche ist, dass wp-login.php zwischen “status” Levels unterscheidet.

wenn Status = “Aktiv” Weiterleitung zu “Dashboard”

sonst KILL / ALLE ZUGRIFFE auf Dashboard beschränken und auf “Mitgliedsseite” redirect.

Zu diesem Zeitpunkt können sie ihre Mitgliedschaft erneuern und den Dashboard-Zugriff wieder aktivieren.


oder gibt es ein Mitgliedschafts-basiertes Plugin, das das schon macht ????? Ich nehme an, nicht, weil es so aussieht, als müssten Sie Core-Dateien ändern, um dies zu erreichen. So oder so, ich brauche das zu 100% automatisiert.

Bitte helfen Sie. !!

PS leider brauche ich Arbeitscode, keine Theorie. Ich bin kein großartiger Programmierer. Ich weiß, es ist eine Menge zu fragen, aber ich brauche dringend Hilfe und kann es mir nicht leisten, das zu bezahlen, was die Leute verlangen, um das zu erreichen.

Solutions Collecting From Web of "Backend-Zugriff pro Benutzerstatus"

Ich entschied mich, immer noch eine Antwort basierend auf dem Titel Backend-Zugriff pro Benutzerstatus zu liefern

Beachten Sie, dass dies eine Erklärung für das Konzept zum Gewähren oder Einschränken des Zugriffs basierend auf Benutzerstatus (Rollen oder functionen) ist. Dies könnte oder könnte nicht direkt auf Ihre Situation angewendet werden, da Sie ein Drittanbieter-Plugin mit seiner eigenen Logik verwenden. Aber ich glaube, dass es relevant ist, weil ich hier eine grundlegende WP-Zugangslogik zeige, von der ich sicher bin, dass Ihr Plugin teilweise oder ganz darauf basiert.

Jetzt zur langen Erklärung!

Was wir eigentlich machen wollen ist

  • Überprüfen Sie unsere aktuelle Benutzerstatusstufe (ich würde den Status den functionen zuordnen)
  • Wenn der Status active ist, gewähren Sie Zugriff auf das Dashboard.
  • Wenn der Status etwas anderes ist ( pending , canceled , inactive usw.), dann redirect auf die Anmeldeseite
  • Ich werde die Komplexität für diese Erklärung niedrig halten, aber wir könnten nach mehr Kontexten suchen und für jeden Kontext eine andere Regel anwenden. Hier wird es ” active ” und else
  • Die Logik des Zuordnens und Änderns von Mitgliedschaftsstufen zu einem Benutzer wird weggelassen, da dies das Mitgliedschafts-Plugin ist (und das ist außerhalb des Rahmens dieser Erklärung). Also werde ich mich wieder auf den Backend-Zugriff pro Benutzer-Status konzentrieren, unter der Annahme, dass sich die Statuslogik um einen anderen process kümmert.

Daher bieten WP-Rollen und -functionen eine große Flexibilität, um den Zugriff und die Einschränkungen eines Benutzers auf die Site zu verwalten.

Eine Rolle ist wie ein Container für Fähigkeiten und definiert den Kontext eines Benutzers.

Fähigkeiten sind Flaggen, auf denen wir überprüfen können, ob eine Aktion erlaubt ist oder nicht. Zum Beispiel ist edit_posts eine WP-Fähigkeit. Wenn das Häkchen if( current_user_can( 'edit_posts' ) ){ // Do something } wird true wenn das Flag für edit_posts gesetzt ist, wir machen etwas, wenn nicht, wird es fehlschlagen und wir können etwas anderes tun oder retten.

Eine Rolle kann 1 oder mehr functionen haben, wir können Rollen benutzerdefinierte functionen hinzufügen und functionen aus Rollen entfernen. Wir könnten auch einfach das Flag umschalten, was im Hinblick auf die DB-Abfrage besser ist (Flag-Toggle werden zur Laufzeit ausgeführt, also keine DB-Abfragen). Wir könnten auch benutzerdefinierte Rollen mit corefunktionen oder eigenen eigenen erstellen. Das macht WP für viele Anwendungsfälle so flexibel.

Mithilfe von Filtern können wir functionen für bestimmte Benutzer oder spezielle Kontexte spontan hinzufügen.

Zurück zu Ihrem Mitgliedschafts-Plugin. Ich gehe davon aus, dass das Plugin eine Reihe von Prüfungen durchführen würde, um festzustellen, ob ein Mitgliedschafts-Abonnement gültig ist oder nicht. Ich nehme auch an, dass Sie mindestens 2 Rollen zur Verfügung haben. Nennen wir sie Aktive Mitglieder für gültige Mitgliedschaften und Inaktive Mitglieder für expired , canceled Mitgliedschaften. Wenn Sie einen Benutzer haben, der noch kein Mitglied ist, könnte er den WP-corerollen- subscriber der keine wirklichen Fähigkeiten außer dem Zugriff auf sein Profil hat Seite. Auch hier bin ich davon überzeugt, dass das Mitgliedschaftsplugin die Rolle eines Benutzers auf der Basis der Bestätigung seines Mitgliedsstatus programmatisch ändern würde. (Normalerweise sollte / sollte dies mit einem (guten) Mitgliedschafts-Plugin geschehen)

Schließlich, sobald alles gesetzt ist, würden wir eine function haben, die die current_user_can function und den user_has_cap Filter verwenden würde und den Zugriff des Benutzers basierend auf der aktuellen Rolle modifizieren würde. (Die aktuelle Rolle basiert auf der Plugins Verifizierung des Mitgliedsstatus)

Hier ist ein Beispiel, das auf dem basiert, was ich gerade dargelegt habe. Unsere aktiven Mitgliederrollen sollten die Möglichkeit haben, see_premium_content (oder was auch immer das für das Beispiel ist), die unsere Inaktiven Mitglieder nicht haben würden oder auf false gesetzt werden. Auf dieser Grundlage würden wir 2 functionen zum Überprüfen und Einschränken benötigen. Es würde ungefähr so ​​aussehen.

 add_action( 'init', 'wpse_backend_access_rules' ); function wpse_backend_access_rules(){ // check to see if current logged in user can "see_premium_content" add restriction if not by modifying capabilities if( ! current_user_can( 'see_premium_content' ) ){ add_filter( 'user_has_cap', 'inactive_membership_cap_filter', 10, 3 ); } } function inactive_membership_cap_filter( $allcaps, $cap, $args ) { // give only permission to access own profile in dashboard. // On the profile dashboard, you can output a message inviting to sign up again. $allcaps = array( 'read' => true ); return $allcaps; } 

ok cool .. Bynicolas. Wenn Sie noch lesen, Hier ist meine Aufschlüsselung von dem, was ich gesammelt habe.

Ich glaube, Sie haben ein gutes Verständnis davon, was ich erreichen möchte, aber ich werde einige Dinge ansprechen, um zu überprüfen, ob wir beide auf derselben Seite sind … ich selbst eingeschlossen.

Die Logik des betreffenden Plugins schafft Mitgliedschaften auf verschiedenen Preislevels. Es erlaubt dem Benutzer grundsätzlich, verschiedene “Kategorien” innerhalb von Beiträgen oder bestimmten Mitgliederbereichsseiten zu lesen. Das ist überhaupt nicht das, was ich will oder brauche. Es akzeptiert jedoch Geld für wiederkehrende Acts und es erstellt / generiert Benutzer. Ein zweites Plugin erstellt Rollen, Rollengruppen usw. und ich kann bestimmte Dashboard-Inhalte für bestimmte Benutzer zulassen. dadurch kann ich zum Beispiel sagen, dass ein “freier mitgliedschaft” benutzer, der durch das mitgliedschafts-plugin erstellt wurde, eine spezifische Rolle für den Zugriff auf “Eigenschaften” (wie in Häusern / Häusern) gibt. oder eine “korporative Mitgliedschaft” kann die Rolle des “vollen Zugangs” haben, um Zugang zu Immobilien, Grundstücken, Gewerbeimmobilien, Eigentumswohnungen, blah blah “zu erhalten.

Nichtsdestotrotz schränkt keines der Plugins den Dashboard-Zugriff ein, sobald er abgelaufen ist. und da die Bereiche, auf die sie nach Rollen zugreifen, nicht externe Seitenbereiche wie Posts oder bestimmte Seiten auf der öffentlichen Seite der Site sind, brauche ich diese Einschränkung. Ich habe jedoch das Gefühl, dass Sie das Konzept sehr gut verstehen.

Wie für Punkt 3, ja, ich verstehe, dass es mehrere mögliche Umstände je nach Statuswert geben könnte, aber ich bin in Ordnung mit dem Senden sie auf die Anmeldeseite unabhängig von Status, abgesehen von “Active”. Dies ist etwas, was ich vorher mit mir diskutiert habe, und wie Sie dachte, “halten Sie die Komplexität gering”.

Danach wird viel über Rollen geredet, was ein Konzept ist, das ich erst kürzlich völlig verstanden habe, nachdem ich mehrere Stunden damit verbracht habe, während der Konfiguration des Rollen-Plugins auf meinen Monitor zu schreien. Der Rollenbereich der database befindet sich jedoch nicht dort, wo der Status gehalten wird, sondern ist Teil des Mitgliedschaftsplugins. Aber … du hast das auch gesagt.

Ja, es macht eine Menge Schecks, und ich habe 6 Rollen oder Rollengruppen. Ich habe keine Wahl getroffen, welche ich verwenden soll. Ich denke Gruppen. aber wie im zweiten Absatz über Zugang und “Status” usw. erwähnt … keine Notwendigkeit zu wiederholen.

Nun, das ist die Sache “Wiederum nehme ich an, dass das Mitgliedschafts-Plugin programmatisch die Rolle eines Benutzers basierend auf der Bestätigung seines Mitgliedsstatus ändern würde. (Normalerweise sollte dies durch ein (gutes) Mitgliedschafts-Plugin geschehen)” Das Mitgliedschaftsplugin weist keine Rollen zu, erstellt, ändert, delegiert usw. überhaupt. Es ermöglicht nur den Zugriff auf bestimmte sichtbare Website-Inhalte. wie “Sie können jetzt auf example.com/paid_stuff/free_area zugreifen” … das ist das Problem. Ich versuche, etwas zu tun, was es von Natur aus nicht tut. Ich muss noch ein Mitgliedschafts-Plugin finden, das Benutzerrollen / -gruppen erstellt und den potenziellen Zugriff auf Dashboard-Elemente ändert, und dann gibt es die Tatsache, dass es höchstwahrscheinlich keine Dinge wie “nur Benutzern erlauben, die von ihnen hochgeladenen Medien zu sehen” tun würde. . was mein Rollen Plugin tut. Deshalb ist das Ganze ein Durcheinander. Ich muss 3 Plugins verwenden, um 80-90% von dem zu erreichen, was ich brauche, und muss alle Kundenzugriffe manuell aktualisieren, und Rollen manuell zuweisen, etc. Ich bin damit einverstanden, den Großteil davon zu tun, aber. Ich möchte nicht jeden Tag einen Kalender auf meiner Desktop-Einstellungs-Warnung haben müssen, über den ich mich als Benutzer informieren und ihn vorübergehend sperren kann, damit sie nicht mehr darauf zugreifen können, weil ihr Konto abgelaufen ist. Es ist keine erweiterbare Lösung.

aber ich fühle mich wie du das bekommst.

“Schließlich, sobald alles eingestellt ist, würden wir eine function haben, die die current_user_can-function und den user_has_cap-Filter verwendet und den Zugriff des Benutzers basierend auf der aktuellen Rolle ändert. (Die aktuelle Rolle basiert auf der Plugins-Überprüfung des Mitgliedschaftsstatus)” This Teil ich verstehe nicht, und ich weiß nicht, ob wir auf der gleichen Seite sind. Vielleicht bin ich es, also wiederhole ich es. vorher hast du gesagt

“Wiederum nehme ich an, dass das Zugehörigkeits-Plugin programmatisch die Rolle eines Benutzers basierend auf der Bestätigung seines Mitgliedsstatus ändern würde. (Normalerweise sollte dies durch ein (gutes) Mitgliedschafts-Plugin geschehen)” aber meins tut es nicht nicht. Ist der vorherige Absatz noch gültig? Oder muss es jetzt überarbeitet werden, da der angebotene Code auf dieser Idee basieren könnte?

Der letzte Absatz ist, wo ich verloren bin, in den vorherigen Absätzen. Also im Grunde, ich bin auf dem “ok, also hier ist, wie Sie es tun würden” verloren. lol und .. ich weiß, das wird sich auch lächerlich anhören. In welcher Datei würde ich suchen? functionen oder wp-Login um die Änderungen zu implementieren? Außerdem habe ich buchstäblich nie mit etwas gearbeitet oder programmiert, das DB-Informationen zur Laufzeit sammelt. Das ist für mich ein sehr fremdes Konzept. Aber es erklärt auch, warum ich auf diesen Seiten noch nie Fragen gefunden habe.

aber ich denke, wir werden wärmer .. aber lange Rede kurzer Sinn, Sie verstehen das Problem auf jeden Fall. aber ich verstehe die Lösung nicht. lol