WPCloudDeploy uses a lot of WordPress Cron jobs to keep things running smoothly.
However, the WordPress Cron process responsible for triggering the jobs has a severe limitation – it only triggers when there is traffic on the site.
This means that it’s almost impossible to consistently have Cron jobs that run every 5 minutes or every 1 minute on sites that are only used for admin purposes (eg: many WPCD installations.)
But that’s exactly what WPCloudDeploy needs – consistency in triggering Cron jobs.
The WordPress development team created an alternative Cron process though. This alternative deactivates the usual WP Cron trigger and uses a Linux Cron to trigger WP jobs. You can find more information with a google search for DISABLE_WP_CRON.
The advantage of this alternative is two-fold:
Using this alternative WP Cron process is what we recommended up to WPCD V 4.x. And whenever we created a server for customers to run WPCD, we configured this alternative WP Cron on the server.
However, even this alternative has limitations. In particular:
In WPCloudDeploy 5.0, we decided to take a page out of WordPress’s book and offer an alternative way to execute the WPCD background Cron jobs. This is optional but is now the recommended method to use with WPCD.
The idea is simple – you’ll set up a constant in wp-config.php (DISABLE_WPCD_CRON) that will tell WPCD to not schedule its regular Cron jobs.
Then, we’ll use a Linux cron to invoke wp-cli and trigger a WPCD wp-cli specific command that will run the Cron jobs instead (calling the same action hooks that the standard WPCD Cron jobs would have called.)
Below we’ll discuss how to set this up.
You should verify the following on the server where WPCD is installed:
Define DISABLE_WPCD_CRON in the wp-config.php file on the site where WPCD is installed
define( 'DISABLE_WPCD_CRON', true );
Next:
The process of deactivating and reactivating the two plugins removes any of the existing critical WPCD Cron jobs affected by our new process.
Add a wp-cli command to your Linux Cron table (as the sudo/root user) to run every 1 minute.
run-one su - <youruser> "wp wpcd wpcd_wp_cron_actions"
The entry might look something like this:
* * * * * run-one su - wpcloudpanel.com -c "wp wpcd wpcd_wp_cron_actions"
Notice the use of ‘run-one’. This prevents multiple Cron processes from running simultaneously and is very important!
Please double-check that the run-one package is installed on your system since not all Ubuntu images automatically include it. If it’s not the Cron will silently fail without any error messages.
Also notice the use of the su – wpcloudpanel.com part of the command – this switches the user to the user named wpcloudpanel.com (your user will be different of course) and prevents wp-cli from running as root (which is dangerous).
The actual wp cli command added to the Linux Cron table might vary with your server configuration. The one shown above is the one that will work on any server that was created with the WPCD bootstrap scripts.
If you’re NOT using a server that was created with the WPCD bootstrap scripts then it is likely that the system user for the site might not automatically be switched to the site folder. In that case something like this might be more appropriate for the crontab entry:
* * * * * run-one su - wpcloudpanel.com -c "cd /var/www/yoursitefolder/html && wp wpcd wpcd_wp_cron_actions"
Notice the use of the cd command before running the wp command.
If all else fails, you might try the following alternative which will execute as the root or sudo user
* * * * * run-one "cd /var/www/yoursitefolder/html && wp wpcd wpcd_wp_cron_actions --allow-root"
Change the /var/www/yoursitefolder/html portion of the entry to match the actual location of your WPCD files.
On some servers where you’re not logged in as root, you might need to use ‘sudo’ in front of the crontab commands.
If you’ve added the DISABLE_WPCD_CRON constant to wp-config.php and deactivated and reactivated the plugins, then there should be almost no WPCD jobs for the WP Cron process to run.
You can verify this as follows:
There should be no WPCD processes scheduled (or maybe just one or two instead of the 6+ that are normally there).
Every time the WPCD Cron jobs are run from a Linux Cron we write an entry to the error logs IF the appropriate logging flag is enabled.
You can temporarily enable this flag in the WPCLOUDDEPLOY → SETTINGS → LOGGING AND TRACING tab.
In there, you’ll see an option for BETTER CORE CRONS. Just enable it and save settings.
Then, every 1 minute or so, you should see a couple of new entries in the WPCLOUDDEPLOY → ERROR LOGS screen:
Don’t forget to turn off the flag in settings otherwise you’ll just be polluting your database with a bunch of entries that aren’t needed.
If WPCD is installed on a multisite installation and in multiple subsites, you’ll need to make sure that your Linux Cron wp-cli command is executed on ALL the subsites where WPCD is installed.
For example, you might use the following:
* * * * * run-one su - <youruser> -c "cd /var/www/domain.com/htdocs && wp site list --field=url | xargs -i -n1 wp wpcd wpcd_wp_cron_actions --url=\"{}\" " > /dev/null 2>&1
Where you should replace <youruser> with the system user for the site and domain.com with your domain or folder for your site.
Or, if you really want to use the root user:
* * * * * run-one su - root -c "cd /var/www/domain.com/htdocs && wp site list --allow-root --field=url | xargs -i -n1 wp wpcd wpcd_wp_cron_actions --url=\"{}\" --allow-root" > /dev/null 2>&1
After installing this it is possible that it works for a while and then you start to see the WPCD WARNING about CRONS not running. This is usually because the run-one process is stuck for some reason.
You can handle this by first identifying the process id that is stuck:
ps -C run-one
If you see an ID in the PID column then it is possible that that the run-one process is stuck. To confirm, wait about 30 seconds and run the command again – if it shows the same PID then it is likely that the process is stuck for some reason.
You can also run this command to see if any process that include ‘wp’ is running:
ps aux | grep -i wp
If you run that command twice, waiting 30 seconds in between and you see the ‘wpcd_wp_cron_actions’ string both times then it’s likely the command is stuck.
In either case the simplest solution to this is to restart the server.