How to Set Up a Staging Environment to Test Changes and New Features for Your Membership Site

Running a membership-based business online requires constant innovation and the ability to quickly respond to member needs. If you are operating a mature, public membership, it can be difficult to properly test, develop, and release new features. Enter the staging site.

This article aims to explore the best practices and mandatory rules you must follow when setting up a staging site for your membership business.

Staging Sites: Use Extreme Caution

A staging site is a non-public version of the code that powers your live membership site. Your membership’s staging site, if set up properly, will allow you to add and test new features before releasing them on your live site.

When setting up a staging site for a transactional ecommerce site, like a membership site, you need to be extra cautious.

Whether you have a staging site already or are just considering setting one up, the steps below outline the best way to ensure your staging site does not do any of the following worst-case scenarios:

• Your staging site cancels real member subscriptions at the gateway.
• Your staging site ‘member’ data overwrites the live site, removing all new members (and their data) that have joined since the staging site database clone was created.
• Your staging site data overwrites all the recurring order data for real members in your live site.

Imagine how awful it would be to find yourself in any one of these scenarios. Please read the steps below and follow them exactly.

Setting Up a PMPro Staging Site: Step-by-Step

The steps below will take you through an entire staging site setup. Some web hosts have “magic” staging site clone buttons.

• If you choose to use that process, you must still follow the steps below as they relate to scrambling member data, disconnecting your live gateway credentials and more.
• It is best to avoid any automatic processes to create a staging site and instead follow these steps one-by-one.

Before you go down this path, I want to share that all of us at Paid Memberships Pro (especially Jason) do not believe in database syncing for development membership sites.

• A database sync is a setup where the staging site database stays linked and “up to date” with your live site.
• While this approach is fine for a content-driven site, there are too many custom tables at play in a membership site running Paid Memberships Pro.
• Syncing data across a live and staging site is not just syncing post content. It involves syncing users, user meta, custom membership tables, options tables, and more.
• We do not recommend attempting this.

Establish Your Goals for the Staging Site

The goal of your staging site should be focused on testing: to test new code recipes, new features, new plugins, plugin updates, and more.

These types of tests do not require a sync between your live and staging data. Yes, there may be some additional work when you have a feature ready to launch.

You may need to create new pages or posts on the live site; you may need to match settings and configuration from a staging site plugin admin to the live site plugin admin.

For the average WordPress power user, the time it will take to launch and replicate settings from staging to live is small when compared to the thought of losing your live site’s member and order data.

Pause Mode for Safer Staging Site Setup

Paid Memberships Pro v2.10+ includes a new feature to detect if the primary URL of your site has changed. When the plugin detects a change, automated services such as WP-CRON are automatically disabled. “Pause Mode” is automatically triggered when we detect a URL change. For more details on pause mode and the services that are disabled, refer to the documentation on Staging and Development sites here.

How to Set Up a Membership Staging Site

