Optimized use of schedules
Some things need to be done when they need to be done. This could be publish planned posts, automatically updating plugins or themes, cleaning up your system or retrieving data from an external service. For those tasks WordPress has a schedule implementation. Those schedules have some serious disadvantages and should be extended with “real” cron job if possible. Why and how that’s the topic of the following read.
If you want to run scheduled tasks all you need to write are the following lines.
These few lines check if a schedule exists, and schedule the specified action to execute if none exists. One and every hour later if someone or something is requesting an url of your WordPress site, the action will run and every function that is added to this action will execute.
Sounds nice and easy and smooth, right? Well, yes but…
WordPress schedules are triggered by http requests by default. So first of all it’s not dependable. If there is no traffic on your website no schedule will be executed. This means no planned posts, no system updates, no ping backs and no other scheduled processes are triggered. There will be no schedule functionality at all.
On websites with high traffic it stresses the server performance because all incoming requests have a bit more to do. There is at least a database query that checks if schedules need to be run. That’s no expensive operation but if you use some ajax functionality on your website for example, it can cause at lot of unnecessary work for the server. And small flocks can also make a mess.
Some other request will have a lot more to do. If you are the poor visitor that has to run some scheduled tasks with your request the page load time can be much longer depending on the task.
Just imagine a task that imports data from a foreign service via http request. This could take a while and the request could be canceled by the visitor. And even if you have very patient visitors, they may run into max execution time problems. Not a satisfying situation at all in my opinion.
I guess this implementation of schedules has a good reason. WordPress is the most popular CMS in the internet. Almost every second website uses it (w3techs.com May 2021). Most of those websites are created by non-professional developers who do not use professional hosting. Some of the cheap hosting solutions do not even support cron jobs, so an implementation for schedules like this makes WordPress “fully” functional even on cheap hosting.
How to optimize schedules
So what can we do about the drawbacks of WordPress schedules? The good news is: We can do a lot with almost no effort.
First add one line of code
define('DISABLE_WP_CRON', true); to your
wp-config.php . This disables any schedule related functionality with normal requests to the website.
There are several better ways to reactivate schedules.
HTTP cron job
Some cheaper hosting providers only provide cron jobs that can trigger an url on a regular basis. You can use the url
https://your-domain.tld/wp-cron.php and schedules are executed again. This makes schedules execution reliable and independent from visitor requests but the risk of max execution time errors still exists.
If your hosting provider does not provide any cron job tool at all you can still use wp-cron.org .
If you have shell access to your web server and your hosting supports the
crontabtool, you can create a cron job that runs directly on the shell.
Check if the command line tool
wpis available. If not, you can download it here.
crontab -e to edit the cron job set up file and add a new cron job.
0 * * * * wp cron event run --path=/path/to/wp/docroot --due-now
You want to learn more about crontab schedule definition syntax?
Done! This will execute your schedules every hour. Independently from visitor requests and without the risk of max execution time errors.
If it is possible disable the default schedule behaviour of your WordPress instance. Use crontab and shell execution of wp-cli as first choice. If that’s not possible have a look at your hosting cron job options or use wp-cron.org.