S2Member not demoting users when they reach their EOT

Hey there,

So I’ve used s2member successfully for several years, but I just realized that back in May, users at Level 1 (only level I use) stopped being demoted to Level 0 when they EOT passes.

EOT term setting in Stripe look fine:

The automated process just seems to have stopped working in May for some reason.

I’m not very code savvy, so I never go tinkering around under the hood. I’m completely unsure what it could be. Any suggestions?

I have had a similar issue, but it turned out that something had caused the Enable ... box to go blank. So I had to reset it and save, and then it worked again.

Obviously, yours has not gone blank, so what I’d suggest is that you install the WP Crontrol plugin and then check the list of Cron Events it finds (under Tools->Cron Events in the WP admin menu). You should see one there listed as ws_plugin__s2member_auto_eot_system__schedule

If it appears there, then it should be working.

If it isn’t there, then I suggest that you reset the Auto EOT behavior in s2Member by making the first box blank, saving, and then setting it to the right option and saving again. Then check that the Cron Event appears in the list as it should.

Thanks for the help. I went ahead and installed WP Crontrol and also found the proper cron-job on the list. It did show up.
So now I’m unsure as to why it’s not demoting users at the EOT, because it is there.

I went into the setting and disabled, saved, re enabled, but that didn’t seem to make a difference either.

I can’t explain it, but I have referred to your problem on this Github thread.

Thanks.

I do see others talking about this, but as I mentioned, the cron job is showing up, and a settings reset didn’t do the trick. Really hoping someone finds a solution!

I can also confirm that it’s not just Stripe, it’s also Paypal. I can see both payment processors on this list.

Maybe that could contribute to someone being able to help me find a solution? Obviously, these users should have all been demoted to level 0 yesterday. It’s a bit of a pain to handle all of this manually.

I have something similar that only a couple of members were not demoted after they canceled their monthly subscription and it still happen, must demote them manually and check frequently for non demoted members.

The EOT code doesn’t differentiate between payment processors, so that’s what I’d expect. What I don’t understand is why the EOT cronjob isn’t working if it’s showing up in WP Crontrol.

Same here

I have been fighting with the EOT settings for literally years.
First the EOT reset randomly it self, and the WP cron settings were kicked off.
I solved that by setting up my own cronjob via hosting that I run every 30 minutes (so in my case the WP cron is not the problem).
I installed the WP mail log where I see only few of member being notified. But certainly not all that passed the EOT.
What I found here on the forum is that the function that runs each cron action is actually limited to 6 users per request and some people suggested to increase that value.

// Increase per process SQL records scanned for EOT Reminder Emails
add_filter ('ws_plugin__s2member_pro_eot_reminders_per_process', 'aamet_set_eot_per_process');
function aamet_set_eot_per_process(){
	$per_process = 75;
	return $per_process;
}

so now I wait if that helps… but that might mean another angry email from customer who did not received their reminder… coz you never know if this is the last thing you should do to make it work.

Any other ideas?

just for reference, my issue on github