1. Create a backup your wp_content folder from the live site.
2. Create a backup of your live site’s connected WordPress database.
3. Set up a fresh WordPress installation at a subdomain or unique IP address in your web hosting account. This is now your “staging site”.If you do not want to set up your staging site on the live server, you could also set it up in a local development environment like Local by Flywheel, Desktop Server, or MAMP.
4. If you set your site up on a public server, it could be discovered and even indexed by a search engine. We recommend using basic authentication to block the site. For an Apache server, try following these docs provided by the hosting company Digital Ocean. Whether or not you are hosting with them, the process will be somewhat similar. NGINX has a doc for setting up basic authentication here.Once basic authentication is set up, if someone discovers your staging site URL, they will be prompted to enter a username and password to get to the site. This username and password exist at the server level (outside of WordPress), and adds one more layer of protection for someone potentially accessing your staging site.
5. You can also use a “maintenance mode” plugin or other “development mode” setting in the staging WordPress site. This approach tends to interfere with running real tests for member and non-member features. For this reason we recommend using server-level basic authentication instead.
6. Replace the “staging site” wp_content folder with the backup you took in step 1 from your live site.
7. Replace the “staging site” database with the backup database from your live site. You can load your database backup to a new table in your host’s phpMyAdmin interface, then update the wp-config.php file of the staging site WordPress install to point to the copy of the database.
8. Run a series of SQL commands to search and replace any urls from the live site with that of the staging site. You can use a tool like this Database Search and Replace Script to handle the commands or do it yourself via custom SQL commands.
9. Install and activate the Developer’s Toolkit Add On for Paid Memberships Pro.
10. Deactivate Email on the staging site. There are two recommended methods to disable email on your staging site. You can use the Developer’s Toolkit Add On email rerouting feature under Settings > PMPro Toolkit. This will send any email that would have gone to your member to the designated email address.Another method would be to scrub all user data. This can be done via an automatic script in the toolkit under Tools > PMPro Toolkit Scripts. You can even do both.
11. Disable scheduled scripts that run daily via WP CRON. You can do this by checking the appropriate box on the Tools > PMPro Toolkit Scripts admin page. This will stop the server from processing member expirations or sending recurring payment reminders and payment method expiration notices.
12. Scramble Subscription and Transaction IDs. Another feature of the Developer’s Toolkit under Tools > PMPro Toolkit Scripts will scramble transaction IDs. This is one additional protection to help you ensure that live member subscriptions will not be affected by your staging site.
13. Remove API keys, email addresses, passwords, and more from the Memberships > Settings > “Payment Gateway and SSL” admin page. You can optionally set this up with a different set of API keys created exclusively for your staging site or disconnect the gateway completely.Once you have deleted your live gateway API credentials, you can consider setting up a connected gateway in the “Staging/Testing” mode. This is only needed if you would like to test payments on the staging site. Note that a staging site protected with basic authentication (username and password at the server level) will block certain tests with your gateway.
14. If you were using the Add PayPal Express Add On, make sure you also remove the stored API credentials for this gateway by changing the “Gateway” dropdown to “Paypal Express” and removing the saved fields. You can then save the gateway settings, toggle back to your preferred “primary gateway”, and save the settings again.

Staging Sites: An Intentionally Specific Process

Setting up a staging membership site is not a simple task. These 12 steps cover the process at a very high level—and chances are that some of the steps have left you a bit confused. It will require an experienced WordPress developer to properly set up your staging site if you would like to migrate any live member data or settings from production to staging, even just once when you create the staging site.

We can provide some high level guidance on setting up a staging site in our member support area, but please remember that having a skilled developer in your own team is the safest way to make sure you do it correctly.

Moving Code Changes From Staging to Production

A proper staging site allows you to test new plugins, plugin upgrades, custom recipes, and more. But what do you do once you are happy with where the changes are at?

One method to move changes live is to overwrite specific folders from the live site with the “updated” version from your staging site.

Since we are primarily using your staging site to test code changes (plugin or theme updates and custom code added to your site), advanced developers can consider setting up git repositories for specific custom plugins or themes.

“Git” is a version control system that allows you to make changes to code, maintain a log of what user made the change, commit and push changes from one location to another, and, if needed, roll back changes to an earlier release if things go haywire.

There are two methods you can consider when using git for version control in a “staging to production” model: create a private repository on GitHub, GitLab, or BitBucket or create a “bare” git repository on your own servers.

You don’t need to track changes for every single folder in your WordPress site—just the folders you expect to do most of your changes in. We use bare repositories on our own servers to track a few customization plugins as well as our child theme for the main Paid Membership Pro site.

Both methods (manually moving folders or using git) may require you to update settings in the live site after launching the changes. While there are methods for moving WordPress options, posts, pages, and other data from a staging site to a production site, we recommend updating settings and recreating posts and pages manually.

Most plugins and tools to copy data from a staging site to a live site are not savvy enough to avoid overwriting transactional order and user data created by plugins like WooCommerce or Paid Memberships Pro. If you were to push data from your staging site database to your live site database, you could overwrite important member or order information by accident.

If you have a lot of post and page content that you want to work on in staging and move to production, or you cannot afford a few hours of downtime during your transitions, a really good (and well paid) WordPress developer would be able to help to do such a database migration for you with limited downtime.

As far as we know, there is no simple solution for moving data from staging to production on ecommerce sites. Many smart minds and well-funded companies have tried to solve this problem in a user friendly way, but none have succeeded yet. We will be sure to share such a solution if something comes along.