Introduction #

Up until this feature was introduced in DVI 4.16.2, you could only make use of your custom bash scripts either by:

  • Modifying the existing scripts directly or
  • Writing a full add-on to insert them using DVI hooks and filters.

With this feature you now have a third option for the most common use case – running commands at the end of the server provisioning and site provisioning processes.

There are two types of post-processing scripts.

  1. Remote scripts
  2. Local Scripts

Remote Post-processing Scripts #

These scripts are used for new sites and servers. Because these servers and sites do not yet exist, there’s no place ‘local’ to store them so we allow you to set them up remotely.

Set Up #

First you need a place where you can create a publicly accessible text file using a standard https url. For example, the RAW version of gists.

Create a file with the bash commands you need to run.

Then, set the link in the DevelopVIDeploy → SETTINGS → APP:WORDPRESS → CUSTOM SCRIPTS tab.

What Can You Do With This? #

You can create simple text files and make them available at a public link with bash commands.

For new servers, you can:

  • Disable or enable server processes
  • Install new server components
  • Reboot the server
  • Reboot the server and then install or run new scripts

For new sites you can do the following:

  • Use WP-CLI to install plugins and themes from WordPress.org on new sites
  • Insert or update constants into the wp-config.php file (eg: memory limit) in new sites
  • Modify the amount of PHP memory used in the PHP processes for new sites or servers
  • Increase or decrease the number of PHP workers used in new sites or servers

Your scripts will have access to the full complement of variables – which means that there is a lot of you can do without having to customize DVI code directly. The above are just some ideas.

Example #

Here is an example of a post-processing script you can use on a site to install two plugins from the wordpress.org plugin repository:

View the code on Gist.

Using Secret Keys #

So, you have a situation where you need to access a private github repository or maybe you want to add your plugin license key to new site installs. Since you should not place private data into public scripts, you need to make use of a secrets manager. The one we’ve used is called doppler.com but you can use any you like, as long as the following two requirements are met:

  1. It only requires a single API token instead of a key/value pair and
  2. It has an api can you can use from your bash script.

You can enter your api token in the SECRETS MANAGER API KEY field (see image earlier in this document). Then, that value will be available in the bash environment variable: $secret_key_manager_api_key

With this key, you should then be able to pull in all your other keys directly from your secrets manager.

Using Secret Gists #

You can use a secret GIST for your post-processing scripts. There are two caveats to be aware of:

  1. You must use the url for the RAW gist. Otherwise you’ll end up attempting to execute some odd combination of embedded JS and HTML script.
  2. If you change your gist, the URL changes! So you will need to keep updating the settings in the DevelopVIDeploy -> SETTINGS -> APP:WORDPRESS -> CUSTOM SCRIPTS tab if you make frequent changes to your script.

Notes #

There are, of course some things to watch out for when using this feature:

  • These scripts have to be publicly accessible. But they can be ‘secret’ links such as the raw links to secret gists.
  • Because they must be publicly accessible you cannot (or should not) include any private information such as api keys.

From a security perspective, if your remote link is compromised, so will any new servers or sites you provision.

Additionally, this feature is only useful if you do not need to set state data using post-metas in the DVI plugin. Scripts you run using this method have no way of writing data back to DVI without a custom add-on.

Local Post-processing Scripts #

Some operations allow you to create a script with a specific name in an existing site or server. When the operation is complete it will look for a script with a particular name and run it if it exists.

The list of operations and the expected script name are as follows:

  • Cloning Sites: wpcd_clone_site_after_clone_script.sh

The post-processing script for cloning is especially useful when cloning ‘template’ sites associated with Multi-tenancy or our WooCommerce Integration. Add the script to the root of your template site and it will be executed after the site is cloned.

Other #

Need post-processing scripts for other functions? Let us know your use case and we’ll try out best to make it happen!

More Topics In Admin #