PMPro Update 2.10: Setup Wizard, Detect URL Changes, Stripe Checkout, Restrict by Tag

Version 2.10 of Paid Memberships Pro is out. This version includes a Setup Wizard for new sites, the ability to restrict posts by tag, and the release of “Stripe Checkout” and the “Stripe Customer Portal” as options for sites using Stripe.

We have also added better detection for primary site URL changes to help sites prevent unwanted behavior on staging or development sites.

You can update Paid Memberships Pro from the plugins page of your WordPress dashboard or get the latest version of PMPro here.

Read on for the full list of new features and the entire v2.10 changelog.

Setup Wizard for New Sites

New membership sites can now use the Setup Wizard to quickly set up PMPro and begin accepting new member registrations within minutes. The wizard performs the key setup steps for Paid Memberships Pro, including setting up your first free and paid level (both optional) and reviewing advanced settings related to content filters and spam protection.

Detecting Primary URL Changes

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.

There are some weird edge cases where the notice may appear for sites who were testing out a pre-release of this feature in Paid Memberships Pro. If you see the notice and are confident that your site URL has not changed (the site URL matches the URL output in the notice), you can safely click the button to resume all services and the notice should not return.

Enhanced Protections Around Deleting Data

v2.10 also added clearer warnings and a few forced admin interactions to confirm changes before we make a update that could trigger unwanted changes. These safeguards include:

• Deleting Membership Levels: This update changes what happens when you delete a level from the Memberships > Settings > Levels screen.
  • We no longer cancel all of the subscriptions (at the gateway) associated with a membership level upon deleting it.
  • Instead, you should cancel members individually, before deleting the level.
• Deleting a User: This update changes what happens when you delete a user from the Users screen in the WordPress admin.
  • In previous versions, we showed a warning message that the member’s subscription would be canceled at the gateway, and that their membership would be canceled on the site.
  • Some people overlook this message.
  • This update adds a checkbox that the admin must confirm to also cancel active subscriptions and delete member history for that user.

Stripe Gateway: Offsite Checkout, More Payment Methods, Customer Portal

v2.8 of Paid Memberships Pro added Stripe Checkout as a “beta” gateway option. In v2.10, this gateway option is completely out of beta and now available to any site using Paid Memberships Pro.

Stripe Checkout is a Stripe-hosted, prebuilt payment page that simplifies the process of collecting payments from users.

In addition to accepting credit card payments, Stripe Checkout also gives users the option to use other payment methods, such as bank debits, as well as Stripe Link.

Stripe Checkout integrates with Stripe Tax to calculate sales tax, VAT, and GST during the payment step. For business owners, this service simplifies the process of filing and remitting taxes.

For Billing Information updates, our Stripe gateway now includes the option to use the Stripe Customer Portal. This portal redirects active members to update their billing info directly in Stripe. The Stripe Customer Portal is a Stripe-hosted page that allows users to see active subscriptions, update billing and tax ID information, and view or download previous invoices (does not include one-time payments). In order to use this feature, you must first enable it in Stripe.

Learn more about using Stripe Checkout for your membership site in the documentation here.

Stripe Gateway: Webhook Status Report

We also added a Webhook Status report on the Stripe gateway settings page. This report gives sites confidence that they have properly configured the Stripe gateway. It will also help sites identify where to look if there is an issue with processing data from the gateway.

Protecting Content by Tag

Paid Memberships Pro always included a way to protect content by post category. With v2.10, you can now also protect content by post “Tag”.

To protect a tag, navigate to Posts > Tags in the WordPress admin. Select a term to edit and adjust the “Require Membership” setting.

Full Changelog for v2.10

• FEATURE: Added Setup Wizard
• FEATURE: Fully released Stripe Checkout and Stripe Customer Portal integrations. Increased Stripe fee to 2% for newly connected sites.
• ENHANCEMENT: Now “pausing” some PMPro functionality when the site URL changes.
• ENHANCEMENT: Restrict categories and tags by level directly from their respective settings pages.
• ENHANCEMENT: Updated Stripe webhook checker to check each event type separately.
• ENHANCEMENT: Admins will now be given the choice to delete a user’s membership history when deleting a user.
• ENHANCEMENT: Stripe Checkout now creates Invoices for one-time payments.
• ENHANCEMENT: Updated Stripe library to version 10.0.
• ENHANCEMENT: Excluding more dev/staging-related subdomains and TLDs from Wisdom tracking.
• ENHANCEMENT: Added the add class attribute to the “rate us” notice in the footer of PMPro pages. You can use this to hide the notice.
• BUG FIX/ENHANCEMENT: WordPress users will now be created before payments are charged at checkout.
• BUG FIX/ENHANCEMENT: No longer cancelling subscriptions for users with a membership level when the level is deleted.
• BUG FIX/ENHANCEMENT: Removed the “What’s This?” text from the CVV field.
• BUG FIX/ENHANCEMENT: Fixed error thrown if all pmpro_reports were unset.
• BUG FIX/ENHANCEMENT: Fixed localization issues with the Members List table in the dashboard and several other areas.
• BUG FIX/ENHANCEMENT: Fixed issue where usage tracking was disabled, even if you clicked the “allow” button in the notice. Double check that this is set how you would like at Memberships > Settings > Advanced Settings > Enable Tracking.
• BUG FIX: Fixed issue where “Visits, Views, and Logins” report may not show up on some setups.
• BUG FIX: Fixed issue where invoice emails were not sending due to issues with the pmpro_get_order_json() function.
• BUG FIX: Fix for fatal error on site health check page if login/password is required for ftp account. (Thanks, @freax on GitHub)
• REFACTOR: Deprecating CyberSource and PayPal Website Payments Pro gateways.
• REFACTOR: Marking “trial ending” cron as deprecated.
• REFACTOR: Removed the ability to direct access the scripts in the /crons/ and /services/ directories. Only the getfile.php script can be accessed this way when activated.

