Rerpoting Fatal Errors with new version of Pro Site

Umesh Kumar

Using the new version of pro-sites on my more major network, the better error reporting you have placed in the plugin is revealing some compelling errors. Please review.

PHP message: PHP Fatal error: Call to a member function retrieve() on a non-object in /home/wordpress/public_html/wp-content/plugins/pro-sites/pro-sites-files/gateways/gateway-stripe.php on line 3339" while reading response header from upstream, client: 107.170.204.135, server: networkdomain.com, request: "POST /wp-cron.php?doing_wp_cron=1467097354.3985249996185302734375 HTTP/1.0", upstream: "fastcgi://unix:disappointed:var/run/php5-fpm.sock:", host: "www.mappeddomain.com"
2016/06/28 07:02:35 [error] 2773#0: *2237193 FastCGI sent in stderr: "PHP message: Stripe Notice: Undefined property of Stripe_Customer instance: subscriptions
PHP message: PHP Fatal error: Call to a member function retrieve() on a non-object in /home/wordpress/public_html/wp-content/plugins/pro-sites/pro-sites-files/gateways/gateway-stripe.php on line 3339" while reading response header from upstream, client: 162.211.147.84, server: networkdomain.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:disappointed:var/run/php5-fpm.sock:", host: "www.mappeddomain.com"
2016/06/28 07:02:41 [error] 2773#0: *2237198 FastCGI sent in stderr: "PHP message: Stripe Notice: Undefined property of Stripe_Customer instance: subscriptions
Going to this mappeddomain.com url no longer shows the site, here are the error logs:

PHP message: PHP Fatal error: Call to a member function retrieve() on a non-object in /home/wordpress/public_html/wp-content/plugins/pro-sites/pro-sites-files/gateways/gateway-stripe.php on line 3339" while reading response header from upstream, client: 207.46.13.72, server: networkdomain.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:disappointed:var/run/php5-fpm.sock:", host: "www.mappeddomain.com"

Made some non related updates to code, so line 3339 refers to:

$subscription = $customer->subscriptions->retrieve( $sub_id );

