Expire Users with SCM Extension & Cron Job -- Does this work?

In an earlier version there were more settings (to specify the member group that a user should be upgrade to) but I soon realised that this information could be captured from the simple commerce module so there was no need to have it entered on the settings screen. 😊

Also, just to add that this extension is being used ‘in the wild’ on a site which we’ve been working on here at Nine Four for some time.

Be Fabulous

Nathan, because you have this at GitHub, I’m wondering if it’s best to grab it there, or if we should be grabbing files from this thread.

I’m actually working on a site now that will need this functionality. I haven’t yet started building the EE code, just getting the html/css up yet so I can’t yet play with this.

However I do have one question, will it be able to handle different subscription lengths. My client want’s to have monthly, quarterly, 6 month and annual subscriptions.

Hi @masuga and @sean.

At present the extension and accompanying plug-in are identical here and on github. If you want the very latest version check out github and if you want a fairly stable version, check here. I will start a new thread here when I release a new version.

Regarding different subscription lengths, at present it is not set up to cater for different subscription lengths, though the sending of notification emails and the downgrading of accounts is all handled by the accompanying EE template so if you are willing to get your hands dirty with a bit of PHP I see no reason why you could not hack this in using some simple if statements based on the id of the product which the user purchased.

Obviously if you do make any additions it would be great to see there posted here.

😊

This is very interesting to me - partly because I wasn’t even aware of this until a couple days ago, but also because this is the exact reason that I bought the FoxEE module that works with FoxyCart (user subscriptions). I’d much rather not use a subscription-based cart if I don’t have to.

@masuga: Feel free to fork this on GitHub, or just download it and build upon it… I have no upcoming jobs where I am likely to use this again at present so it would be great if someone else was also willing to help move it forward. 😊

I don’t think I need multiple member levels, so wouldn’t need to fork it necessarily - we’ll see. If I think it could use anything at all, I will definitely fork it at GitHub and keep you posted.

Nathan, can you explain the Cron template? I didn’t see any example code that you referenced. I’m working on setting this extension up for testing today - with a really short expiration period 😊.

Then I need to make a membership “product”? Maybe I need to go back and download Greg’s original file so I can figure out how to set this up from start to finish.

EDIT: I just noticed the second folder in the download that has the “expireUsers.php” template, but basic start to finish docs would be really handy.

Nathan, I almost have this working the way I need. I set up a cron job on my server (through cPanel) to run every few minutes (while testing). I also set member ship to be 30 minutes so I can test the whole expiration thing.

The issue is that it seems like when the cron job runs, it sets me to expired immediately. I modified the expire_users.php template that gets hit by the cron job:

if (($difference <= 900) && ($difference >= 1) && ($row['state']!="pending")) {

I changed that so that the first part is equal to 15 minutes. My thinking is that I should get emailed at around 15 minutes that my subscription is about to expire.

So, I sign up for a membership that is 30 minutes long. It costs a penny at PayPal (cheap testing!). I successfully go pay, and get returned to the site as a new member group. everything seems to be fine. I have the cron job running at 3 minute intervals. After three minutes, if I refresh my member page, I’m set to expired. I never get a warning email, and never get set to “pending”.

It seems my renewal date keeps getting added onto. It’s currently “February 4th, 2009 11:10pm”, even though it’s only 9:40 here. I’ve renewed a number of times in testing (hence the reason I think the renewal date is so far out there) but for some reason, I’m listed as expired.

Does this only work on the scale of days? I thought this was capable of seconds - which is enormously useful for testing. Any ideas? I’ll re-read the thread to see if I’m missing anything.

I’m outputting some values to my template and I just noticed this, after signing up for a new subscription:

now: 1233911431 join date: 1233808830 renew date: 1233826830 diff: -84601 State: active Your current time: February 5th, 2009 11:10pm Renewal Date: February 4th, 2009 11:40pm

I am listed as “active” (because I just signed up) even though the renewal date was never updated - and note that it is in the past compared to my current time. So, of course, the next time the cron runs, it will set me to inactive.

Any thoughts as to why this might not be updating the renew date in the exp_paid_members table? I see you have a hack for a new hook, but is that necessary?

Hi Ryan. I’m unlikely to have time to look into this today but just to let you know I’ll set up a simple test here to try and replicate the problems you are having. It may be that you’ve discovered a bit of a bug in my code!

RE the hook, this is only required if you want the extension to also be called when manually modifying a members group assignment via the control panel (if I remember correctly!).

Thanks Nathan, I’ll move on to another part of this build that needs my attention for now, but will definitely need to get this worked out. It’s working pretty well as far with PayPal and the cron job and everything - just have to get the date difference correct and I’ll be golden.

Thanks for the info about the hook. I’d love to see a more detailed code sample of exactly where we’re supposed to put that hook in the code. Above or below the bracket in cp.myaccount.php?

Back at this, and have sort of narrowed things a bit. I had a user in the table that had already expired - so their renew date was in the past. To add to that would be short changing them! When I was updating that user(resubscribing), the Subscription setting was adding to that old date, instead of the current time. That is a big deal when your subscriptions are only minutes long, like mine are in this testing phase. So:

1) If you were once a member but expired and you’re renewing, add the subscription date to NOW.

2) If you are currently a member, but are renewing early (say, in your pending period), add the Subscription time to the renew date.

I made a conditional for this in the add_paid_members function. Here’s that area:

} else {  // If they are renewing their subscription

 if ($isMember->row['state'] = 'expired') 
 {
    // if they had expired, we need to add to NOW, not old renewal date
    $renew = ($today+$this->settings['subscription']);
 } 
 else 
 {
    // if they haven't yet expired
    $renew = ($isMember->row['renew_date']+$this->settings['subscription']);
 }

$returningMember = array(
  'renew_date' => $renew,
  'state' => 'active'
);

That seems to work pretty well, and I’m almost there with this. The issue I’m having now is that somewhere I’m almost 5 hours off.

I’m creating subscriptions that are 30 minutes long for testing. As an expired member, these were my stats on my member template:

join date: 1233808830 (2009-02-04 06:40 PM) renew date: 1233914630 (2009-02-06 12:03 AM) now: 1236152822 (2009-03-03 09:47 PM) diff: -2238192 Alternate date output: Join Date: February 4th, 2009 6:40:30 pm Renewal Date: February 6th, 2009 12:03:50 am Your current time: March 3rd, 2009 9:47:02 pm

I then renewed my (30 minute) subscription:

join date: 1233808830 (2009-02-04 06:40 PM) renew date: 1236136678 (2009-03-03 05:17 PM) now: 1236152965 (2009-03-03 09:49 PM) Alternate date output: Your current time: March 3rd, 2009 9:49pm Renewal Date: March 3rd, 2009 5:17pm -16287 seconds off - about 4.5 hrs

Note the times. Looks like something is off by 5 hours, and then the 30 minutes got shaved off. My renewal date should have been March 3rd, 2009 10:19pm

I just love dates and times. I think I need to kill all localization and try to make these dates based on some sort of hard and fixed date and time, period.

Where should I look first at shaving off that strange 5 hour difference? My server time (or is that PHP time?) seems correct, if going by what time is output on the template for “now” is any indication.

Thanks for any thoughts.

Well, I just tried this in the extension, and it seemed to work quite well:

// Get todays time string and add the subscription time period
//$today = time();
$today = $LOC->now;

It was using “today”, but I was reading the docs for the Localization Class and that recommended using $LOC->now.

I just tried to upgrade again:

Your current time: March 3rd, 2009 10:14pm Renewal Date: March 3rd, 2009 10:43pm

Looks like it’s working!