In this episode I’ll show you how to create Scheulded Tasks in Plesk. I’ll explain where to find them (for admins and customers), how to execute them and what all those cryptic fields mean. I’ll also show you how to mute the output of the commands you execute so you won’t be bothered with emails you didn’t ask for.
Scheduled Task is another name for Cron Job, and it’s something you want to run on a regular basis, like a script file. Plesk itself does not execute your task. Instead it will give you a nice interface to add the parameters you need for the Linux crontab command (or the equivalent on Windows, I believe it’s called at or schtasks).
The cryptic numbers in each field are crontab parameters. Numbers for those fields correspond to their description (i.e. 0-59 for minutes, 0-23 for hours, etc).
One thing of note (and confusion) is how to define endless repetitions. We can do this with the asterisk and slash combinations.
* means “every”, as in “every minute”, “every hour”, “every day”
*/4 means “every 4”, as in “every 4 hours”
5-11 means “every number in between”, such as 5,6,7,8,9,10,11
To find out more about the crontab command, head over to a great nixCraft article here:
By default Plesk will send you an email with any output a script or command may generate. You can avoid this by diverting all output to /dev/null. This is a virtual partition that magically makes things disappear.
In the video I’m using a fictitious script /var/script.php. To divert its potential output I would use
A note about Script Files
If you’re executing BASH, PHP, Python or any other script, make sure your files contain the she-bang at the very beginning to that your server can find the correct path. Here’s an example for how a PHP script should start:
Note that web files that are designed to run in a browser cannot be called that way. You need to call those using cURL or wget.
Creating a recurring automatic function in WordPress used to be one of the most difficult things for me to understand. Several articles out there explain how to do it, yet I always forgot the concepts when the next cron job job came along. Right now it’s in my head, and that’s the time when I like to write things down for “next time”. I hope these notes will help you in your own development.
Setting up a Cron Job in WordPress involves the following items:
a scheduled event, i.e. something that WordPress will execute repeatedly
our own function with code to execute (we’ll hook it into the above)
the event needs to be run when WordPress loads
the event needs to be unscheduled upon plugin deactivation
So we’re hooking into WordPress, which gives us a new “timed hook” into which we hook our own function. No wonder this is a complex subject.
In addition, WordPress only offers three schedules, so we’ll also look into how to add our own intervals. Let’s get started.
Creating our Scheduled Event
First we’ll create a function that will schedule our event. Mine is called “mycronjob” and it will run once every day. All this code can go into your plugin’s main file, outside the main function:
// create a scheduled event (if it does not exist already)
// and make sure it's called whenever WordPress loads
At the same time we want to make sure it’s unscheduled when the plugin is deactivated:
// and make sure it's called whenever WordPress loads
The unschedule function remains the same as above.
Checking and Testing your Scheduled Events
Before you go on a coding spree you probably want to know if this event is actually happening as planned. I like to do this in two ways.
Setup something tangible like the email function above and set the schedule to something like once every minute. Then refresh the front page of your WordPress test instance once or twice and watch your inbox. You should receive emails more or less once a minute, if you keep refreshing the front page (not the admin page). If this works, then you’re good to go.
Another way to check if your event is recognised by WordPress is a lovely plugin by Simon Wheatly called Cron View:
Once activated it will show you which events are scheduled by WordPress. Let me show you how helpful this is. The first screenshot shows a vanilla WordPress installation with its own scheduled events. “mycronjob” is nowhere to be seen (nor should it at this point):
Now we’ll activate my own cron starter plugin and refresh the front page. We’ll also refresh the What’s In Cron page to see this:
Just what the doctor ordered: “mycronjob” is scheduled to run in the next minute, and at the top of the screen I can see my custom schedule that have been added (Once every Minute). You can see this menu under Tools – What’s In Cron.
WordPress Scheduled Events are not “real” Cron Jobs, like the UNIX Cron Tab. The difference is that a “real” cron job would be reliably called by the server clock. Scheduled Events on the other hand are determined by how long ago the last event happened. If the time interval between “last run” and “right now” is larger than specified, the event fires.
This in turn relies on visitor traffic. On low or no-traffic websites like your test environment this means your event may not fire as expected. You can help this along by refreshing your front page.
Also note that traffic kicking off scheduled events can be disabled in wp-config.php by adding the following line:
This is often done so that a “real” cron job can call the wp-cron.php file in exactly specified intervals (we’ll deal with this in another article). It’s not the default setting, but definitely something to check if your events are not working as expected.
I have created a demo project on GitHub that implements the above and works out of the box:
This is good to know if you need to setup a cron job which triggers a PHP file. Calling it from a web browser directly is not a problem, but if you have to call it from the command line or as a scheduled task you need to call it with
You can also use wget or cURL but that’s often not reliable.
If your PHP file gives you an output (usually to the browser screen), your server will send you an email. If you;d rather this didn’t happen, direct it to nowhere like so:
Wouldn’t it be great if something could be triggered even when you’re not around? Say once an hour, once a day, once a week or whenever you like in predetermined intervals?
Then you want to do this with what’s known as a Cron Job, or Scheduled Task.
Unfortunately, this is a bit beyond what WordPress can do, and it means getting down to the nitty gritty of the internal workings of your server (after all, that’s where WordPress lives). Bear with me here, I’ll try my best to explain and show solutions.
I’m using a Cron Job with Manu Flury’s excellent Photo Q Plugin. It posts one of my pictures over at http://www.versluis.com every so many hours. But for this to work properly, both the WordPress Plugin and my (Linux) server need to be setup correctly.
Some WordPress Plugins (like Rob Felty’s Postie or Charles Johnson’s Feed WordPress) have similar functionality built in, but they rely on a visitor coming to your site at predetermined intervals. That’s not something you can control really. In most cases it works reliable enough for these plugins to work, however many others just don’t have that functionality, or require more accurate control. That’s where your Cron Job comes in.
So what on earth is a Cron Job?
In a nutshell, it’s a task that’s triggered at predetermined intervals. But it’s a bit like sitting in front of a Linux Prompt on your SSH connection, and all you have at your displosal is a keyboard with a black screen and white text to type in. What’s worse, your server doesn’t speak “WordPress”, or PHP for that matter. So all you can do really is to give him Linux commands.
In all likelyhood, you probably want to call a PHP file so that WordPress does something for you (such as check if it’s time for a new post, or maybe a database backup). And you can’t just tell Linux to go to that file, becasue it wouldn’t know what to do with it. I’ve tried this without success many times over (they nearly put me in a mental institution, seriously… I can assure you I’m much better now though).
So you need to find a command that calls your PHP file as if it were a browser. Lucky for us, the command “wget” will do the trick.
Wget is really designed for downloading a file to your server, but it’ll work fine for triggering a PHP file, just as a browser would do. The command for calling the Photo Q file for example looks like this:
Now that we know how to call upon a PHP file from our command prompt, we need to tell our server to do this without us being there, and at what times he needs to do this. He’ll be more than happy to oblige, after all, that’s what he was designed to do.
How to setup a Cron Job in Plesk
I’ll focus on how to do this in Plesk 9 here, which refers to it as Scheduled Tasks (earlier versions of Plesk call it Crontab).
Here’s how you get there:
from the main menu on the left, select HOME
select the DOMAIN you want to run this task on
under Additional Tools, select SCHEDULED TASKS
choose the SYSTEM USER you would like this task to be run as
select SCHEDULE NEW TASK
OK, this was complicated enough to figure out – now comes the part nobody ever really talks about. It’s hard to explain, so please bear with me if I’m not making a whole lot of sense at first. In essence, you’re telling your server WHEN to do something, followed by WHAT to do.
Each field requires an entry. Don’t leave them blank.
The first tick box is to “switch on” the task. That’s what you want, unless you want to suspend the task. Tick it for now.
Now tell your server WHEN your task shall be run.
a “*” (i.e. star or asterisk) means “every”. So a star in minute would run the task “every minute”, likewise for hours and days of the month
You can also create the command “*/5” if you want your task run every 5 hours, every 5 days, every 5 minutes – you get the drift
Alternatively, put in the specific date (i.e. “Monday” and “17” for Monday at 5pm)
After all that, you’re left with one last line, which is the actual command or task you’d like to be run.
Like I explained above, for a PHP file to be called, use the wget command like so:
Although I’ve been dealing with webshoting and webdesign since 1995, it took me a whilw to figure this one out. If you’re used to shared shosting packages, it’s likely that you’ve never come in contact with this. Hence, this article is aimed at people who don’t know what it is.
As explained in Wikipedia:
Cron is the name of a program that enables unix users to execute commands or scripts (groups of commands) automatically at a specified time/date. It is normally used for sys admin commands, like makewhatis, which builds a search database for the man -k command, or for running a backup script, but can be used for anything. A common use for it today is connecting to the internet and downloading your email.
So a cronjob is a scheduled action, which is executed by and on your web server. WordPress itself doesn’t do this for you. It’s like having a monkey sitting at a command prompt, typing something in every minute/hour/day – in regular intervals – you get the drift.
In order to setup this automatic execution, you need to be in control of your own dedicated or virtual server. If you’re on shared a shared hosting plain, you can ask your provider to setup a cron job for you. Just tell them “I want (this particular file in this particular directory) executed every Thursday evening at 9”. Otherwise, use your own administrative panel (like Plesk or Webmin) to set this up.