located in the function:
public static function get_blog_subscription_expiry( $blog_id ) {

In addition seeing other errors being logged:

2016/06/28 06:57:22 [error] 2772#0: *2237117 FastCGI sent in stderr: "PHP message: Error in /home/wordpress/public_html/wp-content/plugins/pro-sites/pro-sites-files/gateways/gateway-stripe.php at line 3343Customer cus_XXXXXXX does not have a subscription with ID sub_XXXXXXXX" while reading response header from upstream, client: 162.211.147.84, server: actorgear.com, request: "GET /subblog/wp-admin/index.php?wdeb_off HTTP/1.1", upstream: "fastcgi://unix:disappointed:var/run/php5-fpm.sock:", host: "networkdomain.com", referrer: "https://networkdomain.com/subblog/wp-admin/"

where 3343 refers to:

error_log( "Error in " . __FILE__ . " at line " . __LINE__ . $e->getMessage() );

Thank you

  • Rupok

    Hi Ben, hope you had a wonderful day.

    I am running the latest version of Pro Sites on my test site but I didn't face any of these fatal errors. Can you please confirm which PHP version you are using? I can see that you are using a beta version of Pro Sites. Can you try installing a stable version and check if the issue is still there?

    I'm still pinging Umesh Kumar as he can give you best feedback on this. Please keep in mind, our developers work round the clock and they have to deal with lots of critical issues and other things. So it may take a little while for them to check this and provide a feedback.

    Have a nice day. Cheers!
    Rupok

  • Ben

    He's placed more errors for debugging. You also wont be able to replicate the errors with out the same older stripe subscription data which is causing the possible issue.

    That said the errors are revealing that work needs to be done on the retrieve function to catch the errors so that it doesn't cause a fatal error to the site.

    This is on an expired subscription, i was able to manually extend the users subscription by 2 days which now got the site online instead of a fatal error.

    I'm going to sleep, look forward to what umesh finds. Hopefully more error try/catch can be to help with the retrieve issue and with other unexpected data from subscription methods possibly left over from earlier versions of pro-sites

  • Ben

    Just a little overview and check list of problems we are running into:
    1. FIXED account with a single subscription that had expired being able to be paid to a pro-site
    2. NOT FIXED account with 2 subscriptions being able to take a live subscription and upgrade it to a different plan
    3. NOT FIXED Applied Coupon not being applied after payment is completed in stripe for an account with 1 subscription that had previously expired.
    4. NOT FIXED Conflict with WP User Avatar plugin (IS_USER_LOGGED_IN conflict) https://premium.wpmudev.org/forums/topic/is_user_logged_in-conflicts-with-pro-sites-and-other-issues

    5. Additional styling/bug issues with fixes (wish we had some sort of bitbucket or github action)
    In my opinion, it is somewhat difficult to style pro-sites and the ordering of the sign up, here are some minor suggestions.

    A. The blog_title Field should be re-ordered so that it comes before the blogname field
    B. In the following files:
    pro-sites-files/lib/ProSites/View/Front/Registration.php
    the function: private static function render_user_section

    after the line: if( ! is_user_logged_in() ) {
    Should have the following line inserted:
    $content = '<div id="pro_user_section">';
    then $content above the if should be instead set to:
    $content = '';
    At the end of the respective "if" block mentioned should be the closing of the "div"

    This enables us to style this user block. There is no reason for the div block to be created if the user is logged in hence the change in code for the div.

    In addition for this block of code, place holder attributes should be set, ie:
    $content .= '<input name="user_name" type="text" id="user_name" value="' . esc_attr( $user_name ) . '" maxlength="60" placeholder="User Name" />';
    and
    $content .= '<input name="user_email" type="email" id="user_email" value="' . esc_attr($user_email) . '" maxlength="200" placeholder="E-Mail Address"/><br />';

    in the function: private static function render_blog_section
    The div should be given an ID, ie:
    $content = '<div id="prosite_blog_section">';
    The fields blog_title, blogname should be given place holders, ie:
    <input name="blogname" type="text" id="blogname" value="' . esc_attr( $blogname ) . '" maxlength="60" placeholder="enter-temp-name" /></div>';
    $content .= '<input name="blog_title" type="text" id="blog_title" value="'.esc_attr( $blog_title ) . '" placeholder="Website Title" /></div>';

    pro-sites-files/lib/ProSites/View/Front/Gateway.php
    Add div blog to surround the account data after a user signs up, ie:

    $content .= '<div class="aftersignupbox">'; //ben
    $content .= '<p><strong>' . esc_html__( 'Your login details are:', 'psts' ) . '</strong></p>';
    $content .= '<p>' . sprintf( esc_html__( 'Username: %s', 'psts' ), $username );
    $content .= '<br />' . esc_html__( 'Login URL: ', 'psts' ) . '<a href="' . esc_url( $blog_admin_url ) . '">' . esc_html__( $blog_admin_url ) . '</a></p>';// ben ben gear
    $content .= '</div>'; //ben

    pro-sites-files/gateways/gateway-stripe.php
    Additional question:
    in public static function create_transaction_object

    I see the line:
    if ( empty( $customer_id ) && isset( $line->customer_id ) ) {
    From other bugs I've seen in Pro Site from the previous developer, there seems to be some confusion between the use of 'customer' vs 'customer_id' being that 'customer' is a standard stripe variable in the stripe data with a that can contain a person's "customer id" however 'customer_id' as a stripe variable is NOT a standard in the stripe data. Please review the docs to confirm this, and correct me if I am wrong. Maybe the previous developer used 'customer_id' in some meta data, idk, but there is still confusion on the code with this issue that needs to be addressed. As an example I have mentioned this confusion and a bug attributed to this many months ago, but it appears in the latest beta and is still not addressed. Reviewing:

    if ( $from_sub ) {
       $subscription = $object;
    }

    Then later you attempt to use the line:
    $customer = Stripe_Customer::retrieve( $subscription->customer_id );
    HOWEVER...." $subscription->customer_id " does not exist creating immediate failure.

    Months ago I suggested the following code change:

    if ( $from_sub ) {
       $subscription = $object;
       $subscription->customer_id   = $object->customer;  // BEN BANDAGE FIX
    }

    but you should also consider the follow fix and reviewing your code for other locations of this occurring:
    $customer = Stripe_Customer::retrieve( $subscription->customer_id );
    vs
    $customer = Stripe_Customer::retrieve( $subscription->customer );

    In addition, please review this code fix I have found important, in the function:
    public static function get_subscription
    sometimes the blog_id is not being retrieved causing issues, so i wrote a fix:
    Just after this code block:

    // Get fields from subscription meta
    
    // 3.4
    $parts  = explode( '_', $subscription->plan->id );
    $period = (int) array_pop( $parts );
    $level  = (int) array_pop( $parts );
    
    $subscription->period     = ! empty( $subscription->metadata->period ) ? $subscription->metadata->period : $period;
    $subscription->level      = ! empty( $subscription->metadata->level ) ? $subscription->metadata->level : $level;
    $subscription->activation = isset( $subscription->metadata->activation ) ? $subscription->metadata->activation : false;
    $subscription->blog_id    = isset( $subscription->metadata->blog_id ) ? (int) $subscription->metadata->blog_id : false;

    Insert the following:

    global $wpdb;
    if ( empty( $subscription->blog_id ) ) { // ben start
         $subscription->blog_id = $wpdb->get_var( $wpdb->prepare( "SELECT blog_id FROM {$wpdb->base_prefix}pro_sites_stripe_customers WHERE customer_id = %s", $subscription->customer_id ) ); // ben
    } // ben

    ...unless the people running pro-site websites are combing through their logs...nobody knows these issues are happening...Lets get this working. I hope these fixes help in identifying the issues. I'm on your team Umesh Kumar , let me know what you think about these changes. In addition, still looking to hear back on the issue with the user avatar conflict, can't seem to locate the source of the change that occurred in pro sites for that conflict.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.