Extend Renewals Based on Custom Format

[JarrydLong]

Is your feature request related to a problem? Please describe.
PMPro's core functionality is set to extend a membership level when manually renewed if an expiration date is set. The Set Expiration Date Add On doesn't honor this.

Describe the solution you'd like
Ideally, when renewing a level that expires before the time, it should extend the time based on the same format. If set to Y1-M-01 then an additional year should be added when renewing.

Describe alternatives you've considered
The only way to work around this at the moment is to use the PMPro core functionality. But then you lose the functionality of the extended features that the Set Expiration Date Add On provides.

[MaryOJob]

A workaround for now could be to hide the renew button with CSS, set your “Expiration Date” to the next year (e.g, Y2-12-31), and when you want members to begin to renew, take out CSS code used to hide the renew button.

Members who renew would then be able to have their membership extended by one year or your specified date.

[andrewlimaza]

There is a PR that has some logic around this but would need testing as it's a bit outdated - #16

[ideadude]

Say for example someone set up 1 level to expire on Dec 31 of the year, so Y1-12-31. When people check out for that level, their expiration is 2023-12-31. Good. But then, sometime around Dec 1 they're going to get an email about their membership expiring. And sometime between Dec 1 and Dec 31 they are going to try to "renew" their membership.

Currently, if that person checks out for the same level on Dec 15, it sets their expiration date to Dec 31, 2023. The expected behavior for 90%+ of cases is to set that to Dec 31, 2024. That's kind of hard though.

Why is it hard?

1. The expiration is not always 1 year, it could be monthly or weekly or daily, and there could be a period of every 3 months, every 2 weeks, etc.
2. The Dec 15th example is "obvious", but different sites have different opinions on extending depending on far into the period it is. A counter example is a monthly subscription that creates the monthly newsletter on the first of the month. It's more important in that case that people checking out only get 1 issue of the newsletter rather than the total time they have access. So for that site, someone checking out on Feb 28th, when the newsletter comes out on March 1 should only have access until March 1.

The work around that many are using in that annual use case is to manually update the expiration date from 2023-12-31 to 2024-12-31 sometime around November.

Here's an idea for a couple update that I think should address this for most use cases.

1. After pmpro-set-expiration-dates figures out the expiration date, if it's exactly the same as the user's current expiration date, then push the expiration date out 1 period. "1 period" is the main expiration date cycle_number and cycle_period set for the level.

You might want to let PMPro push things back, but there are off-by-one issues with that. SED knows that the site wants the expiration to be something like Y1-12-31, so it can make sure that when it pushes the date out, it's still on the 31st of Dec... and probably can use a different algorithm that just increments years, months, or days based on how the set expiration date is set.

When PMPro is interacting with an expiration date, it puts into a timestamp format (effectively). But when SED is working with an expiration date, it's in Y-M-D format.

2. A related fix is if the expiration date is in the past, we should throw an error at checkout (You're already a member until X. You can't checkout again until Y.) instead of redirecting back to the levels page like we do. When this happens, people don't know why. (It's user error on the admin side, but would be nice to have an indicator.)

Complicating issue. Lots of active sites have had off by one issues for a few years. So if their expiration date was Dec 31, some combination of custom code and other fixes have resulted in a few people expiring Jan 1, Jan 2, etc. So the "exact same date" mention in 1 above may want to be "fuzzy". I would suggest a gist for that. It could consider any expiration date within 1/2 period of the calculated expiration date to be "the same". E.g. for annual recurring level, the period is "1 year". So anything that is < 365/2 days after the set expiration date would be considered the same.

I think the code version of this is much simpler and will work on a PR for consideration.

[MaryOJob]

Plus One for Option 2

[dwanjuki]

A customer using this Add On (Mods: ticket #494688) would like early renewals to extend the membership by one period.

[dwanjuki]

A customer (Ticket #496977) is looking for this functionality.

[andrewlimaza]

Here is a gist that is a good starting point in programmatically changing the Set Expiration Date - https://gist.github.com/andrewlimaza/f5e6bce9dfb832d0f1bac247cebac4f4

Summary of the gist and edge case:

• Set Expiration date is set to Y1-12-31 (31st December of the current year)
• If checking out from 1 October - 31 December of the current year, set it to Y2-12-31.
• This would affect renewals and new checkouts for this checkout window, but could be adjusted for renewals only by a developer.