Want to keep your WordPress install up to date automatically? Follow these steps to add a cron job to update your WordPress install every 6 hours.
Set up the install
The WordPress install must be a Subversion checkout. You can grab the bleeding edge source with a command like this:
svn co http://core.svn.wordpress.org/trunk/ .If you aren’t familiar with Subversion, start here:
Schedule the updates
Add the cron job from the command line.
- Edit the cron job list.
crontab -e - Add the cron job (edit the path to your WordPress install).
MAILTO="" # Update WordPress install every six hours * */6 * * * svn up -q ~/path/to/your/wp-install - Save and close.
To learn more about editing cron jobs from the command line search Google for man cron and man crontab.
You can also use a GUI tool like CronniX on Mac OS X to manage the cron jobs.
Notes
- The
-qparameter tells thesvn updatecommand to run silently so that you don’t have to worry about any output from the cron job. But, you should add theMAILTOdefinition if you want to completely silence output. - Some systems don’t recognize the
*/6syntax for hourly notation. If you get an error when trying to save the cron job you might have to change it to comma-separated values instead:0,6,12or similar.
The Sensible Leader 
This is fantastic… I’ll be sure to do this on most of my sites… Is there a way to accomplish this with plugin updates??
LikeLike
What would happen if the update required a database upgrade?
LikeLike
@Chris I’m sure you can do it with plugins, too. Change the
svn updatepath to match the plugin’s path (as long as the plugin is a Subversion checkout, that is).@Dave You can do the database update manually when you visit your WP admin. To be clear, I’m not using this technique for production sites, just local development versions on my Mac.
LikeLike
@Dave, to run the database update automatically after doing the upgrade, you merely need to invoke ../blog/admin/update.php and it will run the database update.
@simpledream — while doing this on dev sites using the trunk may be great, especially if what you’re doing is developing wp code, plug-ins, themes, etc. However this shouldn’t be used for sites that will eventually get into production. The codex states that trunk is unstable and buggy, and that you should definitely not use it for production (I know you’re not doing that, I just want to warn any others that may come here.) Tracking the stable version is a bit harder since it relies on release tags rather than a pseudo head (like latest or stable or some such). Again, the codex gives a clue as to how to get a list of tags for releases, but it may still not be advisable to update a dev/test/staging area with the highest number on that list, given that the requirements may have changed. E.g. 3.2 requires php of at least 5.2 and mysql 5 which some people may not have upgraded to yet. This may not be a problem if you keep your dev box continuously upgraded with dependent software, but might be a problem for some people.
LikeLike
Thanks for the quick tutorial Lance. I use this on my personal sites (live) and haven’t had any problems yet. It seems that WordPress trunk is still reasonably stable despite the warnings.
LikeLike
You’re welcome Ryan, glad it’s helpful.
LikeLike