Version 3.0 has been in the works for almost a year and we’re thrilled to finally have the first beta release available for testing. Most notably, version 3.0 introduces custom database tables for memberships and customers, a batch processor to migrate data, payment plans, and much more. This update is particularly exciting because introducing custom tables lays the groundwork for our next big project: adding support for multiple memberships per user.

How to test the beta

In order to help ensure the final release of 3.0 goes as smoothly as possible, we need your help testing this beta version.

Testing the beta is very simple. Simply log into your testing site that has Restrict Content Pro installed and activated and navigate to Restrict → Settings → Misc and check the box for Opt into beta versions:

The beta update will now be available as a standard WordPress plugin update from your Plugins page, though it could take up to a few hours for the notification to appear.

See our FAQ if you have any questions or issues updating to the beta version. If you encounter any bugs, please let us know through our support page.

Note: we do not recommend you test the beta on a live site. Use a testing site. While we do our very best to not cause issues during updates, sometimes issues do slip through unnoticed, so having a staging / testing site is very important.

New PHP requirement: version 5.6 or higher

Version 3.0 now requires PHP version 5.6. This will allow us to upgrade some of our third party libraries, such as the Stripe library, and give us more flexibility in the future. Please make sure you’re using PHP 5.6 or greater before updating to 3.0.

Custom tables for memberships and customers

Previously, all membership data was stored as user meta. This has worked fine for simple, single memberships, but is not feasible for some exciting changes we have in mind for the future. As such, membership data is now stored in two new tables with the following columns:

wp_rcp_customers

  • id
  • user_id
  • date_registered
  • email_verification
  • last_login
  • ips
  • notes
  • uuid

wp_rcp_memberships

  • id
  • customer_id
  • object_id
  • object_type
  • currency
  • initial_amount
  • recurring_amount
  • created_date
  • trial_end_date
  • renewed_date
  • cancellation_date
  • expiration_date
  • payment_plan_completed_date
  • auto_renew
  • times_billed
  • maximum_renewals
  • status
  • gateway_customer_id
  • gateway_subscription_id
  • gateway
  • signup_method
  • subscription_key
  • notes
  • upgraded_from
  • date_modified
  • disabled
  • uuid

Once the 3.0 update is installed, you will be shown a prompt to migrate your membership data from user meta to the new tables. These tables give us more speed and flexibility with querying, sorting, and searching membership information.

We also have new admin interfaces for managing customers and their memberships.

Membership details UI

With new tables, we also have new classes: RCP_Membership and RCP_Customer. The old RCP_Member class and associated helper functions have been deprecated, but they are fully backwards compatible.

Payment plans

Payment plans have been a popular request by customers wanting to give their members the option of paying the full amount upfront, or paying the amount in instalments over the course of several months. If your membership content is more expensive and normally a one-off payment, it may be easier for some customers to pay smaller amounts over a greater period of time.

This feature introduces the ability to set a maximum number of renewals for membership levels, along with an “after final payment” action. As an example, you can create a membership level that is $100 per month and is limited to three renewals. This is a total of four payments (initial payment of $100, plus three renewals of $100 each). After the final payment, the subscription is cancelled and the customer is given lifetime access to the content. This might be an alternative to charging a single amount of $400 upfront.

Payment plan with 3 renewals

Restrict content to multiple user roles

The post restriction metabox now allows you to select more than one role when using role restriction. Instead of just allowing access to “editors”, you can choose to allow access to “editors” and “contributors”.

Select multiple roles in the "restrict this content" metabox

The [restrict] shortcode also now supports custom roles in the userlevel attribute. In the past, it only supported the built-in roles such as admin, editor, contributor, etc. Now you can enter a custom role, such as “shop_vendor”, or even a comma-separated list of multiple roles. For example:

[restrict userlevel="shop_worker,shop_vendor"]

One restriction message

Previously there were two restriction message settings: Free Content Message, and Paid Content Message. In 3.0, we’ve merged these two into one single “Restricted Content Message”. As restriction settings get more complex, so does figuring out whether content is free or paid. If you allow members of a free level to access Post A, but also let members of a paid level access Post A, is Post A free or paid? Which message should be used? What about if you restrict Post B to access level “4 or higher”, but there are both free and paid membership levels that grant that access level? This has caused confusion for many of our customers, and having one single restriction message brings more clarity.

Upon upgrading to 3.0 you’ll be asked to confirm your new “Restricted Content Message” setting.

The restriction message does have a filter, rcp_restricted_message. You can use this if you want to add custom code to once again create separate messages for free vs paid content.

Additional improvements

    • “Subscription Levels” have been renamed to “Membership Levels”.
    • Added a batch processing API.
    • Memberships can now be sorted by expiration date.
    • The Stripe API library has been updated.
    • The “Email IPN Report” feature has been removed.
    • Our login functions now use wp_signon(). This allows greater support for third party plugins that integrate with the login system, such as Jetpack Protect.
    • The invoice template has been expanded to include fees, discounts, and credits that were applied to that payment.
    • The “Auto Add Users to Level” setting has been added to the system info file.
    • The PayPal Express confirmation screen has been updated to include additional information, including discounts, fees, and credits.
    • The login link text in the registration template has been adjusted.
    • object_id is now supported in RCP_Payments::count().
    • Improved error messaging when adding/updating membership levels fails.
    • Original join dates are now stored (in the wp_rcp_customers table).
    • “Prevent Account Sharing” setting now accepts a maximum number of simultaneous connections.
    • When a user account is deleted, associated recurring subscriptions are now automatically cancelled.

