We have many active, production, paying clients on our site, so we're skeptical to try the beta version. Really Simple SSL is taking care of the problem for us at the moment, but it's not without its own problems. I know that the plugin has to go through a QA testing process, but is there an estimated target for when a production ready version will be available / released?

Great stuff! That helped us fill the holes in our code. For now, I'll post our actual hook function for anyone else who may want to modify it for their needs. For those who come across this, this for a subdomain installation of multisite (and not sub folder). You'd plug that function into whatever WooCommerce or WC Subscriptions "Payment Complete" action hook of your choice. Ours is in the woocommerce_checkout_subscription_created action hook for WC Subscriptions although you could use woocommerce_payment_complete for regular wordpress installs. function create_site_after_checkout_subscription_created($subscription, $order, $recurring_cart) { write_log('Firing inside woocommerce_checkout_subscription_created.'); //load new blog templates api include_once( WP_CONTENT_DIR . '/plugins/blogtemplates/nbt-api.php' ); nbt_load_api(); //get the user who just paid for woocommerce product //$order = new WC_Order( $order_id ); // only needed if order isn't passed to hook $newdomain = get_post_meta($order->get_id(), 'Domain Name', true); $newdomain .= '.'; $newdomain .= DOMAIN_CURRENT_SITE; // as defined in wp-config.php $path = "/"; $title = $newdomain; $user_id = (int) $subscription->get_customer_id(); //create the blog with the current correct info $new_blog_id = wpmu_create_blog($newdomain, $path, $title, $user_id, $meta, get_current_network_id()); //custom function to get blod_id to clone based on what product was ordered $template_blog_id = toursoft_choose_template($order); $args = array( 'to_copy' => array( 'posts' => true, 'pages' => true, 'menus' => true, 'terms' => true, 'files' => true, 'settings' => true ), 'update_dates' => true ); nbt_api_copy_contents_to_new_blog($template_blog_id, $new_blog_id, $user_id, $args); }

Great explanation! Thanks so much!

Thank you for that Panos Can you please explain a bit more what's happening for those of us who aren't SQL savvy? The solution from this thread works fine, but would we not want to just continue to use the solution from your other thread a couple years ago? What is a constraint and why is it needed? Many people over the past couple years have had the same problem with different database tables from different plugins. Your earlier solution fixed all of them. What happens if, next month for example, we install a new plugin and this happens again? (Since that seems to be specific to woocommerce above). Should this not be considered an issue that needs a different direction in the plugin that would handle all cases regardless of plugin like your earlier solution did? Why would this not be considered a bug if the same thing has happened many times over the years? Also, do you have any idea why I'm having this issue but Patrick couldn't replicate it when he tried? Thanks!

Leni Neto Leni, I have a similar question, and as I plugin this into my WooCommerce hook, I too am getting the same JSON error. You said you resolved that, but I didn't see the answer above. Do you remember what you did to get past that error? And did the final solution work for you?

My title got cut off. The title is: "WITH NEW BLOG TEMPLATES, HOW CAN I PROGRAMMATICALLY CLONE A TEMPLATE AFTER A WOOCOMMERCE ORDER."

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.

Just curious if there were any updates on this. Were the developers able to take a look? I'm curious as to how this could be happening. We have a developer on staff who can help investigate if we have a bit more insight. As it stands now, we cannot sign people up manually or activate them, so we're anxious to be able to contribute if we can.

After some more digging and working with the WooCommerce dev team, their dev team confirms that whatever code is handling the duplication of certain tables, that code may need to be updated to correctly handle constraints. https://github.com/woocommerce/woocommerce/issues/20310

In his response on the thread https://premium.wpmudev.org/forums/topic/new-blog-templates-plugin-creates-error-when-affiliate-wp-is-enabled-in-template?replies=17#post-1322960, Panos suggested a file that hotfixes this issue. I followed his instructions and copied out one file for the other. And, it works. So, when you go to test, you won't get the error. While this hotfix let's us get around our immediate issue and continue sign ups (hopefully, we're still testing it) it would great if WPMU could review the code in that file. Why is it working? What did he do that overcame the issue? What is the issue? Why was that code never pulled into production if it can solve this problem? Patrick can't reproduce the error even without the code, so I still want to keep this ticket open, figure out and solve the fundamental issue. If you need to test the error again before I can get back to it, you are welcome to login and switch the file back to the original. There is a copy in the folder named copier.phpBU