Site turned to free despite payment going fine through stripe

The Stripe payment went through on Feb 19th for this site https://sto....com/bombfirst1 and Pro Site logs shows that subscription was set to "Starter" level as expected. The site, however, was reverted to "non pro site".

Site's renewed until Feb 16th were handled fine.

  • Panos

    Hi Ben ,

    Apologies for the delay!

    We're still trying to find what is the cause of this. We could not replicate on our test sites. I would like do some tests which would include the creation of test sites (one or two max) to check original payments, then we will force expire them and do simulated payments to see how site responds and if the blogs get updated or not.

    For this we would require ftp access. You can send ftp info privately through our contact form: https://premium.wpmudev.org/contact/#i-have-a-different-question

    Send in:Subject: "Attn: Panos Lyrakis"

    and include:

    - Admin login:
    Admin username
    Admin password
    Login url

    - FTP credentials
    host
    username
    password
    (and port if required)

    - link back to this thread for reference

    Thanks!

  • Ben

    To make sure we are testing the same thing:

    1. Are you testing against all the stripe api's. The stripe shop owner can choose what stripe api version they are using. If pro-sites is not instructing the user as to what stripe API they should be using, then you shouldn't expect the user to change the stripe api version to the latest. I've never received any instruction from wpmu dev on what version of api should be used...so...i'm guessing this is an oversight.

    2. Are you testing sub folder vs sub domain installs

    3. Are you testing against subscriptions created with previous versions? If changes were made in how data is handled vs each version, is pro-sites updating legacy subscriptions properly?

    4. Is they data you are expecting being tested? Many times when i was helping debug...different data was received than expected which was causing issues.

    Please let me know if you have tested all these things before proceeding. Hopefully this matter is urgent as most people wont know it is happening and as a result wont even be reporting it to you.

    -Ben

  • Panos

    Hi Ben ,

    I have been doing some testing and indeed there needs to be some change when the latest version of Stripe (2018-02-28 or ) is used. In my tests I got an error message from stripe:

    Stripe plan some_plan_name does not exist

    Although I don't see you mentioning this here, I am attaching a file to replace.

    However I think it would be better if you could share admin and ftp access to do some testing. Could you also check that payment you received in Stripe dashboard and click on it. Then scroll to the Events section (at the bottom of the page) and click on the most recent event. In the page that loads it should mention the json sent in the "Events Data" section, it should look similar to this:

    You can include that information along with the admin and ftp access message. I have mentioned how to send this information privately in a previous reply, please do not share this information on the forum :slight_smile:

    Thanks!

  • Panos

    Hi Ben ,

    This is strange. I believe it might be related to version 2016-03-07, I haven't tested with this version.

    I can test do some tests on your site with versions 2018-02-28 and version 2017-08-15. I would set my test api keys temporarily and create some test sites using both versions. Then I will restore your live keys.

    For this I would need admin and ftp access as mentioned. In case you send this info in please follow instruction from previous post above to use our contact form.

    If this works with latest version then I will suggest to update :slight_smile:

    Thanks!

  • Panos

    I tested the file I have attached above with more sites using latest Stripe API version. So I would recommend to:

    1. replace that file :
    wp-content/plugins/pro-sites/pro-sites-files/gateways/gateway-stripe.php
    It is attached in a previous reply

    2. Update your Stripe API version. It think it offers an option to update version for a few days and you can restore back. Instead of updating I could provide you with my test keys with latest api to try. Please let me know so I could provide them.

    3. Make a few tests and see if sites are getting activated.

    Please let us know how this goes.

    Thanks!

  • Ben

    Lets debug this together!

    You need the file:

    to get to line 1218, so that it can run:

    case 'invoice.payment_failed' :
          $psts->log_action( $blog_id, sprintf( __( 'Stripe webhook "%s" received: The %s payment has failed. Date: "%s", Charge ID "%s"', 'psts' ), $event_type, $amount_formatted, $date, $charge_id ) );
           $psts->email_notification( $blog_id, 'failed' );
           update_blog_option( $blog_id, 'psts_stripe_payment_failed', 1 );
           break;

    Because it is not getting there...which means no failed email notification is being sent out...and then the blog stays active...what F'ing mess.

    Please review your code in the file:

    Line 1065
    $event_type = $event_json->type;
    so be checking that to make sure you are getting the data you expect.

    Line 1114
    if ( $blog_id || $domain ) {

    What would happen if blog_id is not set? How long has blog_id been set the way it is currently set? Will older subscriptions started from versions before be set the same way...whats the history on this. Also of note...where is $domain ever set? Whats missing here.

    Line 1131
    case 'invoice.payment_failed'
    I think this might be getting hit now, because a user knew her card was stolen and when she logged in she new to put her new card in.

    So if thats the case (we are guessing) why is line 1218 not getting hit? Is there a error in that case statment getting triggered causing a blind catch exception?

    or is there something in here that would have a condition causing an error?

    // Should be Stripe regardless if its a trial, we need the proper information returned later
                                    $gateway = self::get_slug();
    
                                    // ... but we should record that it is a trial.
                                    if ( $is_trial ) {
                                            ProSites_Helper_Registration::set_trial( $blog_id, 1 );
                                    }
    
                                    $amount_formatted = $psts->format_currency( false, $amount );
                                    $charge_id        = ( isset( $event_json->data->object->charge ) ) ? $event_json->data->object->charge : $event_json->data->object->id;
    
                                    if ( ! empty( $plan ) ) {
                                            $plan_parts = explode( '_', $plan );
                                            $period     = array_pop( $plan_parts );
                                            $level      = array_pop( $plan_parts );
                                    }
                                    if ( ! empty( $blog_id ) ) {
                                            /*      reset the waiting status (this is used on the checkout screen to display a
                                                    notice to customers that actions are pending on their account) */
                                            update_blog_option( $blog_id, 'psts_stripe_waiting', 0 );
                                    }

    line 1253:

    catch
                    ( Exception $ex ) {
                            $message = $ex->getMessage();
                            die( $message );
                    }

    why are we not writing this to a log file...? Or even the network admin email! Anytime this fails...this a a major problem deserving extra attention.

    This issue is still a major bug and needs to be addressed.

    Panos please reach out so we can chat about this further and get this fixed for everybody once and for all.

  • Panos

    Hi Ben!

    I apologize as I wasn't working yesterday.

    Panos, any progress or further information on this, failed credit card billings are still not being recognized by pro-sites as being failed.

    Is this new a issue for failed payments? When there is a failed payment, it should not expire the site instantly. It will expire on next check for expired sites. Has the expiration date of that site passed already but it still has a pro level assigned?

    Also, could you please create a staging/testing site where we can replicate the issues you report?

    Thanks!

  • Adam Czajczyk

    Hello @benmiskie!

    Thank you for your response. It would be best if you could just provide Panos with direct access to the site so he could test what is needed to be tested in a way he thinks is necessary. If it's not possible then, I guess, any type of additional testing data might be handy but we don't have any "special mail" for that. Therefore I messaged Panos directly (as he's not working today) and he'll get back to you here once he's back online for work so you could establish some sort of non-public communication/data handling between you.

    He'll be get back to you here as soon as possible.

    Kind regards,
    Adam

  • Panos

    Hi Ben ,

    As Adam mentioned it would be more helpful to figure out what is going on if we had admin and ftp access. Best option would be to use a staging site where this issue can be replicated.

    In case you still don't feel like providing access I'm afraid there isn't anything we can do as we can't replicate. Perhaps we can try checking some custom logs. I have prepared a mu-plugin the would create 3 custom log files in the mu-plugins folder. You can download that file from here:
    https://gist.github.com/wpmudev-sls/8a7bfc7ca5b1c9a2c6af358be0a0d172

    and upload it to your wp-content/mu-plugins folder (if that folder doesn't exist you can create it).

    Once you have added that file, each time you receive a payment from stripe it should create/update 3 log files that could possibly point to what is going on. These files are
    ps-stripe.log
    ps-stripe-raw.log
    and
    ps-stripe-subscriptions.log

    So when this happens again we can check those logs to see what is different.

    Thanks!

  • Ben

    Add me on Facebook and I'll glad work through the logic. I am pretty confident there is no conflicts, you I can check you setup to make sure your config matches and I can help you walk through the logic with the log file to see where the logic fail is.
    >> Without access it is hard to tell

    This is what needs go be done, what else would you be needing with system access? Is there something I'm missing?

  • Panos

    Hi Ben!

    I am checking the logs but I would need to know if you have some specific blog_id that did a successful payment but it did not extend the pro level. Also date and time of payment if possible :slight_smile:

    what else would you be needing with system access?

    Since payment issues can be quite complex and do several checks in order to allow or disallow extension, we create test users with test subscriptions (test blogs) and send in test payment notifications (similar to what Stripe would send) to the payment gateway webhook. Each time we send we can follow the path via ftp and check where it fails. For example it retrieves no blog_id because the customer or subscription id are different. That was just an example.

    Add me on Facebook and I'll glad work through the logic.

    I'm sorry we don't work through Facebook

    I can check you setup to make sure your config matches

    We can't share access to our test sites. Also it might be related with changes made in time that have affected records in db not matching stripe info. We can't replicate this in a different system unless we copy db.

    Kind regards!

  • Ben

    I am checking the logs but I would need to know if you have some specific blog_id that did a successful payment but it did not extend the pro level. Also date and time of payment if possible

    Here's the frustrating part...I've given this information to you in the form of a screenshot that includes the pro-sites billing page showing the blog id, stripe subscription, stripe user id, shows that the prosites level is at 0, shows the date went through...all the good stuff needed to isolate the data to be reviewing in the logs and then manually simulating that posted data to see where the gap in logic exists in pro-sites....when I didn't see any action on this after a couple weeks...I re-followed up with the tech agent and delivered that information again.

    To my horror, if you are not getting this from the standard wpmu dev communication...then we need to figure something else out. I've been finding pro-sites update issues for a while now..and clearly no debugging on these issues I am finding are happening...so was suggesting a way around the road blocks...because i we could get this done fairly quickly in the debug method I am suggesting...I highly doubt this is a plugin conflict.

    So...if your tech support guys aren't giving you the necessary information I am repeatedly giving you, and given this is silently happening with no notification of the fails...making it a pretty dangerous bug...can you please suggest an alternative to me helping you and giving you the necessary information to debug. I clearly can't give you this information publicly.

  • Panos

    Hey Ben ,

    It was my fault! So sorry for missing it, I focused on the logs links that I didn't pay attention.

    Your screenshot is about blog_id 113 and payment made on June 4th

    Of what I see the payments for blog id 113 are failed from Stripe. You can confirm by checking the file ps-stripe-raw.log or for more clear results file ps-stripe.log. You will see that the event type is set to failed:

    event_type : invoice.payment_failed

    You can search using the browser search (ctrl+f) for 113. There will be several instances you will find, we focus to the invoice payment events. Eg on [ 04-06-2018 18:40:14 ] there is a failed payment for 113.

    Stripe continues though to try to repeat the payment a few times. There seems to be a successful payment on
    [ 06-06-2018 07:56:08 ] :
    "type": "invoice.payment_succeeded"

    So this should have activated the blog.

    What confuses me is that I see it has sent another failed payment notification on the next day
    07 Jun 2018 18:40:36

    If the blog is not active I assume that either the success payment didn't activate the blog on
    [ 06-06-2018 07:56:08 ]
    or that the blog was activated but the failed payment did expire it again on
    [07-06-2018 18:40:36]

    I tried to exclude either of the above in a test site of mine. But by expiring manually a site and re-sending a success request does reactivate it. Also when resending a "payment failed" request it doesn't expire the level.

    I'm afraid I can't think of anything else to suggest to try. Only way is to do similar request on your site and monitor what is happening on each request.

    Kind regards!

  • Ben

    Panos
    1) To clarify, i want to make sure and re-confirm you understand that i have opened other requests, and adam has requested that the conversation be limited to this one thread.

    For this most recent specific scenario, are you understanding that this scenario is that single user has TWO separate paid pro-site blogs created on different dates. Are you testing against this scenario or only a user with 1 blog

    2) You describe the scenario where a few fails occur, then a succeed, followed by a fail.

    So lets map that to a possible user action which would be VERY VERY common in subscription scenarios:
    1. Card is stolen or expired
    2. Next charge fails
    3. User logs into account after seeing fail email
    4. A shitty dialog appears....why shittty? Because instead of one simple primary step of allowing the user to maintain their subscription by simply adding updated card info to update their last ACTIVE subscription for the blog, they are forced to choose a new subscription for no reason further confusing them. Dumb dumb dumb. And more dumb :slight_smile:
    5. The user then enters in new card info, and a chooses a NEW subscription, to reactivate their site with
    6. Their site is re-activated. So now a NEW GOOD active subscription exists for blog ID X, and a secondary BAD subscription exists for blog ID X still floating around in the world not fully killed.
    7. Bad Stripe subscription, hearing no commands about what to do about its status, posts to blog X a message that the subscription for blog x is expired and changes the blog level to 0.

    Is this the correct set of events? Just want to make sure we are on the same page.

  • Ben

    Other notes, my user, as mentioned before has 2 blogs, blog 70, blog 113

    1) Reviewing the billing page on each site reveals that instead of there being one stripe customer id owning 2 subscription id's, there are instead different customer id's assigned to each blog with their own subscription id.

    2) through a support tech Nahid I have sent you screen shots of the 2 different customer ID information from stripe dashboard to show the various entries and times needed to help debug the logic/architecture of pro-sites. As you can see, possibly additional confusing data was sent to stripe when a logged in user tried to make a secondary blog in their account, so that process needs to be debugged as well for pro-sites logic errors (that i posted about possibly in another thread)

    I understand you didn't write this code, or the logic and you are just assigned to fixing it. There is a lot to fix, I hope you can get it done once and for all.

  • Panos

    Hi Ben ,

    Still can't replicate. I could replicate the issue which you describe here :
    https://premium.wpmudev.org/forums/topic/pro-sites-second-blog-sign-up-issue
    and there should be a patch for that one soon. I will update that thread soon.

    You can create more than one sites when either session expires or you use a different browser or incognito mode.

    After creating multiple sub-sites we still could not replicate this. Sites would be extended. I am testing this by sending json requests similar to the ones you have on your log files, but I replace dates, levels and blog ids.

    I think that there is nothing else we can check on our sites, at least nothing I can think of. Perhaps it's time to share admin and ftp access so we can check at which point this gets stuck on your site.

    Kind regards!

  • Ben

    Panos

    Are you using the screen shots to work backwards or simply just trying to replicate from a clean install?

    >> 4. A shitty dialog appears....why shittty? Because instead of one simple primary step of
    >> allowing the user to maintain their subscription by simply adding updated card info to
    >> update their last ACTIVE subscription for the blog, they are forced to choose a new
    >> subscription for no reason further confusing them.

    Did you see #4 above, is the scenario that happens to subscription after step 4 that I described going to create a possible problem that you are not re-creating in your test scenario....?

    Is scenario #4 being fixed? That is a bug that needs to be addressed.

  • Ben

    Panos
    >> I think that there is nothing else we can check on our sites, at least nothing I can think of.
    >> Perhaps it's time to share admin and ftp access so we can check at which point this gets
    >> stuck on your site.

    Can we agree that the bugs I have found are in no way specific to my site and will be happening to everybody using pro-sites and stripe?

    I do want to give access, but monitored and through dialog. I have clearly demonstrated issues that have been missed in terms of logic that the QA team and developers have missed. I've offered to do direct chat to lower the latency/frustration of this conversation but repeatedly been told "that's not the way things are done"

    The way things are done has now officially caused this issue to continue to extend longer than necessary for all customers, so perhaps the policy needs to be adjusted when a customer like me is finding the the bugs and will to help.

    I had been hacked one time, to mitigate future threats, I have no ftp set up on my server only ssh. I have ssh login limited to the keys, so i have turned off user/pass login.

    I could turn it on briefly but can't BLINDLY leave stuff open while somebody goes in there with no timeline and nobody monitoring as I had before when giving access to WPMUdev.

    So I agree I would like to be in more direct contact and help you replicate and work through the issue as I have a vested interest in making this work. I could "open up the gates" and close the gates in a monitored method, but to do that you need to directly contact me and have us set up a time not in a public forum.

    I hope that sounds fair, you should have my email on file to set up more direct contact.

    Thanks!

  • Ben

    Panos please check with Rupok, I just sent him alot of different screenshots and private data directly on the stripe dashboard, just ran a test by creating another site with the same user using a new card...didn't go well. Depending on how old users were created prior to your updates, that could be a source of the issue. Also could be the issue is you are indexing on a customer id instead of subscription ID at some point in the logic...? I don't know, but please review the screen shots and notes delivered, you will see that when logged in as the user and trying to create a new paid blog, the payment went through, but the confirmation page didn't show, in the new blog's network admin payment logs it doesn't show subscription information, and when reviewing the stripe dashboard data, the payment was fraudulently made on the card already on file and not on the card that was typed in. Luckily i know this customer very well and he can be forgiving, but this is a big problem if i didn't know him very well.

    So review the notes given to Rupok and lets work on getting this right. I only have one customer at the moment wanting multiple blogs, so I can manually repair this stripe customer account if instructed on how to if that is the cause of all this because of the previous actions of the plugin.

  • Panos

    Hey Ben!

    It doesn't seem that the part where it check for the customer_id only does affect anything. I am using the exact same response from stripe in my test that is included in your logs, of course modified dates, and ids

    That response includes the correct blog id.

    I am now thinking of a change that seems to be working with this response. But I need to tests with more payments and discuss with main dev how can this have side-affects and cause other issues.

    I'll keep you updated.

    Thanks!

  • Ben

    Are you testing with new payment sources or the same payment source? Are you testing against a customer who's blog was expired and then they had to add a new payment source which then created a new stripe customer when it shouldn't adding to data confusion in the event that stripe is able to re-activate a card on an older subscription...many scenarios here.

    I'd like to work directly with you on helping with testing and review, but my hands seemed to be tied which is difficult.

  • Panos

    Are you testing with new payment sources or the same payment source?

    In my tests I am using a modified version of the invoice.payment_succeeded so I have my Stripe plan info., cusch as custome id and dates to not be in the past. Before I send this test request to the webhook url, I change the customer_id and subscription_id that is stored for that blog in my db.

    Initially the payment does fail to extend the blog, but the subscription_id and customer_id get corrected in the db so they now match the new ones.

    With this, I understand that by changing the customer payment source, it would not make any difference.

    Before making that change I mentioned (in my previous reply) in stripe file, I would suggest to make sure that the subscription info stored in db is in sync with the ones in stripe just to make sure.

    What we need to make sure that match are the customer and subscription ids. I have attached here another mu-plugin. This should show you the current customer and subscription id that is stored in the db for each blog. You can see this info in the blog's "Manage Site" page, eg for blog 113 :
    site.com/wp-admin/network/admin.php?page=psts&bid=113

    In case they are not the same with the ones in Stripe please first copy them somewhere safe, then insert the correct ones and click on the "Change Stripe Info" button.

    In case you have not extended that site manually, I can provide instructions on how to send the Stripe request via curl, or I can prepare another mu-plugin for this to check if this change would make any difference.

    Kind regards!

  • Ben

    Panos

    In my tests I am using a modified version of the invoice.payment_succeeded

    Just to re-clarify, even though this thread is titled "SITE TURNED TO FREE DESPITE PAYMENT GOING FINE THROUGH STRIPE" we are possibly dealing with more than one problem leading up to this issue:

    1. When somebody signs up up for a new blog, and the user a different credit card than previously, that may create unintended consequences during sign up, and when a future payment attempt is made because of the customer profiles set up wrong on the stripe side. This needs to be tested, have you tested this thoughroughly and are you getting the correct stripe customer accounts you are expecting?

    2. If a user's account was previously set up on an OLDER version of pro-sites, and then the network operator updates to a newer version of pro-sites, will the new version of stripe be accounting for that.

    3. (ALOT OF Variables here) If a user's account was previously set up on an OLDER version of pro-sites, and then the network operator updates to a newer version of pro-sites, and then the person's onfile credit card fails to the point where the subscription on the wordpress side cancels, hower the stripe side (DOESN'T cancel yet and is still in process of its re-attempts or DOES Cancel because too me re-attempts), and then the user logins, and adds the new card (replacement visa card OR different card all together like an american express) and then they either choose (the same subscription or a different subscription) what happens on the stripe side: is a new customer account created, is the same subscription active or killed, is a new subscription created on the same customer or is a new customer created, is the old payment source removed. ALL of these factors are needing to be tested so we can have a baseline and conditions be set up to correct things.

    Stripe plan info., cusch as custome id and dates to not be in the past. Before I send this test request to the webhook url, I change the customer_id and subscription_id that is stored for that blog in my db.

    Initially the payment does fail to extend the blog, but the subscription_id and customer_id get corrected in the db so they now match the new ones.

    I'm not following..

    I would suggest to make sure that the subscription info stored in db is in sync with the ones in stripe just to make sure.

    Just let me know what to look for and do.

    What we need to make sure that match are the customer and subscription ids. I have attached here another mu-plugin.

    I dont see an attachement...

    In case they are not the same with the ones in Stripe please first copy them somewhere safe, then insert the correct ones and click on the "Change Stripe Info" button.
    
    In case you have not extended that site manually, I can provide instructions on how to send the Stripe request via curl, or I can prepare another mu-plugin for this to check if this change would make any difference.

    I am still confused how to proceed, maybe because there is no attachment?

  • Panos

    Hi Ben!

    Thanks again for all this info! And so sorry for not attaching the file, I attached it here.

    You don't really need to be going to chat each time, you can update here (unless you need to send some private info).

    This is not the normal case regarding Pro Sites and has been reported only once more just recently as there was some custom subscription creation via Stripe.

    I know you are wondering about the different credit cards used. Pro Sites doesn't check credit cards. Stripe does the payments automatically and it then sends a notification to the webhook url. The subscriptions that are created via Pro Sites checkout contain the blog_id in Stripe subscription meta and this blog_id is included in the notifications sent after payment.

    So only things that matter here are if the blog_id is present and if not, if the proper customer_id and subscription_ids are present. By proper I mean that they match the ones in the Stripe table. In case they don't match, Pro Sites will try update them in the table if blog_id is present in notification.

    I have sent you via email instructions on how to re-send those notifications if you would like to test your self. It might be a bit complicated so I have also attached file :
    pro-sites/pro-sites-files/gateways/gateway-stripe.php
    which should be updating the blogs normally if you would prefer to wait until next payment.

    You did ask several things in your previous reply, I'll try keep it short:

    1. As I have already mentioned, what matters is that the correct customer_id and sebscription_id are stored in Pro Sites db table for the specific blog. You can modify that table directly or use the mu-plugin I attached here.

    2. It doesn't make any difference on which version of Pro Sites is used.

    3. Again the Pro Site version doesn't affect. Changing the cc on Stripe though and creating new customer should affect. That's why I have attached the mu-plugin which you can check if they match and insert the correct ones.

    Kind regards!

  • Ben

    Panos

    Please re-review blog 115 (the newest one)

    Notice in subscription information it says: This site is using different gateway so their information is not accessible.

    The information i sent to Patrick Freitas contains the subscription id and customer id that should be associated with this blog. And the subscription is showing the blog_id 115 in the meta data.

    Your mu plugin wont update because I a guess the creation in the pro-sites table didn't happen because of another pro-sites bug when creating this site. So that will somehow need to be created...which I can do manually or should you review it to see if it is revealing another bug that you might be unaware of.

    Thanks

  • Ben

    Reviewing ps-set-gatway.php, line 82:

    $sql = "UPDATE {$wpdb->base_prefix}pro_sites_stripe_customers set customer_id='%s', subscription_id='%s' WHERE blog_id=%d";

    Wouldn't work if there is no row ever set in the first place...right?

    So just for fun, I also used phpmyadmin to insert the row without needing to code the fix...except getting this error when attempting to insert the stripe customer and subscription.

    "Duplicate entry for 'cus_kjsdlkjslkdj' for key 'customer_id'

    Why is customer_id the key...a customer_id can have multiple subscriptions. the key should be blog_id....right...?

    This is dragging on and on...can we get some urgency here?

  • Ben

    pro-sites-files/gateways/gateway-stripe.php, line 1509:

    public static function set_customer_data( $blog_id, $customer_id, $sub_id, $domain = 'deprecated' ) {
                    global $wpdb;
    
            //If we have blog id update stripe customer id for blog id otherwise store in signup meta
            if ( ! empty( $blog_id ) ) {
                $sql = "INSERT INTO {$wpdb->base_prefix}pro_sites_stripe_customers(blog_id, customer_id, subscription_id) VALUES (%d, %s, %s) ON DUPLICATE KEY UPDATE customer_id = VALUES(customer_id), subscription_id = VALUES(subscription_id)";
                $sql = $wpdb->prepare( $sql,$blog_id, $customer_id, $sub_id );
                $wpdb->query(  $sql );
            }
    }

    I could be wrong...but I am guessing...if there is no blog_id (ie...maybe a new blog situation...ehhh...) then it will see the customer_id and then update the record containing the same stripe customer_id with the new subscription. But...that would mess up the billing for the other blog a user has already set up (which seems to be the mystery bug i describe over and over again)...so...whats going on here....hmm

  • Panos

    Hi Ben ,

    I apologize for this taking so long to get resolved!

    We can't do proper testing though since we don't have access and this has to do with the delay too. I hope for your understanding :slight_smile:

    Could you please check if the customer_id is set as unique for that table? It should not be, not sure why this happened in your db, but it seems wrong. You can check via phpmyadmin or add a snippet like the following in some action:

    global $wpdb;
    
      $table = $wpdb->base_prefix . 'pro_sites_stripe_customers';
    
      $q = "select distinct CONSTRAINT_NAME
    from information_schema.TABLE_CONSTRAINTS
    where table_name = '{$table}' and constraint_type = 'UNIQUE';";
    
      $r = $wpdb->get_results($q);
    
      error_log('$r :: ' . print_r( $r,true ) );

    If you have debug logging enabled you should see the output of the above snippet in your debug.log file. It should contain only the subscription_id.

    When calling the set_customer_data() the blog_id should be already set. It retrieves the activation key and creates blog based on that.

    Did you test what I mentioned in my last email? It could be a bit tricky but let me know if you need further guidance there.

    Kind regards!

  • Ben

    We can't do proper testing though since we don't have access and this has to do with the delay too. I hope for your understanding

    I mean...we have the same code...but blame your boss...he doesn't want us to work directly together to avoid security concerns. Also fyi password doesn't work for me on the test server.

    Could you please check if the customer_id is set as unique for that table? It should not be, not sure why this happened in your db, but it seems wrong.

    I'm scratching my head...as i 2 posts ago I showed you the database is indeed set to have customer_id as a unque key and then I showed you the code in the following post that would fail everytime a secondary entry with the same customer id would be attempted.

    I know you didn't originally write this codebase...but it looks like the guy before you messed up with how the original database table was created in a previous version? You can review my previous threads on pro-sites and you will see lots of other little bugs. So perhaps you should review older versions of this plugin, figure out where in your git repo there was a change to how the database was created and track down what other errors could be a result.

    Did you test what I mentioned in my last email?

    I didn't test because I found this bug and can confirm this will create problems at the code snippet i found, and I want to do one thing at a time.

    So can you suggest what you want me to do for the database fix. Or perhaps you want to write a plugin to check database set up, and then fix database as if I have this problem, so can other customers that were using the plugin when it was creating bad database tables.

    We can't do proper testing though since we don't have access and this has to do with the delay too. I hope for your understanding

    Forgive me...but I'm not understanding why you can't go on chat and work this out with me. You can understand why I have this higher level of security. And again, you have access to older versions of the plugin, so you have to keep in mind people didn't start with a fresh install on this plugin.

    Hope to hear back today on how you want to handle the database, but that error i found could be one of the issues.

  • Ben

    Also while I have your attention, couple cosmetic requests:

    Please add placeholder data to the form fields for when people are doign their registreation in:

    pro-sites-files/lib/ProSites/View/Front/Registration.php:

    the field user_name should have the attribute placeholder="User Name"
    the field user_email should have the attribute placeholder="E-Mail"
    the field blog_title should have the attribute placeholder="Website Title"

    pro-sites-files/lib/ProSites/View/Front/Gateway.php:
    Please add "id" attributes to the div tags

    Doing these cosmetic changes will allow for more customizations via css for developers. Thanks.

  • Ben

    really want to get things moving here...suggestions on what to do next...? I am guessing the goal is to make things look like the table set up in screenshot Screen_Shot_2018-07-04_at_4.05.35_PM.png

    So in the screen shot:

    Screen_Shot_2018-07-04_at_3.38.08_PM.png

    Can I drop:

    customer_id, customer_id_2, customer_id_3, customer_id_4, customer_id_5, customer_id_6, ix_customer_id

    And any other suggestions you have please let me know...but trying not to wait too long here...

  • Ben

    So i moved forward and did it, seems okay.

    however for the network with this screen shot:

    Screen_Shot_2018-07-04_at_3.58.37_PM.png

    I was having trouble as I needed to add the unique key for the subscription_id....but couldnt. As i reviewed the data...some entries have customer_id's but no subscription_id. So perhaps in a previous version if there was a subscription ID that was cancelled, it would make then field empty.

    Now that would work on one...but what happens when number 2 would be removed...database error as that would not be unique...

    So on the flip side...if there are some entries and a bunch of them are set to empty from a previous version, then you can not update the database to this field to have a unique key as that would create an error because of the multiple entries existing with the empty subscription id.

    So as you craft a solution, be advised of these two situations.

  • Ben

    Regarding the placeholders, we will include that in next release

    Great, that saves me time. Also dont forget giving your div tags ids so people can style them.

    Sorry for the big delay here. I'm investigating your issue now. Somehow your Stripe subscription table has messed up. 4 is the blog ID that I should check right?

    Joel ..hopefully you are "joking" and have read the thread in its entirty.

    Panos are you no longer addressing this?

  • Ben

    Joel

    Please review the thread backwards. In addition to whatever issues panos has found, what I have discovered is the way "pro_sites_stripe_customers" table is set up now...is not the way previous developers had set it up. As a result this is causing problems for people that installed the plugin in its earlier forms, which is then causing issues. Please review the investigation I have performed. I have manually fixed 2 of my networks using pro_sites_stripe_customers table to match the current expected table setup that is in the plugin now. However the way things are set up now I have not fully investigated. So you will need to write a script to help customers check to see if the database matches the current expected database, and if it doesn't figure out a script to fix it. In addition you have a key being set on the subscription_id column, which means it will reject an updated or insert on anything that row that has that field empty. Something to keep in mind.

  • Joel James

    Hey Ben,

    Thanks for the reply. Panos is on leave for a few days and I will be following up on this.

    Sorry, but I read your previous replies and just wanted to see the current situation of the blog by reviewing the Pro Sites dashboard. That is why I asked for the support access.

    We will figure out this and include an upgrade script in next release if it is required to update the stripes database table for the old installations.

  • Ben

    Joel

    if it is required to update the stripes database table for the old installations

    Really encourage you to read the thread especially the end part, i did all the debug work for you, took a ton of time to find it. So hopefully it will not go to waste, this is a confirmed issue.

    I see where you were getting blog 4(seems so long ago), that looks to be resolved now and billing seems to be going through normally.

    Adam requested all pro-sites issues to be consolidated here which is why I did all the responses regarding : https://premium.wpmudev.org/forums/topic/pro-sites-second-blog-sign-up-issue?replies=5#post-1330153

    In this thread. So the main issue I was worried about now, and what panos and I were working on recently, and debugging was the issue of of one user signing up for a multiple blogs and then the billing having bugs.

    I see the confusion, so hopefully that makes sense now as to what I am wanting to address.

  • Ben

    Joel

    Was reviewing a prior version of pro-sites: 3.5.0.4 and found this code:

    if ( ! defined( 'DO_NOT_UPGRADE_GLOBAL_TABLES' ) || ( defined( 'DO_NOT_UPGRADE_GLOBAL_TABLES' ) && ! DO_NOT_UPGRADE_GLOBAL_TABLES ) ) {
    			require_once( ABSPATH . 'wp-admin/includes/upgrade.php' );
    			dbDelta( $table1 );
    
    			//3.5 upgrade - modify pro_sites table
    			if ( $psts->version <= '3.5' ) {
    				//Using dbDelta instead
    				// $wpdb->query( "ALTER TABLE {$wpdb->base_prefix}pro_sites_stripe_customers ADD subscription_id char(22) NOT NULL" );
    				// $wpdb->query( "ALTER TABLE {$wpdb->base_prefix}pro_sites_stripe_customers DROP KEY ix_customer_id" );
    				// $wpdb->query( "ALTER TABLE {$wpdb->base_prefix}pro_sites_stripe_customers ADD UNIQUE KEY ix_subscription_id (subscription_id)" );
    			}
    		}

    So I guess they were aware of upgrading the issue...but have it commented out maybe?

    In addition, this line:
    $wpdb->query( "ALTER TABLE {$wpdb->base_prefix}pro_sites_stripe_customers ADD UNIQUE KEY ix_subscription_id (subscription_id)" );
    Would it fail if the database has multiple rows where subscription_id has empty fields?

    I think thats where the failure existed. I manually fixed the database, but for others this might be the source of problems.

  • Ben

    Cool, all good on my side as a manually fixed. Thanks Joel also heads up if possible, i probably said it somewhere else...but in your next release make sure to pay attention to div's that lack id's/classes, form fields that lack placeholders, mobile styling, and perhaps a filter/hook on the "completition" page so that its possible to further customize the user experience for their on-boarding.
    Thanks Joel

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.