On October 17, 2024 we emailed [email protected] and asked them to close the Paid Memberships Pro listing in the WordPress.org Plugins Repository. They complied.

Going forward, every official Paid Memberships Pro plugin update will be served directly from our own license server, rather than through the WordPress.org Plugins Repository. For over nine years, we have been serving updates for our free and premium plugins through our own license and update server. We are now extending this process to include the core Paid Memberships Pro plugin.

Over time, we plan to serve updates for all of our plugins currently hosted on the .org repo, except for a few that are co-maintained with others.

Our decision to leave the .org repo was made after careful consideration and months of planning. We are doing everything we can to make this transition as seamless as possible for our current and future users. Still, there are a lot of questions around this, which this post will address.

Grassy background image with blue sky and words Leaving WordPress.org What It Means for PMPro Users

How will I receive updates in the future?

Every official Paid Memberships Pro plugin update will be served directly from our own license server.

If either the core Paid Memberships Pro plugin or the new PMPro Update Manager Add On is active on your site, you should be able to update from the Updates or Plugins page of your WordPress dashboard as you always have. Go to Dashboard > Updates and click the “check again” link on the Updates page if you don’t see the update in the list.

Or, you can manually update Paid Memberships Pro by following these steps:

  • Download the latest .zip of the plugin.
  • Log in to your site.
  • Navigate to Plugins > Add new.
  • Upload the zip file.
  • Confirm you want to overwrite the existing Paid Memberships Pro plugin.

Why is Paid Memberships Pro leaving the WordPress.org Plugin Repository?

WordPress.org is Matt Mullenweg’s personal website (source: the Automattic account on X.com). Matt is also the owner of our largest competitor, WooCommerce. The conflict of interest was always there, but in the weeks following WordCamp US 2024, Matt crossed several lines that make it crystal clear that he has no intentions of running WordPress.org as an open and fair platform.

Our mission at Stranger Studios is to help people “get paid” to support their lives and goals. Two of our core values that help us with that mission are a commitment to open source and a focus on purposeful work. Specifically, these values drive us to make the best possible software for the most possible people, and were a big reason the first decision we made for Paid Memberships Pro as a product was to release the entire plugin for free through the WordPress.org plugin repository.

Today, those same values have driven us to leave the WordPress.org plugin repository.

  • We would not be supporting open source if we were to distribute our plugin from a site where Matt will lock out users for any reason or even take over complete plugins if it suits him.
  • It would not be purposeful work to continue using the .org site or contribute to a WordPress project that could lock us out at any time or take over our plugins if it suits the one person in control of it all.

We began seriously thinking about these issues in early 2023 and decided that PMPro would have to move off the .org site eventually. We planned on a longer transition, but when Matt started blocking long time .org contributors for petty reasons and took over the Advanced Custom Fields plugin, we decided that it was best for our users to start updating PMPro from our own server while we still had the most control over how that would happen.

We are not a massive, private-equity-backed company. It took five years after we launched Paid Memberships Pro (from 2011 to 2016) to build a business that could support our family. Now going on our 14th year maintaining this platform, we have slowly bootstrapped the company from 2 people to nearly 20—from a few thousand dollars in annual revenue to nearly $2,000,000.

Jason and Kim Coleman in 2011 with son Isaac
Jason, Isaac, and Kim Coleman in July 2011—a few days after launching the first version of Paid Memberships Pro.

There are somewhere between 60,000 and 90,000 websites running on top of Paid Memberships Pro, many of them non-profit organizations or bootstrapped solopreneur businesses.

Collectively, these sites bring in hundreds of millions of dollars each year using our software, but it’s a wide distribution. A small few are making over $1,000,000 per year, but the vast majority of them are making a few thousand dollars or even a few hundred dollars each year.

These are the sites that would be disrupted by any tampering of the old Paid Memberships Pro listing. This is what worries us the most, and what we have been working hard to prepare for, prevent, and mitigate if need be.

Are you worried that Matt might retaliate somehow?

The fact we have to even ask this question is why we have to make this move.

Two days after we closed the Paid Memberships Pro listing in the .org repository, Matt sent a direct message to me (Jason) on the WordPress.org Slack Workspace threatening to “take over your listing and make it a community plugin like we did to ACF”.

Taking over the paid-memberships-pro slug in the .org repository and using it to host a forked version of Paid Memberships Pro would cause a lot of confusion for no good reason. I don’t think there is any reason for Matt and his team to attempt such a take over. I hope he just lets us move our plugin off .org without further disrupting our users and their businesses.

Matt may also try to taint our image by accusing us of breaking the Plugin Guidelines in the Paid Memberships Pro plugin.

