Paid Memberships Pro: an open-source membership layer for WordPress, and the support model behind it

What the plugin does, and who it is for

Paid Memberships Pro gives you all the tools you need to start, manage and grow your membership site, and the plugin is designed for premium content sites, clubs and associations, subscription products, newsletters and more.

The flow it implements is short. Users select a membership level, complete checkout, and immediately become members of the site. The site owner decides what content a member can access. Members can log in, view payments, update billing information, or cancel their account directly on the site.

That last sentence is the one that distinguishes this from a paywall. The plugin is not a content blocker with a subscription attached; it is a membership system with a content restriction feature, and the members manage their own billing relationship with the site rather than through the plugin's own interface.

The primary language is PHP, the licence is recorded as a custom one GitHub cannot classify even though the badge in the README says GPL-2.0+, the default branch is dev, and the homepage is paidmembershipspro.com. The last push was on 2026-10-16 with the project not archived. The recent releases are 3.9-rc.1 from 2026-10-16, 3.8.9 from 2026-10-12 and 3.8.8 from 2026-10-06, so there is a release candidate in flight alongside the patch line.

The repository description calls it the trusted membership platform that grows with you, mentioning Stripe, PayPal and more, and the topic list confirms the shape: wordpress, wordpress-plugin, ecommerce, ecommerce-platform and paid-memberships-pro.

What makes this interesting to read is not the feature set, which is fairly standard, but the fact that the whole thing is open source and sold as support rather than as the software.

Why the repository ships two comparison guides

The first thing you meet in the README is not a feature list. It is a pair of guides explaining why you might not want this plugin at all, or at least not this one.

The first guide is WordPress versus SaaS membership platforms, and the question it asks is whether you should build your membership site on WordPress or use a hosted SaaS platform like Kajabi or Podia. Each option comes with trade-offs, from cost and flexibility to scalability and ownership, and the comparison walks through real-world pros and cons.

The second guide compares the best WordPress membership plugins, and it includes the plugin itself in the comparison, on the grounds of features, pricing, security, scalability and flexibility.

Both are linked from the README of the project's own repository. That is a deliberate choice, and it tells you something about the project's posture. A plugin whose README leads with a comparison against SaaS platforms and against its own competitors is making a different argument from the usual one. The argument is not that you must use this plugin; it is that you should build on WordPress if that suits you, and if you do, here is how the options compare including this one.

It also has a practical effect. A reader who arrives at the repository and is considering a hosted platform leaves with a better understanding of the trade-off than they would have got from a feature bullet list. And for a project selling a support licence, being the one pointing out where the hosted alternative is better is a way of making the recommendation credible.

Neither guide is in the repository. They are on the project website, so the GitHub repository is a developer's portal and the website is the product documentation, which is the split the Support section makes explicit.

The licensing model, and what the support licence actually buys

Paid Memberships Pro is distributed under the GPLv2 license, which means, among other things, that you may use the software on any site free of charge.

That is the core of the model, and it is a deliberate one. The software itself carries no licence fee. What is recommended is an annual support license for websites running the plugin, and the support licence includes access to the technical support team in the Member Support Area, one-click installation and updates for feature-enhancing Add Ons based on your level, and a 100 day, no questions asked refund policy.

Read that carefully, because the boundaries matter. The support licence is what gets you the support team, the one-click install and update path, and the add-ons. The plugin itself stays free and stays GPL, so anyone can self-serve the core functionality.

The add-on model is the interesting part, because the licence level determines which add-ons you get one-click installation and updates for. That is how a GPL plugin can still have a commercial tier that is worth buying: the paid product is not a fork of the code, it is a set of extensions and a support relationship.

The description calls it fully open source and 100% GPL, and the README's own open source section is the same claim in the licence's own terms.

The refund policy is a small signal about how the support business is run. A hundred days with no questions asked is long, and it is the sort of term you only see where the company expects a meaningful share of purchases to be considered rather than kept.

The site also sells a separate membership product of its own, since the plugin's own commercial offering is a paid support membership. The project and the product are the same organisation, Stranger Studios, which is visible in the package author field.

The contributor routes, including the ones for people who do not code

The Contributing section is unusually broad in what it counts as contributing, and the split is explicit.

For developers there are two routes. Report bugs and issues on GitHub through the issue template, and work on any issues by submitting a pull request.

Then there is a section headed here are some ways for non-developers to contribute, and the three listed are worth taking at face value because they are the commercial and community strategy of the project in three lines.

Translate Paid Memberships Pro into your own language. Purchase a paid membership to help fund ongoing development and bug fixes. And leave an honest review for the plugin.

The first is a translation effort, and there is a dedicated page for it, paid-memberships-pro-in-your-language, which tells you the project treats a translated interface as a first-class contribution rather than a favour. Given the plugin targets membership sites and the topic list includes a range of international markets, a translation effort is a direct way to grow the user base.

The second is the interesting one. A purchase is framed as a contribution rather than a transaction, and the framing is honest, since the money does fund the work. It also makes the point that a GPL project with a commercial support model is not a contradiction: the money comes from users who want support and add-ons, and it goes back into the code everyone runs.

The third is a request for an honest review, and the word honest is doing the work. A project asking for reviews rather than ratings is asking for evaluations that might not be flattering, which is a small signal of confidence in the product.

