WPCloud Deploy Documentation

Technical Notes For How We Implement Templating Sites When Selling WP Sites With WooCommerce

Introduction

When a customer purchases a WP site in WooCommerce that is configured to be sourced from a site template, a series of complex processes kick off in the background.  In this help article we aim to provide some color on how we’re handling this within the confines of WPCD’s WordPress technology.

Truth be told, this article is to remind ourselves about what we did!  To be blunt, things can get quite hairy!  So, lets dive right in.

High Level Walk-through

Template sites reside on a different server.  So, when a purchase is made two things have to happen:

  1. The template site has to be copied from its server to the server where the new WP site will be located and
  2. The domain has to be changed to a new temporary domain.

This requires two back-to-back long running transactions that is sequenced properly.

For the first step, we use the function in our “Copy To New Server” tab, referred to internally as “site-sync”.

For the second step we use the function in our “Change Domain” tab.

Challenges & Solutions

One of the biggest challenges in WPCD (and also one of the benefits) is that a lot of activity occurs on action and filter hooks – some might say we overdo it on our ‘do_action’ calls.  They are very very convenient for triggering things and then moving on.  But sometimes these hooks can’t quite get the data they need if they are two steps removed from where the data originated.  For this feature where we need to run multiple long-running transactions, we absolutely required that the data be able to be passed between multiple independent action hooks in a particular sequence.

The only real way to do that was to use the database to pass the data.

So, in order to handle the sequencing we added the PENDING LOGs table/CPT.  (Later we’ll use this CPT to do bulk processing for servers and sites…)

Another thing we had to do was convert the ‘site sync’ and ‘change domain’ functions in the core plugin so that the could be triggered by action hooks instead of just being used directly in the UI via AJAX.

Sequencing

Now, the sequencing depends on a few things:

  1. That at the end of a long running transaction, a HOOK is fired for both the template site copy (“site sync”) and the domain change.
  2. That the initial transaction in WooCommerce that triggered the hook create and passed an array to the FIRST hook with all the data it needed for the rest of the process (including all intermediate hooks).

Thus, when the first long running transaction finishes (copying the template site – aka site-sync), its “I am done” action hook fires.  That hook collects data from the PENDING LOGS using the COMMAND NAME as the key into the log. It  does it’s thing but before it ends it updates the PENDING LOGS task as completed.  It then fires off the second task (changing the domain of the newly copied site) by using a do_action call.  That second task then does it’s thing, adds data to the PENDING LOGS table and, when it ends  fires up its “I am done” action hook.  That hook in turn picks up the data from the PENDING LOGS table, does its thing and marks the task complete.

The Full Sequence

  1. When the order is placed, the function wp_spinup_wpapp is executed – triggered by WooCommerces’ woocommerce_payment_complete hook.
  2. An array with all necessary data is created and the wpcd_wordpress-app_do_site_sync hook is called via do_action, passing that array as the second ‘args’ parameter.
  3. Just before site sync is completed (which copies the template site to the server where the newly purchase site will reside), it adds a record to the PENDING LOGS table using the command name as the key for the record.
  4. The after-action command hook (‘command_completed’) for site-sync then fires, does some updates to the new site record and fires off another action hook to indicate that it is done.  At this point there is no change to the PENDING LOGS table from step 3.
  5. The wpcd_wordpress-app_site_sync_new_post_completed hook is fired.  The function that handles this hook is named site_sync_complete.  It does its thing and then marks the PENDING LOGS task complete.  It then fires off a do_action hook to trigger the domain change on the newly copied site.  The hook being fired is wpcd_wordpress-app_do_change_domain_full_live.
  6. Just before the domain change is completed, it adds a record to the PENDING LOGS table using the command name as the key for the record.
  7. Once again, the after-action command hook (“command_completed”) fires. It does some updates to the new site record and fires off another action hook to indicate that it is done.  At this point there is no change to the PENDING LOGS table from step 6.
  8. The wpcd_wordpress-app_site_change_domain_completed hook is fired.  The function that handles this hook is named site_change_domain_complete. This is where the final steps are done for the process – the new record is updated with all the user, order and similar info and emails sent to the end user.  The PENDING LOGS record is updated as completed.

 

Share: