rossagrant
commented
6 years ago This sounds pretty straight forward actually.
s2 runs it's own EOT cron job, within the wp-cron job schedule to check for EOT's - and members to demote.
It usually runs once every 10 minutes.
Occasionally wp-cron can have issues due to many things, including plugin conflicts.
It sounds like the s2 job had not ran for many months, for some reason - it may have been deleted by accident, and a re-save of s2 settings had re-scheduled it.
It obviously ran and demoted all expired EOT's.
Grab a plugin to let you see your cron-jobs - and double check that the s2 EOT job is there.
As long as it is, you shouldn't see this issue arise again.
EVERY time you update s2 - go in and re-save your settings, just to make sure that job doesn't ever go astray again.
EXPLANATION OF THE ISSUE
Today, I had 40+ auto-eot-cancellation-expiration-demotion. Our site admin tells me that most of them had canceled anywhere from 3-6months ago, and one of them should not have been demoted at all.
STEPS TO REPRODUCE THE ISSUE
I'm not sure how you'd reproduce this. I just am trying to find out if there is any issues you know of that could have caused this.
BEHAVIOR THAT I EXPECTED
Obviously, the expectation is the auto EOT would happen on each individual EOT date scheduled after the cancellation.
BEHAVIOR THAT I OBSERVED
The fact that this many processed in one day, and they all had different cancellation dates prior to the EOT is odd and worries us that members who have canceled are in fact getting "extended" access without paying for it. This could hurt our profits, and if it's a bug it should be addressed. Any help is appreciated.