[Pro Sites] Manually activating a Pro Site with activation key sends wrong password

We're having a big problem with cart abandonment in Pro Sites. A user makes it to the Credit Card screen, decides not to input the credit card, and calls us directly to express discontent about having to add a credit card to a free trial and asks us to manually activate the trial. Which, of course we want to oblige.

So, we go through the very complicated process of digging into the database and finding the activation key for their sign up, and then we to go Pro Sites > Manage and use the Activate with key form field.

This activates the site and sends a user their welcome email along with their login and password. The problem is, Pro Sites sends them the wrong Login password credentials.

I can reproduce this on all sites using Pro Sites in our family of sites. I have created a video that demonstrates what's happening, step by step.
https://www.youtube.com/watch?v=Jgy3BYx4MsQ

  • Patrick Freitas

    Hi Blue,

    Sorry to hear about this issue,

    Thank you for the feedback, I had a close look and we were able to replicate the issue. I’m reporting to the developers and they will send, if we have any hotfix about it.

    However if any update comes up for ProSite, you can create a backup of your site and update it. In any case you can use Automate to performance that.
    https://premium.wpmudev.org/blog/tag/automate/

    Have a nice day
    Best Regards,
    Patrick Freitas

  • blue

    We've been digging into this over the past couple of days. Our research is leading us to believe it could possibly be a filter issue.

    In register.php and pro-sites.php you guys are using update_welcome_email filter to in several places. Initially this felt like wordpress was generating the welcome email and supplying a password, but I can see in the code as well that you guys are also generating a password. We haven't tracked down the exact steps, but it seems that the email that is sent out uses the password WP first generates and not the one that PS generates. changing the filter priorities from 10 to something like 99 inside the Pro Sites code didn't help. However, writing the $welcome_email for that filter did.

    We're still working through what's causing the issue, but we did patch it, and perhaps our patch can give you guys some insight into what's going on. Here is the code for our patch:

    In our theme's function.php file we added the following.

    // hijack Welcome Email for new sites
    add_filter('update_welcome_email', 'update_welcome_email_with_reset_password', 99, 6);
    
    function update_welcome_email_with_reset_password($welcome_email, $blog_id, $user_id, $password, $title, $meta) {
    
        $welcome_email = __('Hello USERNAME,
    Your new SITE_NAME site has been successfully set up at:
    BLOG_URL
    You can log in to the administrator account with the following information:
    Username: USERNAME
    Password: PASSWORD
    Log in here: BLOG_URLwp-login.php
    We hope you enjoy your new site. Thanks!
    --The Team @ SITE_NAME');
    
        // create new password at this point for users
        $password = wp_generate_password( 12, true );
    
        // set password immediately before sending email for the current user_id
        // this trumps any password that may already be in the database.
        wp_set_password( $password, $user_id );
    
        $url = get_blogaddress_by_id($blog_id);
        $user = get_userdata($user_id);
        $welcome_email = str_replace('SITE_NAME', $current_site->site_name, $welcome_email);
        $welcome_email = str_replace('BLOG_TITLE', $title, $welcome_email);
        $welcome_email = str_replace('BLOG_URL', $url, $welcome_email);
        $welcome_email = str_replace('USERNAME', $user->user_login, $welcome_email);
        $welcome_email = str_replace('PASSWORD', $password, $welcome_email);
    
        return $welcome_email;
    }

    Basically what we're doing here is hijacking the welcome email long after wordpress or pro sites is done manipulating it. We are forcing a new password programmatically right before it's sent out. This guarantees that, based on the priorities we found in PS, our password would take precedence.

    It's a hack, but so far we don't see any problems with it until a solid can be baked into the official plugin. If you see any caveats let us know.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.