<URGENT> All Active PayPal Subscriptions Expired

Actually that code has a typo. That may be why some people are getting errors.

It shouldn't say "expire date"
It should say "expire_date"

Code:

update amember_payments set expire_date = '2036-12-31' where expire_date = '2012-12-31'

I know skippybosco's original code was correct. I think at some point maybe someone typed it out and got a typo in it. If you look back on page 1 of this thread you'll see his original sql.

You are correct Benjamin, I had copied it from another thread and missed to fix the typo. It would throw an SQL exception without the underscore.

Hi guys,

Thanks for sharing your thoughts, it's great that while amember support ignores the problem - there is source of information to deal with such an urgent problem.

I'm in process of fixing this paypal expire bug on our side and wondering about all those "expired/cancelled" users. I see that for all of them 31-12-2012 is used in amember table. So does that mean - when we perform mass update in db - it will have any side effect - ie all these users will get access to amember again until next paypal rebilling cycle? Would it renew cancelled ones and charge them once again?

My understanding is that Pay Pal is unaffected by this bug. So Pay Pal will "ping" aMember whenever their subscription payment happens, and that will "end" the current monthly sub and start a new one, just like always. If someone cancels or doesn't pay, Pay Pall will "ping" aMember on the last date of the sub period and still cancel/deactivate their password.

Of course, with so many changes to php code and running SQL scripts, I'm nervous about everything working out. Within a few days, the aMember tech support should return and they'll be busy hopefully fine-tuning all of our amateur emergency fixes that we've done during their time away.

The only people you have to worry about getting a free sub would be anyone whose sub just happened end on 2012-12-31. So if you have a way to check that, you may need to do some manual deletes since Pay Pal (or other pay services) would never "ping" aMember again to cancel them as it did it, as it was supposed to, on Dec. 31 during all of this chaos.

If anyone thinks I'm wrong, definitely correct me.

Hi guys, thanks for the help so far in this thread. I've made the necessary database amendments changing the date string to 2036.

Like everyone I have some important questions, as most of my member base cannot currently login.

I can see all of my active members that expired, but before I go in and manually amend their dates to become active again - how can I be sure that they will fall back into the recurring model? I know their Paypal subscriptions will recur, but I need to be sure that their membership period will also recur, and not just end on the new end date that I set. How can I manually ensure this?

I had this problem and thanks to this thread, it is now resolved. Really appreciate those of you who shared your fixes, here's what I did:

updated /amember/product.inc.php --> define('RECURRING_SQL_DATE', '2036-12-31');

ran the phpMyAdmin command --> update amember_payments set expire_date = '2036-12-31' where expire_date = '2012-12-31'

changed all 2012 date references to 2036 in /amember/plugins/payment/paypal_r/paypal_r.inc.php (thank you steveric for confirming that)

no rebuild DB needed for me, as these fixes reflected RECURRING for my PayPal subscribers (2037 had made them LIFETIME) and showed them ACTIVE again and not 'expired'.

Thanks again!

Can anyone help with running the phpMyAdmin part. That's the only thing I haven't done and I'm a bit of a tech newbie with this stuff.

Alternatively if I can manually setup recurring end dates I'm happy to do that manually.

Any help appreciated asap as I have lots of members who can't login atm.

Thanks!

Just to clarify - I'm trying to work out if by specifying a manual end date for a subscription that was interrupted by this bug and is now set to expired the membership will continue to renew like normal, or if I need to do this another way?

I would really appreciate help with this, as every hour that goes by my members will become less happy.

I am using version 4.2.14 and mistakenly believed I was not going to have a problem. I was wrong. While I get this resolved, I have deleted protection from the affected folders.

I modified the line of code mentioned previously in this thread to the follwing:

update am_payments set expire_date = '2036-12-31' where expire date = '2012-12-31'

It does not work because there is no table named "am_payments" and I believe some of the file names may also be different. Can someone provide the code for version 4.2.14 ..... ASAP!!!

Thank you

Larry Carhartt
www.masterdata.com

By the way, all my tables begin "am_". The closest I see is "am_invoice_payment ".

Ryan Sumner <rsumner@cynchinc.com> helped me with that. He said it was very much his area of expertise. He bills $100 for an hour and 30 percent prepayment. His email is listed at the start of this sentence. I recommend him.

Thanks Keller. I appreciate the recommendation, but I'm honestly happy to do this manually working with individual members.

I literally just need to know if I amend the end date of their membership if this will still allow them to auto-renew or not?

Did you experience the same errors (active subscriptions turning into expired state) as described in this thread? It would surprise me that the same error is still available in more recent versions as version 4.x is totally different from 3.x. It uses different database schemas, API calls and other templates syntax. That's why the above update code doesn't work.

Nothing you do within aMember affects Pay Pal. People sign up with Pay Pal. Pay Pal pings on a specific date each month as long as their sub isn't expired or canceled. So I believe from experience that if you set it to a random future date, Pay Pal will ping on the date of their autopayment each month and add another month to the aMember sub. I think it wouldn't matter if the future date is 2015 or 2036, as long as it's not December 31, 2012 or any date in the past! Again, I'm not purporting to be an expert, so anyone else can correct me, but using aMember for several years, this is my understanding and experience.

That's what I'm hoping. Most of my members are on a 1 month recurring fee, so I want to change their status from expired to active and set the end date of their term to a month after their last payment. It would just be a nightmare if this didn't then rollover onto another month once the Paypal subscription payment went through.

Can anyone else confirm Keller on this?

(thanks for the help)

You are right. Payments do continue as long as expired date is in the future, but the newest version of aMember may handle that differently (it has new features like "stop recurring" and others which I haven't tried yet). One thing the 201211231 expire date does do is stop access for the subscriber. My tempoary fix was to delete the folder protection temporarily until I get this resolved. I am using version 4+ and it has many new features that complicate fixing this. I hope aMember support is reading this and provide a solution VERY SOON!.

Thank you

Larry

Hmm, what I'm worried about is that when someone signs up their dates for membership are displayed as:

01/02/2013 - RECURRING

I literally can't see anyway to specify 'RECURRING' as the end date. So surely specifying save 02/02/2013 would just end their membership on Feb 2nd and they'd expire again?

Any experts here who can help asap please?

Not sure I qualify as an expert, but I recommend just set the date manually to 12-31-2036. It will auto-renew every month until then as long as their sub is paid every month via Pay Pal. What you don't want to do is set it for just one month from now (2-2-2013) because then you'll run into the same issue as the 12-31-2012 problem. That "future date" should be far far ahead and Pay Pal will either extend or end the sub based on the "ping" it sends to aMember on the monthly renewal date for each member. You might not see the word RECURRING when you manually set the future date, and that worried us, too, but since Tuesday we've seen some memberships roll over and they are working as normal again.

Thanks for the details.

I actually just input the date string as 2036 and it came up saying 'RECURRING'. So problem solved it would seem...

However, I'm a little worried that this will mean a lifetime membership for people, even once their natural membership is meant to expire.

Also, in going through my members some have shown up as expiring on the 31st December, but hadn't paid membership for a year or so. I'm pretty sure they couldn't get access during that time, but it's odd how their expiry date wasn't accurate. I don't know if this is to do with the previous 'RECURRING' expiry date being 2012, until I updated it to 2036 on the backend. Although surely because they expired it shouldn't be linking them to a 31/12/2012 expiry anyway.

Gah sorry, my head's hurting going through all this.

Hopefully the aMember tech team is back soon and can clean up the mess. I sorta think if we can get through the week with duct tape holding things together, they can get everything back into proper working order for the long term. They'll be busy, I think.