Notable bug fixes

  • Password reset links will now work with SendGrid click tracking.
  • RCP user meta is now removed during uninstall.
  • The payment_id column name in the wp_rcp_payment_meta table has been renamed to rcp_payment_id. This fixes a conflict with the Give plugin.
  • The admin bar is no longer hidden for users who have the “edit_posts” capability.
  • Under certain circumstances it was possible for rcp_get_ip() to return a CSV of IP addresses instead of a single IP.
  • Databases are now registered when switching sites on multisite.
  • Fixed a DateTime::__construct() fatal error in Authorize.net when signing up for a free trial.
  • In the wp_rcp_payments table, the following column types have been updated: id (now unsigned), object_id (now unsigned), user_id (changed from mediumint to bigint(20) and now unsigned).

Modified templates

The following template files have been edited. If you’ve overridden these, please compare with our changes to ensure your files continue to work as expected.

  • card-update-form.php
  • invoice.php
  • paypal-express-confirm.php
  • register.php
  • register-single.php
  • register-total-details.php
  • subscription.php
  • woocommerce-single-no-access.php

Release date for 3.0

The beta version of 3.0 is available today and we hope to release the final version on or near the 29th of January, 2019.

Ashley Gibson

About the author: Ashley is a developer, tester, and support team member at Restrict Content Pro. When not working on Restrict Content Pro, she enjoys weightlifting and reading.

31 comments

  1. Very interesting news!
    I’ll test the new beta 🙂

    In other hand, I was wondering if you plan to do any changes related with the new WordPress editor, such as, a dedicated block or similar.
    If I’m not wrong EDD recently added blocks, right?

    ¿Any plan in that direction?

    Thanks!

    1. We do have plans for Gutenberg blocks! We don’t yet have an ETA on them but they’re definitely coming!

      Let us know if you run into any issues or questions with the beta!

      1. Cool!
        Thanks for the quick reply.
        I’m really curious about how are you gonna build the blocks. Specially, if there will be any option to transform existing shortcodes into a block.

        Keep us posted 🙂

        Cheers.

    1. Yes those will still work in exactly the same way! But just to clarify: those are used to check if the current user is free/paid — not if the current post is.

    1. The REST API add-on will work exactly the same way it does now. Everything is fully backwards compatible. In the future we will add new endpoints for customers and memberships, but until then the members endpoint still functions the same way it does now.

      Of course we would recommend testing your integration fully and that way if there is a problem we can become aware of it and fix it before release. But we’ve also done our own testing to ensure everything still works the same in 3.0.

  2. Does this mean that we’ll be able to get an output list of all active member names? We’d like to create a member directory type of page, and it would be great to be able to dynamically list all active/paid member names.

    Thanks!

    1. You could certainly use the new rcp_get_memberships() function to get an array of all the active memberships. This would give you an array of RCP_Membership objects. It’ll take a bit more work to get from an RCP_Membership object to a member name (as the name is stored with the user account), but it’s certainly doable.

      You’d use RCP_Membership->get_customer() to get the RCP_Customer object, then from there you can use RCP_Customer->get_user_id() to get the ID number. Once you have the user ID number you can use get_userdata() to retrieve the username/display name/first name/etc.

    1. We’re planning on implementing that in 3.1, which we are already working on! It could be a month or it could be 3 months. It will largely depend on what sort of issues we discover (if any and when) after 3.0 is released for good. We’ll first be focusing on ensuring the transition to 3.0 is smooth and completed for everyone, then we’ll get 3.1 pushed out with full multi membership support.

  3. Hello!
    I am just wondering, if you will you improve your connection to WooCommerce… It would be great if all this would work together and all payments could be done through it… (I am, as instructed by you, using your unofficial plugin…)… Thank you! Jan

    1. Very soon!

      We’re planning on implementing that in 3.1, which we are already working on! It could be a month or it could be 3 months. It will largely depend on what sort of issues we discover (if any and when) after 3.0 is released for good. We’ll first be focusing on ensuring the transition to 3.0 is smooth and completed for everyone, then we’ll get 3.1 pushed out with full multi membership support.

  4. Great news, looking forward to this!

    Should we be aware of any other potential breakages? E.g. like the RCP LearnDash integration, custom integrations with email marketing apps (E.g. Drip), and other things that use RCP member details?

    1. At this point there is nothing that is expected nor intended to break. We’ve built complete backwards compatibility into 3.0 for older integrations.

      That being said, there are significant code changes in this version so it’s very possible something will break. That’s why we’re releasing this as a beta to help catch those issues before the final release.

      If you discover any issues, please do let us know!

  5. I like these improvements a lot and I think they are very interesting. However, I was hoping that the update would include a personalized message for the content by drip, since as it is now, when the user tries to access this content, the same message of “restricted content” appears (which usually invites you to register in the membership to access) without explaining to the user that it will be available in X days …
    This is a topic that should be taken into account for future updates as it leads many users to confusion, because despite being registered and identified, that message appears …
    Thank you!!

  6. Is it possible to have two user role when a membership level is registed? or Update level but remain the old user role.

  7. BOOM! This is a fantastic update which appears to set the stage for many exciting enhancements down the road.

    Thank you for having a long term view and for making it happen.

    Nice work!

  8. Will the Stripe API changes allow us to use newer Stripe features, such as the browser payments, Apple Pay, Google Pay, etc.?

Leave a Reply

Your email address will not be published. Required fields are marked *