Wait, were you breaking the Plugin Guidelines?

Matt may accuse Paid Memberships Pro of breaking guideline #8. The Paid Memberships Pro plugin includes code that updates our “Add On” plugins via our own server, which is prohibited by the current version of the guideline: (I added the bold for emphasis below)

8. Plugins may not send executable code via third-party systems.

Externally loading code from documented services is permitted, however all communication must be made as securely as possible. Executing outside code within a plugin when not acting as a service is not allowed, for example:

Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.org’s

  • Installing premium versions of the same plugin
  • Calling third party CDNs for reasons other than font inclusions; all non-service related JavaScript and CSS must be included locally
  • Using third party services to manage regularly updated lists of data, when not explicitly permitted in the service’s terms of use
  • Using iframes to connect admin pages; APIs should be used to minimize security risks

Management services that interact with and push software down to a site are permitted, provided the service handles the interaction on it’s own domain and not within the WordPress dashboard.

It should be noted that (a) this guideline was not in place when we added the Add On update code 9+ years ago and (b) it is still unclear to me what specifically breaks the guideline and what plugins with Add Ons are expected to do to comply.

Here is how the guideline read in September 5, 2015:

No sending executable code via third-party systems. Use of third-party systems is acceptable in a service-client type of model, but sending actual PHP or other executable code over the network is considered a security risk. Executing outside code like this is not allowed except for specific and very carefully considered cases (such as during upgrades, for example).

We built this feature in 2013, and I don’t even think there was a guideline #8 at all at the time. (The Internet Archive’s Wayback Machine seems to not be showing history from before 2015 right now. I know they have been going through major updates lately.)

  • When guideline #8 was first introduced, even with the earlier version of the guideline, we questioned if our update code was now breaking the guideline.
  • We asked members of the plugins team if our code was in violation and what to do about it.
  • We were told that trusted plugins, which were running updaters like ours before the guideline was introduced, would be allowed to continue to operate as they had been before. 

Paid Memberships Pro was not the only plugin with this exception. In fact, WooCommerce, which was later acquired by Automattic, updated their paid extensions through a similar process, and in fact still do.

At various times, as the text of guideline #8 was updated, and recently when the plugins team volunteers turned over, I inquired about this guideline and how we should handle it. As recently as WordCamp US in Portland, September 17-20th, I was told by a member of the plugins team that the team was aware of plugins breaking the guideline, that clarification would come later this year, and we’d have time to update our plugin to comply.

My understanding, before we decided to close our plugin in the repository, was that we were breaking this guideline, but it was unclear what the proper remedy was, and that was okay because we were trusted to not abuse the updater code.

In all cases like this where applying the plugin guidelines is unclear, we had a saying (I think common within the community): “Do what Automattic is doing.” It’s not a secret that many changes to the plugin guidelines were done to allow Automattic plugins to operate as they needed to or to address the strategic objectives of Automattic. So we felt that as long as we were doing things the way plugins like WooCommerce were, we were in compliance.

Again, WooCommerce included similar update code to Paid Memberships Pro (we all worked off the same tutorial back in the day). In March 2024, WooCommerce introduced their update manager plugin. According to this post on the WooCommerce developer blog, the update manager was released “to better align with WordPress.org’s guidelines.”

The release of the WooCommerce Update Manager prompted me to “do what Automattic is doing” and follow suit with an update manager of our own, but when I looked into the WooCommerce Update Manager code more closely, I realized that the update code wasn’t even removed from the core WooCommerce plugin. The code is still there, it is just enabled by the update manager. The update manager plugin has relatively few lines of code, which simply turns on the dormant update code inside the core WooCommerce plugin.

Does this really adhere to the spirit of guideline #8?

Maybe. Maybe not. It wasn’t clear to me, so I shelved the project to release an update manager of our own, and planned to talk to the plugins team in person next chance I got.

All plugins require a level of trust.

It’s important to remember how plugins work. WordPress runs PHP on the server and controls all aspects of the website. With relatively few exceptions depending on how the server is set up, that PHP code can do whatever it wants. WordPress plugins also run PHP on the server and can do whatever they want.

Plugins hosted in the WordPress.org plugin repository, however, are not allowed to do whatever they want. Plugins submitted for inclusion in the repository must comply with the Plugin Guidelines. These guidelines prohibit things like obfuscating code, trialware, adding spam to the site, and tracking users without their consent.

In many cases, it is clear when a plugin is breaking the guidelines. For example, inserting hidden white text on white background or inserting links to your own site for SEO reasons. These two cases are definitely spam and definitely against the guidelines.

