Hopefully someone can assist. We have a few hundred members

Hi

Hopefully someone can assist.

We have a few hundred members on the membership plugin which were due for renewal on the 31st of December 2014.

I have checked today and it seems that all of the members have renewed but it doesn't seem right. All of the member expiry dates have changed to a day later in 2016 but all of the renewal times are very odd. I have also checked a member which i am sure would not have renewed on the website and they are set as renewed.

The the members were all on a subscription type of serial and payment gateway of paypal express single payments. Would this setting mot mean that the user would need to come back to the website and make payment to renew? I didn't think auto renewal was set up on this paypal- also seeing no members had entered any paypal details because they were imported.

Please help!

Thanks,
Justin

  • Michael Bissett

    Hey @Justin, hope you're doing well this evening! :slight_smile:

    After discussing this with my colleague @Jude (who had assisted you on another thread regarding Membership), he said for me to send it to him, so that he can dig into this more.

    Just to provide my own bit of feedback here, while I didn't see any additional transactions posted for each of those membership level adjustments noted in:

    Membership -> Membership -> News

    I did notice that said membership level adjustments seemed to be processed in groups (one group of users were processed on 2015-01-01 : 04:36 ], another being processed 2015-01-01 : 05:31).

    Kind Regards,
    Michael

  • Jude

    Hey Justin

    I was just running a few SQL queries on the database and I can see that as @Michael Bissett correctly pointed out the renewals were done in batches at specified times.

    Here are some interesting finds

    Memberships were added in batches at the following local times on your server

    '2015-01-01 03:01:08' -> 24 Users
    '2015-01-01 03:16:47' -> 24 Users
    '2015-01-01 03:30:24' -> 24 Users
    '2015-01-01 03:45:18' -> 24 Users
    '2015-01-01 04:03:57' -> 18 Users
    '2015-01-01 04:20:14' -> 23 Users
    '2015-01-01 04:36:38' -> 19 Users
    '2015-01-01 05:31:56' -> 18 Users

    If you want to double check these figures run

    SELECT * FROM wp_m_membership_news
    WHERE newsdate
    BETWEEN  '2014-12-30 00:00:01'
    AND  '2014-12-31 23:59:59'

    Its highly unlikely that it was done by the members themselves given the timestamp on these transactions (i.e 24 users could not pay at the same second)

    Also I looked through the payment gateway's approved transactions and only a fraction of the users we sent the email to actually responded. This data contains sensitive information so I am posting the query, you can run it on the database to see the results yourself

    Members who signed up after seeing the Mail (Total 7)

    SELECT wp_users.ID, user_email, user_login, display_name, paymentmade, paymentexpires
    FROM wp_m_member_payments
    INNER JOIN wp_users ON wp_m_member_payments.member_id = wp_users.ID
    WHERE  paymentmade
    BETWEEN  '2014-12-30 00:00:01'
    AND  '2014-12-31 23:59:59'

    Members who have at any point of time made a successful payment on this site using paypal (Total 21)

    SELECT ID, user_email, user_login, display_name,
    transaction_ID  ,   transaction_paypal_ID  ,   transaction_total_amount
    FROM wp_users
    INNER JOIN   wp_m_subscription_transaction
    ON wp_m_subscription_transaction.transaction_user_ID = wp_users.ID
    WHERE   transaction_status  =  'Completed'
    ORDER BY   wp_m_subscription_transaction . transaction_ID  ASC

    Also if you include a bunch of discounts / manual transactions / pending and cancelled transactions the number goes up to 63. The plugin I created sent mails to 192 users so certainly a majority have not paid.

    Please run these queries for yourself and take a look, let me know what you'd like for me to do. We can easily revert / cancel memberships if needed. Also please check if any of the other admins intentionally made these changes to user memberships.

    Regards,
    Jude

  • Justin

    Hi Michael and Jude

    Sorry for the delay in coming back, I have a different day job and am releasing this website as a favour in my spare time. Thanks for looking into this.

    I can see in the membership news that the members have changed level. No other admins have made these changes.

    I am trying to get a handle on what exactly would happen when the membership is past it’s expiry date. I would have expected that the membership would have dropped access level to the ‘visitors access’ – would the member still be able to log in with the same credentials and renew their membership level after the expiry date? Can you confirm exactly what should happen if the member is on a serial membership subscription and it is past the expiry date?

    Could it have been an erroneous cron job or some other piece of development that we had done. There are two piece of custom development that we have had done.
    The first which @Jude knows about where membership products are toggled between public and private depending on the date.

    The second piece was to do with the renewal dates. There is a requirement for all members to renew at the end of the year (hence why we have quarterly membership products which toggle between public and private), but to get the dates correct this is what happens:

    • Member joins as a new member & pays
    • Is assigned an ‘unapproved’ access level
    • Once the admin are happy they then find the member and move their access level from ‘unapproved’ to ‘approved’ access.
    • The action for doing this move from unapproved to approved automatically changes the users expiry date to the 31st of December of that year

    This should not have effected these members as I imported them from a previous database but I suppose it could be a possibility. Is there any way you might be able to tell for me? I am not great a code and these pieces were beyond me and outsourced :-S

    Next course of action will be to change all the members expiry dates back to the 31st of December 2014 … but if I do that how can I be sure that the same will not happen again and all the levels change back to the renewed status? I was sent a list today and out of all of the members only 17 have actually truly renewed. Hopefully we can get this fixed before the other 180 odd members come to the website expecting to renew (and find that they have been renewed). Do you think we should set up a maintenance page for the login page or something so that they cannot login. This may lessen the confusion. What’s your opinion?

    Many thanks in advance and happy new year to you all!

    Justin

  • Justin

    Hi Michael and Jude

    I have done some testing.

    I have logged onto the database and changed one of the members expiry dates back to 31st of December. When i logged off and viewed the member in the wordpress backend the expiry date had already changed again except this time the expiry date is 2nd Jan 2016 rather than the 1st Jan 2016. I still have no idea what is making this change however.

    I don't think the other custom development is responsible as it always changes the date to 31st December when it is triggered so 02/01/2016 does not meet this criteria. Any ideas?

    Thanks,

    Justin

  • Justin

    Hi Jude

    The user id is 344 .

    I had set the expiry date to 31/12/2014 at around 2100 hours i think.

    In Membership>news:

    [ 2015-01-02 : 20:16 ] ######### has moved from level Approved Member on subscription Affiliate Membership to level Approved Member on subscription Affiliate Membership

    20:15-20:16 is around when i made this change.

    Hope you can debug as I have not gotten around to making any of your suggested changes from our previous chat.

    Thanks,

    Justin

  • Justin

    Hi Jude

    I have been looking doing some research on issues which other might have had and found the following:

    https://premium.wpmudev.org/forums/topic/problem-with-renew-button-and-finite-vs-serial

    If you read the comments from Mon Aug 11 2014, 12:43:12 AM onwards. Tyler mentions that the payment gateway swapping may have caused the auto renewal that Kipp was experiencing. This is what is happening here. Might anyone know how that is resolved? I can't see how changing the payment gateway from admin to Paypal single payments might cause auto renewing. Any thoughts?

    Thanks

    Justin

  • Jude

    Hey Justin

    I can't see how changing the payment gateway from admin to Paypal single payments might cause auto renewing.

    It does not seem intuitive, I am not sure about this behaviour. I'll have to run some tests before I can say for sure.

    Might anyone know how that is resolved? I can't see how changing the payment gateway from admin to Paypal single payments might cause auto renewing.

    I just checked with Tyler to see if he is aware of a fix which can save us a lot of time. I will continue trying to find why the dates get offset in the meantime.

    And since the debug mode cannot be turned on the process becomes much slower. Do post back anything you find which may be useful in the meantime

    Cheers
    Jude

  • Justin

    Hey guys

    I have been doing loads of testing and it seems whatever I do, when the user has not renewed and the date is past the expiry date, the user is automatically moved onto the next level.

    I can see in other posts that other people have had the same problem when they have initially imported their members and set them to use the paypal single payments gateway.

    I do not want the members to automatically renew and this is what is happening even though no payment has been taken, because this is the first year of renewal on the site not many members have put their paypal details in. I was under the impression that the paypal single payments was not an automatic renewal option and it was an option where member can come and renew their membership manually – when testing this is the case until the expiry date is past..

    Please help as this is causing a huge problem for us.

    For now we need to change everyone who has an expiry date of 1/1/2016 to have an expiry date of 31/01/2015 – then I will have to manually go through the list of members who have paid and update theirs to show as renewed. Could you help us with a SQL query which would change the expiry dates for these members. We will give the members to the end of the month to renew their membership.

    The strange thing is when a member logs on before the expiry and renews their membership everything works fine, it is only once the expiry date has past that everyone randomly gets renewed.

    I found this post also which has a few contradictions:

    https://premium.wpmudev.org/forums/topic/please-clarify-how-to-configure-membership-renewals-not-auto-renewals

    The way Alexander Rohmann describes it initially seems like how it should go. Please help.

    Thanks,

    Justin

  • Justin

    Hi

    I am just going to ask the website owners how they would like it to happen. I know that a lot of their members paid by bank transfer and all sorts so this might actually suit ok. I will have to confirm with them if they are ok to manually deactivate the members who have not paid. I will see what they say.

    For now can anyone assist with a query which can update the 'expiry date' on the membership_relationships table? We still need to allow members the chance to renew for a while.

    Thanks in advance,

    Justin

  • Justin

    Hi all

    I was able to update the membership expiry dates with the following query i found in another post:

    UPDATE wp_m_membership_relationships SET expirydate = '2015-01-31 23:59:59' WHERE expirydate > '2016-01-01 00:00:00'

    This has updated them all and then i manually changed those who had actually renewed back to 2016-12-31.

    I think for now we can mark this as resolved. I think we will have a better idea next year how it is actually working.

    Many thanks

  • Jude

    Hey Justin

    Sorry for the delayed response, I was a bit busy with some personal work over the weekend. I've confirmed the gateway switch caused the weird behaviour with the dates I was afraid it was some of the custom code causing it and debugging would have been a nightmare.

    Although we have a stop gap fix I'm not sure if this is scalable in the long run. I was exploring ways of setting up your custom cron in a non conflicting way and also consulted with a senior dev here at wpmudev.

    I have posted back the solution in the other thread as it has more context there.

    Cheers
    Jude

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.