Is your feature request related to a problem? Please describe.
In PMPro v3.0, we are creating a subscriptions table responsible for tracking subscriptions data and next payment dates. In the 3.0 update, the next payment date for check subscriptions should stay in sync with the next payment dates calculated by this Add On, though this Add On will still use the existing SQL calculations.
Describe the solution you'd like
Down the line, we should switch to determining recurring payments based on subs table data instead of having subs table just being a mirror of the calculations in this plugin.
The benefits of this are:
Knowing that subs table data is 100% accurate
Simplifying code in this Add On
Compatibility with Subscription Delays
One important step that we need to make sure to implement here is an upgrade script when we decide to switch to relying on subs table. This upgrade script needs to load all check subscriptions with "default migration data" (to the 3.0 update) and make sure that they are all populated with a "next payment date". If this is not done, then some subscriptions may not create recurring pending check orders.
For Subscription Delays compatibility (and compatibility with many other PMPro Add Ons), we may also want to make the checkout process asynchronous. Ideally, users would not be given a membership level until the pending order is changed to success, and checkout data would be stored in order meta until that swap happened. Stripe Checkout is a good template and proof of concept to follow here. We may want this to be part of a bigger update to core PMPro that standardizes how pending orders (and maybe pending memberships) work.
Taking a step back, it is also important to keep compatibility for sites still using v2.x for the time being.
Is your feature request related to a problem? Please describe. In PMPro v3.0, we are creating a subscriptions table responsible for tracking subscriptions data and next payment dates. In the 3.0 update, the next payment date for check subscriptions should stay in sync with the next payment dates calculated by this Add On, though this Add On will still use the existing SQL calculations.
Describe the solution you'd like Down the line, we should switch to determining recurring payments based on subs table data instead of having subs table just being a mirror of the calculations in this plugin.
The benefits of this are:
One important step that we need to make sure to implement here is an upgrade script when we decide to switch to relying on subs table. This upgrade script needs to load all check subscriptions with "default migration data" (to the 3.0 update) and make sure that they are all populated with a "next payment date". If this is not done, then some subscriptions may not create recurring pending check orders.
For Subscription Delays compatibility (and compatibility with many other PMPro Add Ons), we may also want to make the checkout process asynchronous. Ideally, users would not be given a membership level until the
pendingorder is changed tosuccess, and checkout data would be stored in order meta until that swap happened. Stripe Checkout is a good template and proof of concept to follow here. We may want this to be part of a bigger update to core PMPro that standardizes how pending orders (and maybe pending memberships) work.Taking a step back, it is also important to keep compatibility for sites still using v2.x for the time being.