Wordpress includes a utility called ‘wp-cron‘ which is activated each time a visitor or bot requests one of your blog pages. The intent of wp-cron to to handle scheduled publishing or other ‘chores’ managing the content for the Wordpress install. If you see a lot of traffic (from real visitors or robots) then your server can be negatively impacted by the activation of wp-cron (it hits both your web server and database(s).) Three ways to ‘run’ the wp-cron process:
- leave the Wordpress install alone – wp-cron runs by default (probably OK on a site with moderate activity)
- disable the default behaviour (see below) and run the wp-cron process manually by accessing it via your web browser (totally manual approach – no scheduled processes occur if you take a ‘day off’…)
- disable the default behaviour and use either a custom plugin or create a system level crontab (see below)
To reduce the system load from the wp-cron utility you might consider customizing the code or installing yet another plugin. Creating a ‘real cron’ is perhaps a simpler approach (provided you have access to system level tools and you are comfortable making such changes.)
1) Disable wp-cron in the wp-config.php file (base file tree of your Wordpress install.)
Add/modify this entry between the <?php and ending ?> tags wp-config.php file:
- define(‘DISABLE_WP_CRON’, true);
2) Create a real crontab entry and use any allowed URL fetching tool to activate the cron. Crontab entries may vary across Operating systems so you may need to review the manual entry for crontab on your system (i.e. man crontab.) The entries in a typical Unix/Linux/BSD crontab include minute, hour, day of month, month and day of week switches. Set the times/dates to those which make sense for your needs. Examples:
### Minute | Hour | Day-of_Month | Month | Week_Day (actual crontab date/time settings are usually separated by spaces with the last entry being the ‘arguments’ that are activated/run by the cron process…)
- 15 6,12,18 * * * /path/to/script
- 15 6,12,18 * * * /path/to/tool_with_arguments
The examples above run ‘the cron task’ at 6:15 (AM), 12:15 (PM) and 18:15 every day (*=all.)
Based on the Wordpress Codex for wp-cron there are no Parameters and no Return Values (when your install does not need to run wp-cron) when you access the URI for wp-cron.
Assuming a standard install, when you surf to http://www.yourblog.com/wp-cron.php you activate/run the wp-cron process directly (method 2 above.)
Using an automation tool like wget you can create a crontab for this process.
/path/to/tool/wget http://www.yourblog.com/wp-cron.php
Creating a Crontab Entry – Unix/Linux
- ssh to your server
- run the command ‘crontab -e’ (starts your default editor, like ‘vi’ to edit crontrab entries)
- add the crontab entry & save
- review for status (confirm that the cron is running by scheduling a test post; in this case I scheduled this post prior to completing the post but after setting up a cron script using wget.)
More information on wp-cron.php
Wordpress.org - highlights several reported problems (mostly performance related so I suspect the reporting sites were quite busy…) as well as providing codex links. Note that wp-cron is requires that some user/process access your Wordpress install – if you have no activity (web visits to your blog) then your ‘cron’ is never run so your scheduled posts would never be published…
Additional information and a Wordpress 3.0 multi-site cron tool (not reviewed) is available on Pascal Gauthier’s blog.
More information about Unix/Linux/BSD Crontabs
You might think that you are done by testing your cron command while you are logged into your server. Not quite. When you test from an interactive login (i.e. ssh) you are running the command within a customized user environment (paths and system level variables are set.) I encourage a review of the documentation for both ‘cron’ and ‘crontab’ on your sever – you should find the information needed to configure either your crontabs or scripts to work within a cron process.
Crontab basics
- man -a cron (show all documentation or ‘cron’)
- your system must allow custom crontab entries (read docs above to see which system files might need review)
- man -a crontab (show all documentation or ‘crontab’)
- some crontabs support setting environment variables within the crontab (i.e. email address to send results to; custom system PATHS for tools, or ’switches’ for tools – see OPTIONS below, etc.)
- most crontabs support ranges (i.e. 8-12 = 8, 9, 10, 11, 12)
- most crontabs support lists (i.e. 1,2,3,4,5,12,18)
- some crontabs support ’step values’ (i.e. 0-23/2 = every other hour like: 0,2,4…22)
- some crontabs support named values (i.e. day or week or month; usually specified using the first three letters of the item, like: Mon (for Monday), Nov (for November); of course such values *should* only be valid for the day or month columns…)
- some crontabs support special strings (i.e. ‘@hourly’, ‘@weekly’, etc.)
- crontab -l (to list entries)
- crontab -r (to remove all crontab entires)
- crontab -e (to edit the crontab for your user account)
Sample crontab for running wp-cron.php
OPTIONS="-o /path/to/logfile -O /path/to/wget.results" 15,45 * * * * /path/to/tool/wget ${OPTIONS} http://www.yourblog.com/wp-cron.php #15,45 * * * * /path/to/tool/wget ${OPTIONS} http://www.yourblog.com/wp-cron.php > /dev/null 2>&1#15,45 * * * * /path/to/a_cron_script > /dev/null 2>&1
The first entry assigns a value to the variable OPTIONS (for the wget command.) The second and third (when enabled) entries above run the cron at 15 & 45 minutes after each hour – I suggest using the 1st one for testing and the second when you confirm that the cron is working. The fourth line would call an external script stored on your sever.
Depending on your OS & cron version the second line above should email the results to you. The third line just runs the process and ‘throws away’ the output (no email is sent.) To dis-able a cron you can remove it OR simple insert a ‘#’ character at the begging of the entry as shown above. To activate an entry remove the ‘#’. In general it is best to avoid scheduling multiple crons to run at the same time…
As always, your mileage will vary. 
and yes, this post was ‘published’ when the appropriate crontab entry was activated by the cron process…
Recent Comments