But, what about inserting a “powered by X” link underneath some form or some frontend content your plugin adds? I forget exactly where the community has landed on these things, but I think it’s something like “Links are okay when done in a tasteful way, with a ‘nofollow’ attribute, and modest presentation. These links adhere to the guidelines.”

And so following the guidelines involves trying to understand the spirit of the guidelines, as mentioned at the top of the guidelines page:

While we attempt to account for as many relevant interpretations of the guidelines as possible, it is unreasonable to expect that every circumstance will be explicitly covered. If you are uncertain whether a plugin might violate the guidelines, please contact [email protected] and ask.

To review:

  • WordPress plugins run PHP code on the server. That PHP code can do whatever it wants.
  • Plugins in the WordPress.org repository face a higher bar to clear, namely the plugin guidelines.
  • The guidelines cover many gray areas that require interpreting the spirit of the guidelines.
  • Those interpretations, and the written guidelines themselves, change over time.
  • And so there is a level of trust required between a plugin author and the community to host a plugin in the WordPress.org repository.

Answers To Questions You Might Be Asking

The rest of this post aims to answer other questions you might have about this decision and the stability of the Paid Memberships Pro platform.

Is the plugin still safe and secure if updates don’t come from WordPress.org?

Yes. Our developers will continue to maintain our plugins with a strong emphasis on security. We will continue to use the same standards as we always have, including running the Plugin Checker Plugin that the .org plugins team uses to scan plugins inside their directory.

Will this change impact the plugin’s features or functionality?

In the short term no. In the long term, we will have more freedom to build the software out in a direction that should benefit our core users.

Internally we have been talking about this change as moving from a company that builds a WordPress plugin to a company building a membership platform that happens to run on WordPress. It’s a subtle shift in mentality, but one that will lead to new exciting possibilities for our users as we take more responsibility to deliver for our users exactly how they need.

Does this mean Paid Memberships Pro will cost more or have fewer free features?

All of the code we distribute, including the full core Paid Memberships Pro plugin, will continue to be 100% freely available here on our site and GitHub.com.

How will moving off WordPress.org affect compatibility with WordPress, plugins, and themes?

All existing compatibility with other plugins will work as expected. Over the long term, both ourselves and other companies will make different decisions about which integrations we choose to spend our development time on.

Paid Memberships Pro has always benefited from having a larger number of third party integrations with other services and plugins as compared to many other membership plugins. This may have been partially because our plugin was available in the .org repository. So in that way, some services and plugins may feel less inclined to integrate with Paid Memberships Pro.

What isn’t changing is the fact that our core plugin is 100% free, more fully featured than any other membership option for WordPress, and easy to find and work with on GitHub.com. We believe these latter features are what really draw third party services and plugins to build integration for our platform.

Will this affect support for the plugin?

The only change is that you will no longer be able to get support from us from the WordPress.org site. For now, the support forum is still live and active on WordPress.org, but our team will no longer be looking in there or replying.

We will continue to provide a superior support experience through our contact form, our premium support, or through our community Slack.

What if I currently have the plugin installed from WordPress.org?

Even if you installed Paid Memberships Pro from the WordPress.org repository in the past, it will still have the code required to update from our servers ongoing. To make sure you get official updates from us, even if Paid Memberships Pro is inactive, you should download and activate our PMPro Update Manager plugin, which can be found on this site or GitHub.com.

Is this a common move for premium plugins?

This seems fairly unprecedented, at least until this past month. Most plugins that were ever closed in the .org repo were abandoned or otherwise not in heavy use. This seems to be the first time several plugin authors, including ourselves, are choosing to close our plugins ourselves. It doesn’t seem like the .org repository has procedures to account for this. I’m hoping that they just let us leave without further disrupting our users.

Your Trust is The Most Important Thing

We know that you have placed a huge amount of trust in us. You’ve chosen to build your business with our platform. We do not take that trust for granted.

We know that, for the most part, people who choose Paid Memberships Pro are building their business on their own. We want you to be wildly successful, whether that’s financially successful or another meaningful mission (or both). This is why we continue to do the work that we do and why we approach it with such earnest dedication.

Kim and I are here to answer any questions you have about this post, this decision, and anything at all that you may be concerned about. Please reach out via our contact page and we will get back to you individually.

We will continue to update this post if any questions come in that need to be addressed publicly.

Cover image from ebook 29 Nuggets of Wisdom Volume 1 - Sample Collection

Download the free ebook: Get 29 insights and ‘aha moments’ for new or veteran membership site business owners. Use these nuggets of wisdom to inspire or challenge you.

Was this article helpful?
YesNo