<URGENT> All Active PayPal Subscriptions Expired

I am unaware how to do that, though. I don't have the ability to do this part:

==

You can do this in phpMyAdmin. Run this query:​

update amember_payments set expire_date = '2037-12-31' where expire date = '2012-12-31'​

==​

Can you maybe better explain to me how I'd go about that? I don't want to do it manually, obviously.​

I'm also confused as when I have changed some manually, I don't see "RECURRING" anymore. I see instead:​

"​

12/09/2012 - 12/31/2035"​

I think before I would have seen:​

"12/09/2012 - RECURRING"​

Is this something Pay Pal, next time a recurring payment is made, will essentially "reset" back to looking the old way?​

​

Regarding this:

==

You can do this in phpMyAdmin. Run this query:​

update amember_payments set expire_date = '2037-12-31' where expire date = '2012-12-31'​

==

I don't believe I have the capability to do this on my own. Not sure how, and my hosting company says I don't have the phpMyAdmin program installed. Can you give me detailed directions assuming I have limited knowledge base or provide an alternative route to accomplishing this?

Thanks very much!

Are you sure that's all we have to do?

Doing the 2 changes solved the issue for the members who were being billed (before the change). They showed status active and RECURRING again.

However subscriptions coming in AFTER the change are still put on end date 2012-12-31. We currently set them manually on 2036-12-31 to make the subscriptions active and RECURRING again.

I'm wondering if we don't have to update the dates in /amember/plugins/payment/paypal_r/paypal_r.inc.php ?

I confirm that paypal_r.inc.php has to be updated as well.

Search for the date 2012-12-31 and replace with the date you used in the previous changes.

Not doing so will set end date still on 2012-12-31 for new incoming subscriptions.

Ask your webhost support to run the above query for you. They should be able to do that.

I was wrong. Steveric is correct that you DO NEED TO CHANGE

paypal_r.inc.php to make the values the same as those you set in ​

paypal_r.inc.php​

I did get someone to run the phpMyAdmin query and changed the date. He changed it to 2037, not 2036. Does anyone know if it matters that it shows current subs as being "LIFETIME" instead of "RECURRING," though. Is that an issue with the "future date" being 2037 specifically? Might this affect auto renewals each month or new sign-ups?

You said "

paypal_r.inc.php" twice. What did you mean instead? I just want to be sure I've changed all of the proper php files.​

Does it matter if the date is 2035, 2036, or 2037 for instance? Is there a special meaning to one year compared to another, or is it rather arbitrary?​

I think he means that you have to change it in paypal_r.inc.php and product_inc.php

I am having the same problem as you and have done the following:

1. Ran the SQL update code: select * from amember_payments where expire_date = '2036-12-31'; (I am using 2036 as that changes the subscription to RECURRING - 2037 changes it to LIFETIME.
2. Changed 2012-12-31 to 2036-12-31 in product_inc.php.
3. Changed all occurrences of 2012-12-31 to 2036-12-31 in paypal_r.inc.php

HOWEVER, this does not fix one huge problem, which is that all members that were mistakenly expired on 2012-12-31 are still shown to be expired! Which means nobody can log into my posts now. I have no idea how to fix this.

I did have a third party programmer (who migrates servers for a living, but did some work for me on a holiday today to fix this for me) who ran the SQL update code. Afterward, I clicked on Rebuild DB on the left menu of the aMember admin home screen and that fixed it. Everyone is current again. It was important to click Rebuild DB, though.

Do you know if it the labelling of RECURRING or LIFETIME matters or is just a label and functionally aMember will still interact with Pay Pal correctly. I'll have aMember's tech team in a few days tweak all of this, but I'm wondering if in the mean time I should re-update the database to switch from 2037 to 2036.

Good luck.

You are a frigging life safer! Thank you, thank you, thank you!!!!

I played around and setting the expiration to 2037-12-31 flags a recurring sub as LIFETIME whereas 2036-12-31 sets it to RECURRING. I hope this helps a little.

Rebuild DB worked? Excellent!!! I know the feeling of having my life saved, so I'm very happy if I was a life saver today, too.

The Rebuild DB was kind of dumb luck or a hunch on my part, but I was too tired after staying up for 23 straight hours trying to fix this mess to talk myself out of trying it. It seemed low risk and possibly a solution.

Have you figured out if it makes any difference functionally? I'm just curious if recurring subs or new subs will run into any issues if they are marked as LIFETIME as that might just be a "label" without any meaning. I hate to bother the guy who helped me update the SQL database to switch it from 2037 to 2036 if it makes no difference and the aMember team can help in a few days. But if it does cause issues, I'd like to fix it right away. Not sure if you would even know that, though, but in case you or anyone knows, share any info you might have. Thanks.

Well, see my comment #29. This should fix how RECURRING is being referenced internally (2036 instead of 2012). And the paypal_r.inc.php update is necessary to make sure new subs are being set to the proper end date. Of course only if you run PayPal - otherwise I am certain that other PP processor scripts need to be similarly changed.

If you know Unix command shell then you can log in via SSH and navigate to your amember folder. Then run the following code:

find . -type f -name "*.php" | xargs grep 2012-12-31

This will show you all PHP files that have the 2012 date reference.

I also think that ./admin/mass_subscribe.php needs to be changed as well.

Are you sure you ran the right sql code? The code you mention in 1. is no update sql code. The code mentioned in this thread is: update amember_payments set expire_date = '2036-12-31' where expire date = '2012-12-31'

I hear you on that one - wish we would have known -- why not make the future date 2100?
eugh. what a pain
(now we have users who paid today who show the payment never went through. it's all a mess)

My mistake, I was sweating bullets last night and had copied another SQL statement. The one I used is this:


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

I am using 2036 as that changes the subscription to RECURRING - 2037 changes it to LIFETIME. Also be aware that this may extend some lucky non-recurring subs to 2036, so you may have to dig around and find those.

In order to avoid the aforementioned you can run:

update amember_payments set expire_date="2036-12-31" where expire_date="2012-12-31" and paysys_id="paypal_r";

However I have not run this one personally, so I cannot vouch for it.