The contribution guidelines themselves live in .github/CONTRIBUTING.md on the dev branch, and the README points there rather than duplicating them.

There is also a Contributing Licence Agreement file, CLA.md, at the repository root, which is the mechanism by which contributions are collected under a licence that matches the project's own.

Installing the development build, and the repository layout

The installation instructions for this repository are for developers, not for site owners, and they are specific about which build to take.

The documented route is to download the current development ZIP file directly, from the archive URL for the dev branch, and the README is emphatic that once installing this version of the plugin you must remove -dev from the plugin's folder name. That is a WordPress-specific detail, because WordPress identifies a plugin by its folder name and a folder called paid-memberships-pro-dev would be a different plugin from the released one.

For ordinary installation the README points at the documentation for installing the plugin and for the initial plugin setup, which is the right division: the site documentation covers the user-facing path and the repository covers the development path.

The repository layout is a standard WordPress plugin structure with a few additions. There is paid-memberships-pro.php as the plugin entry point, and the standard directories adminpages/, blocks/, includes/, pages/, services/, shortcodes/ and preheaders/, plus languages/ for translations, css/, js/ and images/ for assets.

Two of these are worth noting because they tell you what the plugin does. blocks/ means the plugin registers WordPress blocks, so its content restriction and checkout elements can be placed with the block editor rather than shortcodes. shortcodes/ means there is also a shortcode route for the same functionality, which is what a plugin supporting both the classic editor and the block editor looks like. And services/ is where the payment and membership logic lives, separated from the admin pages, which is the structure that lets the same plugin support several payment providers.

The JavaScript side is built with wp-scripts, the WordPress build tooling:

  "scripts": {
    "build": "wp-scripts build",
    "format": "wp-scripts format",
    "lint:css": "wp-scripts lint-style",
    "lint:js": "wp-scripts lint-js",
    "packages-update": "wp-scripts packages-update",
    "plugin-zip": "wp-scripts plugin-zip",
    "start": "wp-scripts start"
  },

So the build script is wp-scripts build, the linters are separate for styles and JavaScript, there is a plugin-zip script to package the release artefact, and start runs the development server. The dependency list is small:

  "devDependencies": {
    "@wordpress/scripts": "^23.5.0"
  },
  "dependencies": {
    "classnames": "^2.3.2"
  }

One dev dependency, @wordpress/scripts at about 23.5, and one runtime dependency, classnames. A JavaScript build with a single runtime dependency is a good sign for a plugin that loads on every page of a site, because the shipped JavaScript is not going to drag a framework in with it.

There is also a composer.json alongside, since the plugin is PHP, and a phpcs.xml.dist for the coding standard, a CHANGELOG.txt, a readme.txt in the WordPress plugin repository format, an uninstall.php, a SECURITY.md and a webpack.config.js.

How to evaluate it, and the questions to ask first

There are four things to consider.

First, whether the open core model fits what you are building. The plugin is free and GPL, and the paid tier buys support, one-click updates and add-ons. If you are comfortable running the free version and troubleshooting it yourself, that is a complete product. If you are running a membership site where downtime costs money and you do not have someone who can read PHP, the support licence is the sensible purchase, and the hundred-day refund policy makes the decision low risk.

Second, the payment providers. The repository description names Stripe, PayPal and more, and the services/ directory is where that logic lives. The practical question is whether the provider you need is supported, and whether the recurring subscription behaviour matches how you bill. Membership software lives or dies on how it handles a failed card, a cancellation and a refund, and those are the details to test before you launch rather than after.

Third, the release discipline. The recent releases are 3.8.8, 3.8.9 and then 3.9-rc.1, with the release candidate published on the same day as the last push, which suggests a structured release process rather than ad hoc tagging. The default branch is dev and the releases are cut from it, so the development build in the repository is ahead of the stable plugin, and the -dev folder rename instruction is the practical reminder of that.

Fourth, the security surface. A membership plugin handles payment details and sits in front of every page of a site, so it is a high-value target, and the repository has a SECURITY.md and a dedicated issue template for detailed bug reports, plus a GitHub issue chooser for reports. The README is explicit that this is a developer's portal and that support questions go to the site rather than to the issue tracker, which is a sensible division for a project with a paid support offering.

What you get is a mature, actively developed membership plugin whose core is genuinely free and whose commercial tier is support rather than access, plus a documentation site with comparison guides that are unusually candid. The cost is the usual one for a GPL plugin with proprietary add-ons, which is that some functionality lives outside the repository you can read.

Editorial conclusion

Adopt Paid Memberships Pro if you are running a membership site on WordPress and want a mature plugin that handles levels, checkout and recurring subscriptions without a licence fee for the software itself. Do not expect every capability to be in the repository, because the paid tier covers the add-on ecosystem, so check which features you need are in the free core and which sit behind a purchase. Before you commit, test the failed payment, cancellation and refund paths with the payment provider you intend to use, since that is where membership software earns or loses its reputation, and read the two comparison guides on the project website, which compare WordPress against hosted platforms and this plugin against its WordPress competitors, before you commit to either the platform or the plugin.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. strangerstudios/paid-memberships-pro on GitHub