GIT extension for Plesk has a nice feature “Additional GIT deployment actions” which comes in handy when you need to automate some post-deployment stuff. For WordPress based websites which are under the GIT version control there might be several things to run after each deployment, which includes:
- Clearing various caches (e.g. PHP OPCache, Object Cache, Page Cache)
- Updating version numbers to “refresh” the browser cache for static files
- Event logging (e.g. when the site was last updated)
If your case meets these criteria:
- You have a WordPress website and you use a GIT version control for its development;
- You are using PLESK (Linux) for hosting your WordPress website;
- You are using GIT extension for Plesk to update your site with the latest changes from its GIT repository;
and you have not yet used “Additional GIT deployment actions” feature, this article will certainly help you to set everything up.
How this “GIT deployment actions” feature works?
Assuming that the GIT extension is available on your PLESK webspace and you already have at least one GIT repository added to it, you can find and enable the feature by:
- Going to your PLESK dashboard and opening up GIT (under “Dev Tools” section);
- Clicking on the “Repository Settings” icon of your configured GIT repository;
- Ticking the checkbox “Enable additional deployment actions” under “Deployment Settings” section;
The “Deploy actions” field is meant to contain one or more linux commands (like the ones you use in the terminal). While you can add there practically anything, by default these commands will be run in a chrooted enviroment under your webspace / system user (even if SSH access is forbidden for your webspace). The same thing applies to commands in the Scheduled Tasks section.
Since the chrooted environment on Plesk is usually very limited, there’s also a limited choice of commands you can use to automate the things after deployment. *Except if your webspace has been allowed to use non-chrooted variant of SSH.
GIT Deployment actions in PLESK for WordPress sites
The most safest approach for automating stuff when you deploy changes via PLESK GIT interface (including a webhook option) to your WordPress website is by using a simple “wget” command, since it is tipically allowed in all chrooted environments by default. You can use it to request an URL of a PHP script or a specific endpoint on your website which will then do the actual “post-deployment” actions. This will work if you do not have a special needs of running additional software on the server and you can automate everything just by using the methods PHP and WordPress provides.
Because of limitations you may encounter for the “wget” command (e.g. no support for TLS / SSL or IPv6 connections) I’d highly advise to also use additional triggers “–secure-protocol tlsv1 –no-check-certificate –inet4-only“. The request will be made internally anyway so in general there should be no security risks even if you use an insecure version of SSL.
Sample of a full wget command to use:
You can replace the URL in quotes with anything you need. Just in case you want to use my code snippet further below for post-deployment stuff, you can change only the https://mydomain.tld an myapikey parts.
wget -qO - 'https://mydomain.tld/dwp-clear-cache.php?key=myapikey' >/dev/null 2>&1 --secure-protocol tlsv1 --no-check-certificate --inet4-onlyAttention: Note that in my example command I’m directly requesting a PHP file outside of WordPress. That’s because you can’t reliably clear PHP OPCache AFTER you load the WordPress (like when issuing a request to wp-ajax endpoint) – such scenario could easily result in a fatal PHP error because of missing files which were referenced as inclusions in the compiled PHP OPCode (e.g. if your latest GIT commit you’re pulling involves a removal of some PHP files which were previously loaded in the WordPress).
Editor’s note
PHP file addon: Automatically clear cache after GIT deployment.
Clearing various caches (PHP OPCache, Object Cache, Page Cache) is the most common thing you would want to do each time when you deploy something on your website from a GIT repository. This PHP file is a working sample which can help to automate these processes. It is an endpoint which first clears the PHP OPcache then the WordPress Cache and additionally, if you use a Super Page Cache for Cloudflare plugin, it will purge also the CloudFlare cache.
To use it – just place this file in your WordPress root directory and use the linux command above to run it. Remember to set a proper filename (which matches with the one in the linux command) and change myapikey to something more unique in both – the linux command and this file.
<?php
/*Cache cleaner by DoInWP*/
//Key to avoid unauthorized requests on post deployment actions
if(empty($_GET['key']) || $_GET['key'] !== 'w845298adda8') {
return;
}
//Make sure this request do not get cached
header('Expires: Sun, 01 Jan 2014 00:00:00 GMT');
header('Cache-Control: no-store, no-cache, must-revalidate');
header('Cache-Control: post-check=0, pre-check=0', FALSE);
header('Pragma: no-cache');
//Reset PHP OPCache
opcache_reset();
//Extra delay for safety purposes
sleep(2);
//Load WordPress AFTER the PHP OPCache has been cleaned
require_once('./wp-load.php');
//Run the built-in WordPress function for flushing the cache
wp_cache_flush();
//Cache purge - Super Page Cache for CloudFlare plugin
do_action('swcfpc_purge_cache');Last step: Testing out the functionality
When you’ve added a deployment action you should test it out afterwards. Just open up a GIT interface on your PLESK webspace and press on a “Pull now” button for a repository you want to deploy from. You should see additional subtask in the deployment process – Running additional deployment actions.
When a deployment task is completed, check for any warnings in the same window and check if the site have been properly updated afterwards. You can also add some extra error logging to the deployment action so you better can see if it executes correctly.