Larger subscription company issues

Hey Patrick

Our guide on Advanced Queue Setup In CLI mode will allow for fine tuning the syncing behavior and increase performance especially for larger stores. We’ve found that in certain instances as you’ve discovered the default cron job isn’t sufficient for triggering the necessary syncing. In order to implement the Advanced Queue Setup it will require experience with dealing with WordPress installs on a server and using the Command Line Interface.

We also do provide a way to also turn off syncing transactional customers. This accomplished under the Sync Settings of the plugin found on the Audience tab, See screenshot: https://loom.com/i/4a15662e945c4d278fc5c32be12f0238)

Lastly, if you haven’t done so already please update to the latest version (v3.7) as we’ve made quite a bit of enhancements to help with syncing issues and performance in general.

Hi @builtbyjordan,

Thank you for the fast reply – been looking for the CLI setup; but it looks somewhat like we assumed it would (and we have).

The issue still tends to clog up when we push 3-5000 orders in 20 minutes (and we run 10x faster action scheduler). At least, after a very long time of debugging, thinking it was the payment gateway that had issues; we disabled the MC Woo plugin today; and was able to run all payments within the 20 minutes, for the first time (This is what lead me to the assumption that its a clogging issue that WP-CLI wont fix; but rather a stacking-issue of the queue or callbacks from mailchimp API for each order).

Question: If we just disallow the post_type shop_order with the mailchimp_should_push_order_post_type_list filter – are the checkout-subscribers still pushed to mailchimp? I think what im looking for/asking, is if we can send the signups directly to Mailchimp, without having to send renewal/automatic orders. (All signups to MC are done on the parent-order when the subscription is purchased – so all this transaction-data is just unneeded fillings in our case – and the orders are automatic-renewal orders; so sending them doesnt make much sense.)

An alternative could also be mailchimp_should_push_order and check if-parent then false/ignore the order (but this seems like a hard-check on an order,during the high-load payment run, which is what we’re trying to get away from to ensure faster/smoother payment-processing for the renewals)

@patrickthagaard thanks for the details – this actually helps. I’m going to say your last paragraph about checking if the parent exists is probably going to be the place I would start first. This seems like a perfect way to ignore what you want.

We’ve been talking internally about whether or not we should implement this in the plugin, or just allow other plugin developers to use the hooks… it’s a very difficult situation for us just because of the sheer number of plugins that would need support as well.

The hook seems like the best option for us here.

@patrickthagaard one other thing I forgot to mention just in case you haven’t seen this, is that you have the ability to prioritize processes in the queue by referencing a --hooks argument which you can find documentation on that here https://actionscheduler.org/wp-cli/

This will help you run a specific instance of the scheduler that will prioritize your jobs, especially for payments it makes sense.

The order filter is looking like a good solution (The real trial will be on wednesday next week). Im having issues figuring out what $job->id actually returns; but im assuming its order_id (correct me if im wrong). That means the code-solution should be below. (I might be missing some documentation on the passed variables for the filter somewhere..)

Edit: Since the wcs_order_contains_renewal for whatever reason isnt loaded for the filter; meta_data check works and the below runs smoothly

add_filter('mailchimp_should_push_order','tk_filer_mc_api',10,1);
function tk_filer_mc_api($order_id) {
   	if (get_post_meta($order_id,'_subscription_renewal',true)) {
       	return false;
   	}
    return true;
}

As for the final solution, we are going for:
– Hook into mailchimp_should_push_order – If order is renewal – block it (return false).
– AutomateWoo: Send subscription-status to Mailchimp on a schedule we can match our run-rate of payments (So we can still have the data we need – but can sync it off-peak-hours)

Thanks for all the help so far!

• This reply was modified 8 months, 2 weeks ago by Patrick Thagaard.
• This reply was modified 8 months, 2 weeks ago by Patrick Thagaard.

Hi @patrickthagaard, that sounds good. Please let us know if you need anything else. Happy to help anytime.