MemberPress

Connect MemberPress membership levels to Jetonomy spaces - so paying members automatically land in the right discussion areas the moment their subscription activates.

Available in Jetonomy free. The MemberPress and Paid Memberships Pro adapters ship in the free plugin - you do not need Jetonomy Pro to gate spaces by these two membership plugins. (WooCommerce, Restrict Content Pro, and all LMS integrations require Jetonomy Pro.)

What You Will Learn

• How Jetonomy detects and communicates with MemberPress
• How to gate a space by membership level using Access Rules
• What happens when a membership activates or expires
• How to test the integration before going live

How Detection Works

Jetonomy checks for MemberPress automatically on every page load. No configuration needed. When MemberPress is active, the MemberPress adapter registers itself with Jetonomy’s Adapter Registry and enables the Access Rules UI inside each space’s settings.

Note: If you activate MemberPress after Jetonomy, navigate to Jetonomy → Settings and save once. This triggers adapter re-registration.

Setting Up an Access Rule

This is the standard Access Rules flow that every membership and LMS integration in this section follows. The other integration guides link back here for the full walkthrough.

1. Go to Jetonomy → Spaces and open the space you want to gate.
2. Click the Access Rules tab.
3. In the first dropdown, choose MemberPress. The dropdown lists the type of rule (Everyone, Logged In, WP Role, Capability, Trust Level) and one entry for each active membership plugin.
4. A search box appears next to it. Type to search and pick your membership level there.
5. In the last dropdown, choose what the rule grants: Read, Participate, or Full (see below). Participate is preselected and is the right answer for most paid spaces.
6. Click Add Rule. The rule appears in the Access Rules table below the form, and the form reads your rule back to you in plain English before you save it.

Members who hold the selected level gain access to this space at the level you chose.

A rule only adds access. It never locks anyone out. A Public space is already readable by everyone, so a rule on it restricts nothing, and Jetonomy warns you on the Access Rules tab. To sell access to a space, set Visibility to Private and Join Policy to Invite Only on the space’s General tab. Plan holders still get in automatically through the rule.

Tip: Add more than one rule if you want to grant access for more than one membership level. Rules are evaluated top to bottom by priority, and a member passes on the first rule they match.

Access level

An Access Rule has one setting that decides what a matching member can do:

Access level	What the member can do
Read	View and report topics and replies, but not post or reply
Participate	Read, post topics, and reply (the usual choice for a course or paid space)
Full	Participate, plus the moderator actions the member’s own WordPress capabilities already permit

Full does not hand out moderation by itself. Closing and pinning topics and editing other people’s posts still require the matching WordPress capability, which an ordinary member does not have - so for most paid members Full and Participate come to the same thing in practice. A rule can open a space to someone; it cannot give them a power their role does not carry. Appoint moderators on the space’s Members tab.

The space role a matching member is recorded as is derived from the access level, not chosen separately, and it is the same for every rule type (membership, role, capability, trust level):

Access level	Recorded as
Read	Viewer
Participate	Member
Full	Member

Rules never create moderators. Full is full participation, not moderation. Moderation is an appointment you make per person on the space’s Members tab; no rule, and nothing a visitor can buy, hands it out.

Changed in 1.8.1. This used to be two dropdowns - an access level and a space role - which could contradict each other. A rule labelled “Read” could be set to record people as space Admins, and that combination handed out post deletion and moderation. The role is now derived from the access level and capped by it, so a rule can never grant more than it advertises.

Changed in 1.9.1. 1.8.1 capped what the Access Rules screen could save, but enrolment itself still wrote the rule’s stored role straight onto the space. On a rule saved before 1.8.1, or written by the API, every member who enrolled took that role - including the ability to edit and delete other people’s posts. Every membership integration now applies the cap at enrolment, so the table above is what actually happens rather than what the screen intended. Rules already saved on your site are covered and you do not need to change anything. If someone was given a raised role this way, correct it on the space’s Members tab.

Note: There is no separate “Grant vs Revoke” switch. A rule always grants the access you choose to members who match it; members who match no rule simply do not get in. To take a level’s access away, delete its rule.

