WordPress was designed to run in various hosting environments without additional configuration through targeting the lowest common denominator — shared Linux hosting running php4. Since most hosting companies do not provide support for cron and configuring cron can be imposing to the average user, WordPress includes its own version of “cron” for scheduling tasks, which relies on a visitor request to trigger the execution of wp-cron.php.  This approach in essence occasionally hijacks a request for content to execute scheduled tasks, which is less than ideal and does not offer much in the way of control to the sysadmin.

For the more experienced sysadmin/developer that uses more sophisticated hosting (VPS, dedicated server, or even shared hosting with cron support) there is another option: using cron to execute wp-cron.php. First, wp-cron needs to be disabled in the configuration section of wp-config.php.

define('DISABLE_WP_CRON', true);

Then, simply request wp-cron.php directly using cron. For more information on cron, the Wikipedia article is a good starting point.

To edit a user’s crontab, log into the server via ssh and issue the following:

$> crontab -e

If you don’t use ssh often, you may also need to set the $EDITOR environment variable to an editor that you are comfortable using (e.g. vim, emacs, nano, pico, etc…).

There are two different approaches that can be used to execute wp-cron.php.

1. Use wget or curl to issue a HTTP request for wp-cron.php

*/30 * * * * wget http://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

2. Write a small wrapper script to setup the environment and execute wp-cron.php directly.

*/30 * * * * /usr/bin/php /var/cron-scripts/run-wp-cron.php /dev/null 2>&1

<?php
chdir('/var/www'); // WordPress install DocumentRoot
include('wp-cron.php');
?>

In both examples, ‘/dev/null 2>&1’ is used to send both stdout and stderr to /dev/null which discards any output and errors. By default, cron will send an email to the email address defined for the user.