Important Notes About PMPro v2.6.10

This update fixes an issue where sensitive customer information may have been stored in the checkout_request_vars order meta that PMPro stores at checkout when using the Stripe gateway with the offsite checkout option.

This issue seems to only have affected a small number of sites with specific configurations. Even so, this update is shipped with code to detect and repair the issue. The information here will help you to tell if this issue affected your site, what to do if it has, and how this issue happened in the first place.

How can I tell if my site was affected?

First, note that this issue will only have affected sites that are using the Stripe gateway, and only if you are using the option to process checkouts “offsite with Stripe Checkout”. If you are not using Stripe or not using the Stripe Checkout option, then your site was not impacted by this issue.

Further, there are only a couple of cases that we know of where PMPro would have incorrectly stored sensitive information at checkout.

(1) Sites that are using the Sponsored Members Add On and the sponsored_accounts_at_checkout option in the sponsored level settings may be accidentally storing the plaintext child account passwords in order meta.

(2) Sites that are using an out of date custom checkout page template, perhaps as part of a theme coded to support PMPro, may be accidentally showing the credit card fields at checkout even though checkout is configured to process at Stripe. In cases that we can’t reproduce, these extra credit card fields, if they aren’t breaking the checkout process entirely, may get stored in the checkout_request_vars order meta accidentally.

If you aren’t using Stripe, aren’t using Stripe Checkout, aren’t using Sponsored Members with the option to create child accounts at checkout, and aren’t using an outdated custom checkout template, then your site would not have experienced this issue.

Still, this update checks the order meta on all sites to see if any sensitive information was accidentally stored and if found, starts a process to scrub the sensitive data from the database. If such sensitive data was found (anything that looks like a password, or anything that looks like an unmasked credit card number) then you will see a notice upon upgrading to PMPro v2.10.6.

You can also navigate to Tools > Site Health > Info > Paid Memberships Pro in the admin dashboard and look for a section labeled “Cleaned Fields”. If you don’t see that label, then PMPro did not detect any issues on your site. If you do, it will contain information about what was found.

What should I do if my site was affected?

Again, this update will automatically scrub the sensitive information from your database. If there are more than a few orders like this on the site, it will prompt you to run an “update script”. You should run this from the WP admin dashboard.

If you are sure, by checking the PMPro section of the Site Health info, that your site was impacted by this issue, then you should consider the following:

1. Consider addressing any staging site or database backup that may contain the same sensitive information. You can (carefully!) discard your staging site and recreate a new one from the live site after the data has been scrubbed. You can (carefully!) make a new backup of your database after scrubbing the data and deleting any old backup that contains copies of the sensitive data.
2. Consider removing the checkout_request_vars order meta from your databases entirely. These values are only needed during checkout before the initial payment or subscription setup has fully processed. You can safely remove the user meta after that point (and we may do that in the future anyway). To do so, you can (carefully!) run the SQL query here once on your live or backup databases. Note however that any checkout currently in process will fail if the request var data is removed. You could limit the query to orders within a timeframe or ones that include AccountNumber in the meta_value or some other indication of sensitive data.
3. Consider contacting any user whose data was incorrectly stored this way. We cannot determine if this is the correct course of action for your business and website, but if others potentially had access to this data or you have other legal requirements, you may want to disclose this to your users. To find the users impacted by this issue, export your orders to CSV from the Memberships > Orders page in the dashboard. Then check for a cleaned_data_2_10_6 column and scan or filter for any order that includes data in that column.

How did this happen?

Paid Memberships Pro has an action hook pmpro_after_checkout that is used by Add Ons, other plugins, and custom scripts to perform actions after checkout. Typically this hook fires onsite when the checkout form is submitted. With the offsite “Stripe Checkout” option for the Stripe integration, users are taken away from the WordPress site, and the pmpro_after_checkout hook actually fires while processing the webhook Stripe sends later after the payment is processed.

So, when using Stripe Checkout, the pmpro_after_checkout hook is run in the background on the server. To make sure checkouts that happen on site are the same as checkouts that happen at Stripe and are later finished via webhook, we store all of the fields at checkout into order meta and make them available to the webhook processor. This process was already coded to ignore sensitive fields at checkout like the user’s password or their credit card number, but in the few cases described above, these precautions were not enough to stop some sensitive data from being captured at checkout.

This latest update has further precautions to prevent this from happening in the cases described above or in other cases that may occur. If you have any questions or information about this issue, please contact us. As we learn more, we will share with our users.