Access Follows the Subscription

Access is worked out at the moment someone opens the space, by reading your Access Rules against what they currently hold. Nothing has to be synchronised, and there is no step for you to run.

• Their membership goes active → they can open the space on their very next page load.
• Their membership expires, is cancelled, refunded or paused → they lose access just as immediately.
• They buy again → access returns.

Their posts and replies are never touched by any of this. Losing access hides the space from them; it does not remove what they wrote.

This is handled by the MemberPress_Adapter class, which hooks mepr-txn-status-complete for activation and mepr-txn-status-refunded, mepr-txn-expired, and mepr_subscription_transition_status for deactivation.

Changed in 1.8.1. Access rules used to be read only after Jetonomy had already decided you were a member of the space, which meant a rule could raise an existing member’s access but could never let anybody new in. Pointing a private space at a membership tier produced a space nobody could enter, and the only way in was the manual Sync Members button - which then never took anyone back out when their plan lapsed. Access is now resolved live, both directions, with nothing to sync.

What a paying member does not get yet

Access is automatic; the roster is not. Someone who gets in through a membership rule can read and post, but until you press Sync Members on the rule they:

• do not appear in the space’s Members list,
• are not included in the member count,
• are not matched by space settings that act on roles, such as “who can post: members”.

Sync Members writes those roster rows. A synced row counts only while a rule still admits the person: when their plan lapses, or you delete or change the rule, their access ends on their next page load, and the row is removed from the Members list in the background. Someone you added to the space by hand keeps their place.

What a Visitor Without the Membership Sees

Somebody who lands on a space gated by a membership rule is told which plan opens it and given a button to go and get it - rather than a generic “this space is private”.

The button goes to that membership’s own MemberPress registration page, so they arrive at the right plan instead of a pricing table they have to re-read. Every membership and LMS integration in this section does the same thing, each pointing at wherever that system sells the thing:

Integration	The button goes to
MemberPress	the membership’s own page
Paid Memberships Pro	checkout with that level preselected
Restrict Content Pro	your registration page with that level preselected
WooCommerce Memberships	the product that grants the plan
LearnDash, Tutor, LifterLMS, Sensei, MasterStudy	the course (or LearnDash group)
Learnomy	the course or membership plan

When there is no button, that is deliberate. Two cases:

1. The requirement is not something anyone can buy. Rules based on a WordPress role, a capability, a trust level, a CRM tag (WP Fusion) or an access group (SureMembers) state the requirement plainly and stop there, because sending a visitor to a checkout would be misleading.
2. The answer is ambiguous. A WooCommerce Memberships plan granted by three different products has three possible answers, and guessing which price point to sell somebody is worse than saying nothing. One granting product gives one button; several give none.

In either case you can point the button wherever you like with the jetonomy_membership_upgrade_url filter - see Custom Access Logic.

Visibility Behavior

Space Visibility	Non-member sees…
Public	Space listed and content readable by everyone. A rule only adds access, such as posting
Private	Signed-in people can find the space but see a lock message instead of content. Logged-out visitors do not see it listed
Hidden	Space not listed, and anyone without access sees “Space not found.”

Developer Hook

Both membership events fire the Jetonomy standard hooks you can use in your own code:

// Fires when a MemberPress membership activates.
add_action( 'jetonomy_membership_activated', function( int $user_id, string $level_id, string $adapter ) {
    // $adapter will be 'memberpress'
    if ( 'memberpress' === $adapter ) {
        // Custom logic here.
    }
}, 10, 3 );

Troubleshooting

No MemberPress entry in the first Access Rules dropdown - MemberPress may not be active. Check Plugins → Installed Plugins and confirm MemberPress is activated.

Member not joining on activation - Ensure the membership level ID in the Access Rule exactly matches the level in MemberPress. Level IDs are numeric; check the MemberPress level edit URL for the ID.

Member still has access after expiry - Check whether the member holds a second membership level that also grants access to the space.

What’s Next?

Learn how to gate spaces using Paid Memberships Pro, which follows the same pattern.

Paid Memberships Pro Integration →