MemberPress

MemberPress does two jobs in one product: it decides who may see what, and it takes the recurring payment that grants it. Most of its value comes from those two being integrated — a lapsed payment revokes access without you wiring anything together.

That integration is also where the lock-in lives, because the resulting data is the least portable kind a WordPress site can hold.

The access model

Access is expressed as rules: a rule protects a set of content — specific pages, a whole post type, a category, a URL pattern — and grants it to one or more membership levels.

That model is worth understanding before you build, because it decides how tidy the site stays:

• Rules by taxonomy scale; rules by individual page do not. Protecting "everything in the Premium category" survives you adding a hundred posts. Protecting fifty pages individually becomes an administrative burden.
• Rules stack, so one piece of content can be reachable through several levels.
• Structure your content for the rules, not the reverse. Deciding this after two hundred posts exist is expensive.

The general framing of membership as three separate problems — payment, access, communication — is in how to build a WordPress membership site.

Billing

MemberPress runs its own checkout and its own subscription records rather than sitting on top of a store. For a pure membership that is the right shape: one signup flow, no cart, no product catalogue you do not need.

What to confirm for your situation:

• Which gateways are supported in your country, and whether card details stay at the gateway rather than on your site.
• How failed renewals are handled — retries, a grace period, then downgrade. Silent cancellation reads as theft to a member.
• Whether renewals that need a bank authentication challenge can prompt the member, or fail quietly.
• Upgrades, downgrades and proration, and what happens to the unused remainder.
• Whether the gateway's own fees are the ones you expect.

The mechanics of recurring billing, retries and the scheduler are the same class of problem described in WooCommerce subscriptions, and the failure modes are identical.

Courses and community

MemberPress sells add-ons for course structure and for community features. Whether to use them is the recurring question in this category.

The honest framing: if access control is the product and course structure is light, keeping everything in one plugin is simpler and cheaper to maintain. If teaching structure is genuinely the product — sequencing, assessment, progress, certificates — a dedicated LMS will do it better, and you accept two systems. That comparison is in WordPress LMS plugins.

Stacking two access systems is the mistake to avoid. Members who can pay but cannot get in almost always come from two plugins both believing they control access.

The lock-in

This is the section that matters, and it is not about shortcodes.

Members and content are portable enough. Users are WordPress users; protected content is ordinary content. Both export.

Subscriptions are not. An active recurring subscription is a payment token held at the gateway, created by this plugin, under its identifiers. Moving to another membership plugin generally means one of:

• the gateway supports transferring or re-referencing tokens, and someone does that work carefully; or
• you ask every member to re-enter their payment details, and you lose the ones who do not.

That is the real cost of switching, and it grows with every member you add. It is not specific to MemberPress — it is true of every plugin that owns billing — but it is worth naming before you have two thousand subscribers.

Rules and levels do not travel either, though rebuilding those is work rather than loss.

Protect files, not just pages

The failure worth checking on any membership setup: a PDF in wp-content/uploads/ is served directly by the web server and never reaches PHP, so no rule can gate it. Downloads must route through a PHP endpoint or the directory must be blocked at the server level. Test it by opening a protected file's direct URL in a private window.

While you are testing, check the protected content is genuinely protected rather than hidden: open the URL logged out, and check the REST API, the feed, the sitemap and site search.

Performance

Every member page is personalised, so it cannot be served from a page cache. A membership site is fast at the front and PHP-bound in the member area by construction.

What helps: object caching with Redis or Memcached, correct cache exclusions for login, account and checkout pages, and hosting sized for concurrent logged-in users rather than monthly pageviews. The layers are in choosing a cache plugin and the hosting question in managed WordPress hosting.

Who it suits

A good fit for: a site whose product is access — a paid library, a resource area, gated tools — where billing and access should be one system and there is no ordinary store.

A poor fit for: sites that also sell physical products, where one cart is worth more than tight integration; sites whose real requirement is course structure; and small private areas where a role plus a template check would have been enough.

Before you launch

Run the whole thing as a stranger on a staging copy: sign up and pay, receive the welcome email, open protected content, fail to open a higher tier, let a renewal fail and confirm the retry and the email, then cancel and confirm access ends exactly when it should. Then check that a protected file's direct URL is refused.

Both the happy path and the failed-payment path. Most sites test only the first and learn about the second from a member who is already angry.