OK, I’m about ready to go ape. It is not adding from the renew date for members that are still either active or pending at the time of renewal.
I set membership for 20 minutes. At 10 minutes remaining, the next cron job should run the user checking template and set me to pending. That works perfectly. The problem is when I renew. The script should add the Subscription time (1200 seconds in this case) to the renewal time (which is a time in the future), NOT the current time (like it should when a member is fully expired).
Here are my pre-renewal stats from my testing template:
join date: 1233808830 (2009-02-04 06:40 PM) renew date: 1236158288 (2009-03-03 11:18 PM) now: 1236157766 (2009-03-03 11:09 PM) State: pending Your current time: March 3rd, 2009 11:09pm Renewal Date: March 3rd, 2009 11:18pm
Note I have 9 minutes left to renew, and my state is ‘pending’. The cron job ran and did its job correctly. And after I renewed:
join date: 1233808830 (2009-02-04 06:40 PM) renew date: 1236159008 (2009-03-03 11:30 PM) now: 1236157815 (2009-03-03 11:10 PM) State: active Your current time: March 3rd, 2009 11:10pm Renewal Date: March 3rd, 2009 11:30pm
My previous renewal date/time was 11:18pm, which was in the future. When I renewed, the script added 20 minutes, but from the current time. It should only do that if my state was ‘expired.’ My New renewal date really should have been 11:38pm, not 11:30pm. I got ripped off by 8 minutes!
If anyone can take a look at this, I would greatly appreciate it. I pasted my version of the extension into a Gist at GitHub. I changed roughly lines 128 to 125. Is there something wrong with my logic?
I’m real good at hammering my head against a wall until I figure something out. I was missing an equal sign. From the line posted above, change:
if ($isMember->row['state'] = 'expired')
to
if ($isMember->row['state'] == 'expired')
That seems to solve the whole thing.
For the books, I also found this function online, that will show the time until expiration in a nice format:
<?php
global $DB, $SESS, $LOC;
$currentTime = $LOC->now;
$query = $DB->query("SELECT * FROM exp_paid_members WHERE member_id ='".$SESS->userdata['member_id']."'");
$renew_date = $query->row['renew_date'];
// Get the diff between today and the expiry date
$difference = ($renew_date - $currentTime);
function strTime($s) {
$d = intval($s/86400);
$s -= $d*86400;
$h = intval($s/3600);
$s -= $h*3600;
$m = intval($s/60);
$s -= $m*60;
if ($d) $str = $d . 'd ';
if ($h) $str .= $h . 'h ';
if ($m) $str .= $m . 'm ';
//if ($s) $str .= $s . 's';
return $str;
}
echo "
<strong>Time until expiration</strong>: ".strTime($difference)."
";
?>
In my test, I had 5 minutes left on my 20-minute membership. I renewed and the $difference was 24 minutes and some seconds…so I know it’s working now.
I’m going to clean up the extension a bit. I also added to the language file (add a bunch of time notes for easy reference).
I’d also like to add a setting for when the user group gets set to pending (again, number of seconds here), and settings for the paid group and expired group (query for existing member groups and make a dropdown for each). I’d also like to find a way to keep the content of the emails out of the expire_users template - that way, you never have to go into that template, you can just tweak your PME settings in the CP.
Another cool thing to do would be to make a CP page that lists all the members and their expiration dates (basically just displaying the content of your exp_paid_members table), and just gives simple counts: “143 Paid Members, 23 Pending, 8 expired.” I think this would have to become a module to do that - so I’ll see about that part
I forked your project and will push my changes when I get a chance. I’ll send you a pull request once I get something up.
Thanks for your work on this. it seems like the simplest way to do subscriptions.
This is interesting. Any updates on this one? Have you put up your changes to the extension Ryan?
Will this allow subscriptions into different member groups on the same site? I need to be able to assign people who sign up for one subscription into one group and people who sign up for another subscription into another group. This seems like possibly a simple way of doing things.
What about recurring subscriptions? Any possibility of supporting those?
@Shannon: If I recall, the SCM allows you to determine which member group the users gets put into after purchase.
Recurrent subscriptions are tricky, and I’ve gone the route of using the cron to move members to an expired member group, and also to send a reminder email, about a month out from their subscription expiring.
Thanks for the response AJ. After reading through the thread about this, it seemed a bit confusing as to whether it only allowed for one paid membership group. I think that it does allow for more, but at one time they were having you set the member group in the control panel… which implied only one group. They then removed that and seem to use the group from the product set up in SCM, so I’m thinking you can do this with multiple products. I just want to verify that.
If I understand what you’re saying, you’re not bothering with recurring subscriptions then? I’ve often heard they are tricky, but I’m not sure in what way? Paypal IPN provides the ability to have them… basically sending out messages you can listen for that tell you whether or not auto-renewal went through. I’m NOT at all really familiar with all this, but I’m just wondering why people are finding them so tricky. Thanks!
I’ve modified Nathan’s extension, but haven’t released anything.
It only allows for one group (subscription type) right now. The cron runs every day. If you fall within a ‘pending’ period, you get sent an email saying you’re going to expire in x days. At x day, you get moved to the expired user group.
One group, though!
I didn’t have the need for multiple groups, so I hadn’t thought about it. Thinking about it now, however - you could probably do multiple groups with a touch of hard-coding. THere are some things in the extension that should probably be settings that you have to hard code for now. And the template that the cron runs would have to be modified.
It could probably be done, yes - with a little bit of difficulty.
Any thoughts about recurring subscriptions?
I just find that EE is really lacking in terms of subscriptions… a good module that works with paypal would probably help a lot of people out.
I also am now using FoxEE. Might be overkill, but with nothing else to choose from, I went with it. It’s pretty good, but currently FoxyCart doesn’t allow you to use Paypal standard as a payment processor. It’s in the works, but there isn’t a date. Also, FoxEE is still in flux. I’m thinking the next version that is coming out soon will be a big improvement and solve many of my issues with it.
I just think there is room for more than one solution out there and you guys are heading in the right direction here.
Subscriptions are absolutely lacking in EE. Another option, which I’ve done in the past, is to integrate aMember with EE. NOT fun - but subscriptions are what aMember is for, and there is an EE “bridge” to get aMember to talk to EE. I’m a fan of using just EE when possible, though.
I purchased the FoxEE module a while back…tried installing it twice and backed out both times. Not a fan.
Are you saying the recurring subscription should automatically renew someone, say, if they have a certain custom member field checked to do so?
Yep. The paypal api allows for this. So, basically the user requests to have a recurring month to month subscription (hopefully just a product type in EE weblog)… there is no real expiry date then (although it can be built in to expire after say 2 years or whatever, but that just complicates things for now). Basically, they get billed each month until either of two things happen: the user cancels the subscription OR paypal is not able to get the transaction to go through… perhaps because they have an expired credit card on file or whatever. This is the sort of thing that paypal will send messages for… if they aren’t able to keep billing. In fact, paypal can handle the entire subscription and the user actually cancels their subscription through either paypal or the site. It’s kind of interesting and I’m surprised no one has jumped on getting it to work. I’d do it, but my php skills are limited and I’m not sure I want to use my php skills to mess with eCommerce.
FoxEE is coming along. I am having problems getting it to work properly at the moment (expired users member groups are not being set), but they’re working on it. I haven’t even tried to get recurring subscriptions to work with it (it is supposed to do this). I ran into a FoxyCart bug, but this was quickly fixed (it was a new version of the cart). Next version of FoxEE is going to integrate better with member management in EE, so I have some high hopes for that. I also want to use paypal standard… didn’t realize this wasn’t an option when I bought it. It will do paypal pro and paypal something else… not pro, but similiar. Can’t remember what they call it. Anyway, as I said, this is on FoxyCart’s list to implement along with google checkout. FoxEE will eventually provide all sorts of flexibility once the kinks are worked out.
By the way, here’s the link to the paypal instant notification guide: https://cms.paypal.com/cms_content/US/en_US/files/developer/IPNGuide.pdf
Am looking at how subscriptions work for EE and need to use them on my first 2 EE sites am working on.
Am I correct in thinking the best option is to create a new blog called ‘Subscriptions’ and place them as entries in there?
Ryan - very much like the add-on you’ve created which I’m assuming you use on devot-ee? Am I imagining things or did you write an article on how you used it to do the membership system at devot-ee? (Probably I am!) 😊
Hi Euan! The extension which Ryan has used is a fork of an extension that I developed based on some solid work by Greg… this is a convoluted path that it has taken! At some point I hope to merge Ryan’s changes back into the extension I’m hosting on GitHub but feel free to fork my version and modify as required. Please share your experiences here and hopefully we can continue to build upon what we have! 😊
http://github.com/nathanpitman/np.paid_members.ee_addon/tree
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.