Introducing Product Packages For our WooCommerce Integration

Version 3.3 of our WooCommerce integration will include a major new feature we’re calling “Product Packages”.

Product Packages allow you to automatically activate plugins and themes on a per-product basis, configure memory usage per product and inject the product id, product categories and custom values into the tenant wp-config.php file on a per-product basis. It even allows you to configure and run unique custom bash scripts for each SITE product.

You can create multiple product packages and assign each to one or more WooCommerce SITE products.

Install & Activate Plugins

WPCloudDeploy Product Packages allow you to activate existing plugins for each product that uses a package. These plugins usually already exist because they’re part of your site template for that product.

You can also choose to install and activate plugins from wordpress.org or an external source such as github. But, for performance reasons we recommend that you include plugins in your site template instead of dynamically installing them for each tenant site.

Tip: You can hide portions of your plugin list from your users but still activate or deactivate plugins as the user changes plans.

Deactivate Plugins

If the user switches a product plan, you might want to automatically deactivate plugins if they’re downgrading to a lower-level plan.

Plugins are deactivated first before other plugins are activated from the ‘activate list’.

Activate a Theme

You can specify that a specific theme should be activated when a particular product package is in use on a WooCommerce product.

As the user upgrades or downgrades their plan you can switch their theme to a more or less capable one.

Install Themes

You can also choose themes to be installed for each product package.

We do not attempt to activate a theme until we have processed the ‘install themes’ list. This way, if a theme is not already installed but is in the ‘install list’, we install it first which makes it available to be activated.

For performance reasons you’ll want to be careful about how many plugins and themes you’re downloading and activating. We recommend that you pre-install as many as possible in your site template(s) so that they are available to be used immediately.

wp-config.php custom entries

You can choose to inject custom values into the wp-config.php file of the new tenant site.

A key reason you might need this is to use a custom plugin to control the user experience and features based on something like a ‘planid’. We already inject the WooCommerce product id and product categories that can help with the same idea; but this feature gives you a bit more control over what gets injected to be used by your custom plugins.

Another reason you might use this is to control how much memory your WordPress instance will use for a given plan. Maybe your free plan will have less WP memory allocated than your premium plans.

PHP Workers

If you’re running an NGINX web server, you might want to limit the php workers for each plan.

Limiting php workers limits the amount of cpu cycles and memory consumed in any given period. So this would be a good option to use with your free or lower-priced plans since the default WPCD workers per site is five.

Memory and Other Resources

You further can limit the amount of memory and other resources available on each plan

Custom Bash Scripts

For additional flexibility you can define bash scripts to be run for each product package. You can define two scripts for each package

• A script to run for new sites
• A script to run when the user upgrades or downgrades

Each bash script will have the following environment variables set:

• DOMAIN

You can use these scripts to gain fine control over which plugins are activated, installed etc. as well as setup a more customized site environment for your user based on the plan/product they purchased.

Here are a couple of simple scripts:

This first one is for a new product purchase:

echo "My custom post processing script for a new subscription product package..."

# $Domain was injected into the environment and available to all bash scripts.
echo "domain: " $DOMAIN

# Read product id and categories that were injected into wp-config.
WCPRODUCT=$(su - $DOMAIN -c "wp --no-color config get WC_PRODUCT_ID")
WCCATEGORIES=$(su - $DOMAIN -c "wp --no-color config get WC_CATEGORIES")

# echo out that data to prove it's there.
echo "wc product id: " $WCPRODUCT
echo "wc product categories: " $WCCATEGORIES

# Randomly install plugins so that this sample does something useful.
echo "Installing a new plugin from wordpress.org..."
su - $DOMAIN -c "wp plugin install bbpress --activate"
echo "Installing another plugin from wordpress.org..."
su - $DOMAIN -c "wp plugin install simplepress --activate"
echo "***post-processing script complete***"
echo ""

This one is for a plan change:

echo "My custom post processing script for a subscription switch"

# $Domain was injected into the environment and available to all bash scripts.
echo "domain: " $DOMAIN

# Read product id and categories that were injected into wp-config.
WCPRODUCT=$(su - $DOMAIN -c "wp --no-color config get WC_PRODUCT_ID")
WCCATEGORIES=$(su - $DOMAIN -c "wp --no-color config get WC_CATEGORIES")

# echo out that data to prove it's there.
echo "wc product id: " $WCPRODUCT
echo "wc product categories: " $WCCATEGORIES

# Randomly install plugins so that this sample does something useful.
echo "Installing a new plugin from wordpress.org..."
su - $DOMAIN -c "wp plugin install bbpress --activate"
echo "Installing another plugin from wordpress.org..."
su - $DOMAIN -c "wp plugin install simplepress --activate"
echo "***post-processing script complete***"
echo ""

The two examples look similar except for the first output message. But of course, in the real world they would likely be doing very different things. The examples also illustrate how you can reference the injected bash variables for product ids and categories.

Assigning Product Packages To Products

Using packages are optional. They are assigned to your WooCommerce SITE products directly in the WooCommerce product definition screen:

If no package is assigned then no special rules will be applied after the site is provisioned.

Wrapup

This is a feature that some users have been asking for and we’re really pleased to finally get it done. It also allows us to easily add more per-product customization in the future.

PS: We are looking for ideas on what else we can automatically inject into the wp-config.php file for tenants and into the Linux environment for custom bash scripts. If you have ideas, please let us know!