Important Changes for MemberMouse 3.0 – READ THIS FIRST

MemberMouse 3.0 represents a major evolution of our platform towards key WordPress standards and conventions. Immediate benefits include improved performance, security enhancements, and greater flexibility in subscription billing for card-on-file payment methods. We also introduce core technologies, such as an event queuing system, remove dependencies on centralized infrastructure, and modernize our data storage format.

These changes are fundamental to the operation of the plugin. For this reason, downgrading back to MemberMouse 2.x is not supported. Please be sure to perform a full backup before upgrading, and we suggest testing the upgrade in a staging environment.

The purpose of this article is to acquaint you with some of the important changes to the plugin, and to provide guidance on the upgrade process.

Staging Environments

A staging environment allows you to test changes before you perform them on your production site. Ideally, it will closely mirror your production site, but will not contain real member data. However, most systems for creating staging environments merely copy the production site, including all member data. This introduces the possibility that unwanted subscription billing could occur.

Your very first step when installing MemberMouse 3.0 into a staging environment should be to confirm that you have a valid staging license configured with the correct URL. The presence of this license is a key protection against unwanted billing. You can check your existing licenses in the Account Settings page of our website. A staging license looks like this:

Note the words Active, Staging in the license type, and the URL. If the displayed URL does not exactly match the URL of your staging site, you can click Edit to change it. If you don't see a staging license and would like us to create one, please Request a Staging License. Each staging site requires it's own license.

Advanced users and developers seeking additional protection, please see our article on Production Databases Copied to Staging Sites, which describes how to remove scheduled rebills and card-on-file information. These steps must never be performed on a production site.

Once you have installed MemberMouse 3.0 on your staging site, it's recommended that you visit MemberMouse > General Settings > Other Settings, and disable the local billing scheduler. This setting is found near the bottom of the page.

Finally, it is essential that under no circumstance should data from a staging environment be used to overwrite an already-live production site, or “pushed” to production. Staging environments are exclusively for testing activities that will ultimately be performed directly on the production site. Overwriting the production environment with data from staging will cause data loss.

Local Billing

For card-on-file payment methods like Stripe, Braintree, and Authorize.NET CIM, previous versions of MemberMouse handle subscription billing by using a central server that prompts your site to perform rebills.

Going forward, rebilling for these payment services will be handled completely within your site. This allows us to provide additional subscription management features: you can now rebill a subscription immediately, change the rebill date arbitrarily, and skip to the next rebill in the series.

Additionally, this change eliminates your reliance on our centralized infrastructure for subscription rebills using these services, which historically has been a matter of concern for some customers.

Handling billing locally requires that your server reliably execute scheduled tasks, through a system known as WP-Cron. Before upgrading to MemberMouse 3.0, please ensure this process runs reliably:

• Triggers – Most modern hosting providers trigger WP-Cron periodically using the underlying server. If your hosting provider does not offer this, consider using an uptime monitoring service to periodically trigger your environment to run scheduled tasks. WP-Cron should not be disabled in your wp-config.php file
  
• Performance Plugins – Some performance optimization plugins reduce the frequency WP-Cron runs at, or disable the service entirely. These features should be disabled.

Local billing maintains all scheduling information in the database of your WordPress site. This means that restoring a backup of your site returns the schedule to a previous state. If any subscriptions have billed since the backup was created, restoring the backup queues them to run again. We have introduced a number of features to discourage and manage this scenario, but some changes to your workflows for maintenance and disaster recovery are recommended.

Please see our article describing How MemberMouse Handles Recurring Billing for more information.

Legacy Stripe Integration

In 2019, we introduced the Stripe Elements integration, which provides enhanced security and implements Strong Customer Authentication (SCA) in locales that support it. This integration also offers PCI-SAQ A compliance, which massively reduces your exposure to audit requirements. Shortly after, Stripe Elements became the default for all new MemberMouse customers, and most existing customers have already switched their integration mode.

With MemberMouse 3.0, we are removing the ability to perform new transactions using the legacy Stripe.js integration. When you upgrade, the integration mode will be automatically switched to Elements.

If you are using Stripe as your payment method, you can determine whether you are using the legacy integration by visiting MemberMouse > Payment Settings. If the checkbox Enable Stripe Elements is marked, you have already been migrated, and you may skip the remainder of this section.

The primary difference between the legacy integration and Elements is the way that credit card information is collected. In the legacy integration, MemberMouse created the credit card fields, but in Elements, Stripe creates them using embedded frames, which is significantly more secure.

The customer-facing impact is that Elements fields do not inherit styling information such as length and width from the checkout page, so they may appear different from the rest of the form. Please see our article on Enhanced Stripe Elements Styling Options for more information.

Customers still using the legacy Stripe integration may find it helpful to enable and test Stripe Elements on their existing version of MemberMouse, and address any display issues, prior to upgrading to MemberMouse 3.0.

Database Upgrade

When you upgrade an existing site to MemberMouse 3.0, the plugin will display an administrative notification prompting you to perform a database upgrade:

This process will change the prefix on MemberMouse tables to match your WordPress installation. It's expected that this will improve compatibility with various third-party plugins and automated maintenance systems. Please perform a full backup of your site before proceeding with the upgrade.

When you click the link, the database upgrader will be displayed:

Optionally, you may select to change the collation of MemberMouse tables. This changes the format in which MemberMouse stores data, and allows it to support a much larger set of characters, such as emojis, symbols, and ideographs.

We generally recommend selecting this option. The collation used by previous versions of MemberMouse is deprecated, meaning that the software powering your database no longer receives updates for it, and support for it will eventually be removed. However, there are a few important considerations:

• Changing collation requires your database fully support utf8mb4. We recommend MySQL 8 or MariaDB 10.6+ for use with MemberMouse
• During the process, database performance will likely be degraded. For the majority of customers, the migration will take no more than a few minutes, but could take longer if the database is very large or already experiencing performance problems
• The Activity Log is cleared when the collation is changed. This is a record of user activity, showing logins, page views, and so forth. The access rights of members and their transaction history are not impacted

Customers with very large, busy sites should coordinate with their development teams, and consider whether performing the collation change manually is the preferred solution.