If you are a WordPress developer then you already know the agony that is WP-Cron.
If you’re not a developer and are wondering why your posts miss their schedule and your backups never run… read on.
WordPress has an internal scheduler that runs tasks (like scheduling posts) periodically called WP-Cron. And it really, really, really sucks.
I covered a bit of disabling WP-Cron in part of my previous How to Backup your WordPress Website article. This is a step-by-step guide.
Why WP-Cron Sucks
You would like to think that if you set a post to be published at 3pm on a Friday afternoon, just as you are heading to the pub for a few well deserved beers, that come 3pm and by some marvel of intewebs magic, your post would get published.
Erm.. yes and no. Perhaps. Maybe. Well it depends really…
The WP-Cron system in WordPress does not run “all the time”.
It is not an independant scheduler that is always running in the background looking for an event to action.
Rather, WP-Cron only “runs” when people visit your site.
Hang on. Did you say that right?
Yes I did.
When a visitor looks at your website, the page request triggers WP-Cron into life and only then it will have a look to see if there is anything needing action.
So, no visitors = no scheduled events. …and it gets worse!
Why Shared Hosting Sucks Even More than WP-Cron
If you are on a shared hosting plan and your WordPress posts always miss their schedule, here’s why.
The WP-Cron system uses something called HTTP Loopback, where a web page can send actions to itself.
This is also known as a recursive call.
An iteration of calls that can, under certain circumstances, lead to an infinite loop that draws more and more machine resources until *BAM*. The server falls flat.
Shared hosting means perhaps 80-100 other websites share the same physical server as your website and if the server goes down then all those other website fail.
Not surprisingly most web hosting companies disable HTTP Loopback on their shared server plans.
No HTTP Loopback = no WP-Cron.
OK – bad news over.
Here’s what you can do to resolve all this silliness.
The term WP-Cron was derived from the UNIX cron system which is an operating system level even scheduler (yes it runs ALL THE TIME).
I’m going to show you how to disable the WP-Cron and implement your own permanent cron system that will ensure your scheduled posts and backup plugins and whatever else needs to be scheduled, runs all the time in WordPress.
cPanel is the most common hosting interface so I’ll be using that as the example here but as long as your hosting plan has some access to the server’s Cron you’ll be able to replicate the same results.
Step 1 – Disable WP-Cron
To disable WP-Cron in WordPress you need to add a line to the wp-config.php file that you can find in the root folder of your WordPress installation.
You can use File Manager in cPanel to edit the file, or FTP the change up from your local machine.
Step 2 – Create a new Cron Job
In cPanel go to the Advanced section and click on the “Cron jobs” icon.
This will open the Cron Jobs page.
The cPanel cron interface is very easy to use and has a drop-down list of commonly used schedules.
The one we’re going to use is every 5 minutes. Select that from the dropdown.
This populates the schedule for the cron job.
Now all we have to do is add the command to manually run the WP cron. This is done by running the wp-cron.php file in the root of your WordPress installation.
There are a couple of ways of doing this but the simplest to implement is to run the PHP file using PHP itself.
On linux servers the PHP binary is usually located at /usr/bin/php. You’ll need to check with your web host though just to make sure – they’ll know.
You will also need to know the complete directory path to your WordPress installation (usually in a folder called public_html).
You’ll find this information in your cPanel homepage, on the left in a column called “Stats” and with the label “Home Directory”.
If you’re unsure whether your site lives in a folder called public_html, open up File Manager and locate your wp-cron.php file. Note the directory entire directory structure.
In the example above, the complete path to the wp-cron.php file is /home/limecanvas/public_html/wp-cron.php.
Type the following into the Command box on the Cron Tab settings, using your own path to your wp-cron.php file.
[codelet]/usr/bin/php -q /home/limecanvas/public_html/wp-cron.php[/codelet]
The first part of the command is /usr/bin/php -q
This runs the PHP binary with the -q switch. -q tells PHP to be quiet. Shhhh – don’t print anything out on the screen.
The second part of the command is your own path to your wp-cron.php file.
Sorry to labour on the point but this is not a copy and paste job. This is only going to work if you put your own path to the wp-cron.php file in there.
Click on the Add New Cron Job button and you should see your new Cron Job added at the bottom of the screen like this:
Congratulations! WP Cron scheduling will now work on your WordPress site.
Test it by scheduling a quick post for 10 mins time.
Using the wget Method
If you are unable to locate the PHP binary file, you can use another method to call wp-cron.php called wget. I’ve had mixed results with this.
Rather than use a folder structure, wget uses a URL. So in the Command box of the Cron Tab settings type:
[codelet]wget http://limecanvas.com/wp-cron.php?doing_wp_cron=1 > /dev/null 2>&1[/codelet]
Replace www.limecanvas.com with your own URL of course.
The last part of the command /dev/null 2>&1 tells the server not to output anything to the screen.
The Alternative Cron Method
Just for completeness there is another method of calling WP-Cron from within WordPress and it’s called “Alternative Cron“.
I’ve tried it and it doesn’t come up to scratch. The codex says it all really
“This method is a bit iffy sometimes, which is why it’s not the default.”
The worst part about using the Alternative Cron method is that is appends “?doing_wp_cron=2948209834520948209247209” to absolutely every URL in your site which Google Analytics throws a wobbly at.
This will ruin your SEO, so stay clear.