To keep your blog running smoothly, WordPress often needs to schedule tasks to run at certain times, or at some point in the future. Examples include scheduling posts for publication at a future date, generating backups and newsletters at regular intervals.
In order to make this happen, WordPress has an internal feature called wp-cron. In order to make WordPress easy to install, a nasty hack is used to execute wp-cron every time a visitor hits your site, or you do anything on the dashboard.
There are several problems with this:
-
It increases the load on your server, especially if you have a lot of visitors
-
It’s erratic, especially if you have few visitors or use a caching plugin like W3-Total-Cache
- There’s a bug that can cause it to execute multiple times in parallel, leading to annoying problems such as duplicate [intlink id=”662″ type=”post”]MailPress newsletters[/intlink]
-
It’s a hack
Notice that problems occur both if you have too many visitors, and if you have too few. And you should be using a caching plugin. All this is bad news.
For these reasons, I recommend you disable background execution of wp-cron by WordPress, and set up a real cron job in you host’s control panel to execute wp-cron at regular, predictable intervals. To do this, start by adding this to your wp-config.php:
/* Disable evil background wp-cron */
define('DISABLE_WP_CRON', true);
Then you need to create a real cron job to run wp-cron at regular intervals. On CPanel hosting services like HostGator, log in to your CPanel. Under the Advanced section at the bottom, click the icon labelled Cron jobs. Make sure the Cron email address is set correctly to your email address.
Add a new cron job, selecting Common Settings: Twice a day. If you know your blog needs finer scheduling then you can increase this to Once an hour say, but otherwise twice a day should be plenty.
Specify the command as:
/usr/bin/php -f /home/username/public_html/wp-cron.php >/dev/nullReplace username with your username. Initially you might want to leave off the >/dev/null bit so you can see the output and check that it looks OK. I don’t recommend redirecting the error output by adding 2>&1, because if there are errors you want to know about them.
If you’re on IX Web Hosting, note that Cron is under FTP -> FTP Manager -> FTP User -> Crontab and you’ll probably have to include a path to the PHP config file you use to increase the PHP memory_limit. So it’ll look more like this all on one line:
/hsphere/shared/php5/bin/php
-c /hsphere/local/home/username/domain.name/cgi-bin/php.ini
-f /hsphere/local/home/username/domain.name/wp-cron.php >/dev/null
If you happen to have enabled WordPress’s multisite feature, which is unlikely if you’re just creating a personal or small-business blog for yourself, read disabling multisite wp-cron.
And you’re done! We now return you to your regularly scheduled wp-cron task.
If you want to know more, here are some other articles I found helpful about disabling background wp-cron:
Run WordPress tasks from real cron job
How to disable WordPress wp-cron
27 Comments
Aaron · September 21, 2013 at 10:31 am
Hi Graham,
I am having a problem with woocommerce sometimes sending approximately 6 or 7 emails at a time. I have a feeling this might be to do with WP Cron – would you know for sure?
If I have around 12k visits to my site each month, will WP Cron be having a considerably negative effect on site performance? In other words, will it be noticably faster and use noticably less resources if changing to manual cron jobs?
Lastly, what time interval would you recommend we set for triggering manual cron jobs – about every 15 minutes? Or more/less frequently?
Cheers
Graham · December 6, 2014 at 11:34 am
I doubt it will make much difference if you’ve got 12k visits/month, but it may fix the email problem. Give it a try! I run mine once an hour, and that’s enough for me. Cheers, Graham
Sara - My Merry Messy Life · March 26, 2013 at 12:24 am
Hi Graham, great article. I’m having a lot of trouble with CPU throttling (then my site crashes) when I get a huge spike in traffic – could this be one of the reasons why it’s crashing (I’m on WordPress)? I also deleted 2 plugins that were hogging load time. A friend of mine told me to try this, too, but had a different command than your’s.
php -q /home/publier9/public_html/pieceofmind/wp-cron.php
Graham · December 6, 2014 at 11:43 am
The exact command will depend on your hosting service’s configuration. Try asking their tech support. Cheers, Graham
Dan · October 11, 2012 at 1:26 pm
Thanks for this excellent write-up Graham.
One question:
What’s the
-f
in the command line stand for?
Graham · November 3, 2012 at 11:12 am
It explicitly tells the php interpreter that the next argument is a file to interpret. I just checked the PHP manual and it appears to be optional in this case.
Rachel Ramey · September 21, 2012 at 4:37 am
I came across your post as I was trying to set this up on IXWebHosting.
I’ve copied-and-pasted exactly what you have here in the final field (changing my username and domain name, of course). I’m not certain it’s running, though. How can I check it? Schedule a post for a few minutes from now, and then see if it posts the next time the cron job is supposed to run?
Graham · November 3, 2012 at 11:20 am
Try testing it without the “>/dev/null” part, and a short cron interval. You’ll get an email every time the cron job runs.
Rigette · May 23, 2012 at 10:17 pm
Exactly what I need to solve my problem. Just a note about your site – the pop-up about liking the post on facebook and twitter can sometimes be annoying and I have to wait for around 20+ seconds before I could read your post. I hope you can do something about this, maybe lessening the time:)
Grady · April 10, 2012 at 2:27 am
Thanks for this post. Simple yet practical. I forwarded this to a friend that was being overrun by cron jobs and it was easy for them to implement. I think I’ll do a post and link back to this one if you don’t mind.
Dana Nourie · March 22, 2012 at 4:20 pm
I did what you suggest, but through the advice of my host. I disabled cron in the wp-config.php, set up a cron job in Control Panel, and set it to run once every 6 hours. When it ran, it brought my site down.
So, my question is, can I just leave it disabled and not run it at all? We post about 5 articles at most a week, although comments run higher. I don’t know of anything that is scheduled. So can I just leave wp cron disabled and not set up a cron to run it at all?
I’m using WP Super Cache, and all my plugins seem to be working fine when wp cron isn’t running. Thank you!
Graham · March 24, 2012 at 5:28 pm
The main thing that will break if you disable wp-cron altogether is scheduled posting. Some backup plugins also rely on scheduling. If you don’t rely on these feature it might not be such a problem, but I wouldn’t recommend disabling it altogether. Better to look into why running a cron job brings your site down; that shouldn’t happen! Cheers, Graham
Dana Nourie · March 26, 2012 at 5:17 pm
Thank you!
That helps a lot. I found that I can run that cron command, but I have to use curl instead of the php command. Apparently that is how my host, Lunarpages, is set. I tested and got the email cron had run.
Also, found a cool plugin called WP-Cron. It’s shows all the scheduled cron jobs. Mine calls updates for the theme, wp, and a few plugins, and has “execute tasks” for a few other specific plugins, and it shows the times they are scheduled for.
Lunarpages has asked me to set the cron to run wp-cron every 4-12 hours. That seems like it should work well. Hopefully this will help keep my CPU down.
You might put in the article, that if the php cron doesn’t run or throws errors, people might be able to run cron using curl instead:
curl /home/username/public_html/wp-cron.php >/dev/null
Thank you! This article was super helpful, as was your comment.
david ostrow · December 19, 2011 at 11:48 pm
I am now implementing this fix. One question…is the username my blog admin username, or my cpanel username. I would think the blog admin name, but thought I would check to be sure. Thanks for your help.
Dave
Graham · December 20, 2011 at 8:07 am
What you really want is the full path to your public_html directory on your hosting provider; your cpanel username is usually part of that. So no, it’s not your blog admin name.
If you’re implementing this to workaround the problem of multiple MailPress newsletters, note that WordPress 3.3 has recently been released and it is supposed to fix the bug that causes the problem. So there’s less need to disable background wp-cron once you upgrade to 3.3.
Cheers, Graham
LD Jackson · December 20, 2011 at 12:06 pm
I can confirm that the bug is not fixed in WordPress 3.3. The first thing I did was enable WP-Cron and delete all of my cron jobs. The first newsletter I sent out was sent twice.
Graham · December 21, 2011 at 11:06 am
Oh; that’s not good news. 🙁
LD Jackson · October 30, 2011 at 6:28 am
Okay, I discovered I had disabled wp-cron in the wrong wp-config file. My blog is located in a sub-folder of public html, instead of public html itself. Trouble is, when I insert the code to disable wp-cron in the correct file, my blog will not load. It just gives me a blank page. Any idea what could be going wrong?
LD Jackson · October 29, 2011 at 10:03 pm
Okay, I may have figured out what was going on, but I have one more question. If I disable wp-cron from running in the background and set up a cron job to run wp-cron at regular intervals, do I still need to choose wp-cron to send batches in the Mailpress settings, or do I need to choose other?
LD Jackson · October 21, 2011 at 12:11 pm
Because I am still having a problem with Mailpress sending out duplicate batches, I would be interested in knowing how to apply the patch EJ mentioned above. Does it require a lot of coding skills?
Graham · October 21, 2011 at 12:37 pm
You shouldn’t need the patch if you follow the instructions to disable wp-cron from running in the background and run it from a real cron job; unless something else is going wrong to generate the duplicate batches. Applying the patch would require some programming skills. However, it will be included in WordPress 3.3, which I expect will be released within the next few weeks; it is currently in its second beta test.
LD Jackson · October 21, 2011 at 1:04 pm
That’s the problem, Graham. I have followed your instructions to disable wp-cron and have created a cron job from cPanel to run the batch, but it still sends out duplicate batches. It doesn’t happen every time, maybe every other post, but it does still happen.
Here is the cron job I created.
php -q “/home1/gdjackso/public_html/mytake/wp-content/plugins/mailpress/mp-content/xtras/mp_batch_send/cron.php” >/dev/null 2>&1
OnePack · March 25, 2012 at 9:00 am
This is probably not because cron is fired 2 times but because the sending of the batch failed. When you have batches of 10 addresses maybe 5 users got the newsletter and the other 5 didn’t. When you set retry to 1 (or two perhaps) the newsletter module will process the batch that failed again and so 5 will get the newsletter two times and the other 5 just one time. A solution is to make your batches smaller.
EJ · September 17, 2011 at 7:41 am
I wanted to bring this recent bugfix to your attention. This should improve cron locking and (hopefully) prevent duplication, although I have not yet tested it personally, and have no data right now on what impact it will have on Mailpress performance or wp-cron reliability.
Regardless, I do encourage you to patch one of your WordPress deployments that relies heavily upon Mailpress, with this fix, and post your results. This would require switching away from invoking CPanel / linux server administered ‘cron tabbing’ back to WordPress’ internal wp-cron hooks. I would be personally interested in your observations regarding the impact of this bugfix, as I’m sure would your readers.
The added benefit is that, if you find (via this patch) wp-cron to be reliable again under various Mailpress test cases (low and high mail server load, variable batch levels, etc.), it could reduce the steps in configuring Mailpress, effectively streamlining the process you’ve outlined even further.
Finally, this probably goes without saying, but if you do decide to research this, please don’t test this on your production blog; if you have a test server use that, and if you do not, provision one! Great post and blog Graham.
Good hunting and regards. Please feel free to email me personally as well if you’d like to discuss ideas.
EJ
Graham · September 27, 2011 at 12:03 pm
Thanks EJ, this is really good news. I hope this will fix the bug Andre reported which causes the duplicate MailPress newsletters. I’ll put testing the patch on my TODO list; although it is rather long already I’m afraid.