WordPress has a system for running scheduled tasks in the background. This does lots of useful things – things like clearing up internals (theent equivalent of taking out the garbage), checking for available updates, and performing actions that plugins want doing at a set time, or regularly (like optimizations!).
If you have received a notice that your WordPress scheduler does not seem to be running tasks, then this page is for you.
Firstly, if nobody has visited your site for a while, then this situation is expected. WordPress only gets the opportunity to do things when people visit pages. No pages = WordPress is never called upon = WordPress cannot kick off any background tasks. So, if your site is a development site, or has been moth-balled for some other reason, then this message is not surprising. Visit a few pages, and the message should go away. If not…
What can cause this problem?
1. Maintenance mode?
Firstly: is your website in maintenance mode? This disables scheduled tasks of all kinds – so turn it off first.
2. No visitors?
WordPress’s scheduler relies on the site having visitors. No visitors means that WordPress doesn’t run, and therefore can’t hand over to the scheduled task. If your site is in development, and you schedule a backup run for a time when all the developers are asleep, then that may be the cause for the scheduled task not running.
3. Is your scheduler explicitly disabled?
Perhaps your site has WordPress’s scheduler disabled in the configuration. To check manually, look for a line like this in your wp-config.php file (which is found in the root directory of your WordPress install), and remove it (or change true to false, making sure there are no quote marks around false):
define('DISABLE_WP_CRON', true);
In this case, the disabling may be something your web hosting company did intentionally, so be aware that they may re-disable it. Or, it may be something that you did intentionally, and you may have set another means of calling WordPress’s scheduler system, perhaps via your web hosting company’s control panel. In that case, the message about DISABLE_WP_CRON is to be expected – but note that it is then your responsibility to make sure that the scheduler is called frequently enough to process all the jobs scheduled on your site. No optimizations will run until the time that you have set the scheduler system to be called.
Also – note that it’s possible for DISABLE_WP_CRON to be set in a file other than wp-config.php; wp-config.php is simply the most likely (99%) place. If you have a warning about DISABLE_WP_CRON, but it is not found in wp-config.php, then it will be somewhere else – you will need to hunt for it.
4. Loopback connections are not working?
Some web hosting providers (one big one: Heart Internet) purposefully (though for no good reason) disable the “loop-back” connects that allows WordPress to run its scheduler. This is also the case if your website is password-protected. If loopback connections are not working (whether deliberately disabled or not), you can try this use WordPress’s alternative scheduling system – instructions here. The instructions amount to one thing: add a line anywhere in the middle of your wp-config.php file as follows (don’t add it too late in the file, or it will take no effect):
define('ALTERNATE_WP_CRON', true);
5. Try using a cron job
If your web hosting company gives you “shell” access and you can set up cron jobs, and if you are confident/skilled enough to use that, then that’s a great solution. Jobs run that way won’t face any time-out issues imposed by the webserver. Read more about running via the shell here.
6. Is your entire website password-protected?
Another cause is if your entire website is password-protected at the HTTP level (e.g. via a .htaccess file). This also prevents WordPress’s scheduler from working. You should configure your webserver to allow “loop-back” connections (i.e. connections to self), otherwise you WordPress scheduler and everything that depends upon it will be broken. If you are using Apache and .htaccess, then adding these two lines to the access control section of your .htaccess should work – after replacing a.b.c.d with your website’s IP address):
Allow from a.b.c.d Satisfy Any
Please note: The above suggestion is just a suggestion. .htaccess configuration is a very big subject. WP-Optimize neither “supports” nor “doesn’t support” different .htaccess configurations, because .htaccess files operate at quite a different level to WordPress plugins. If you enter the correct instructions in your .htaccess file to permit access, then WP-Optimize will work. But if you are not sure of the correct instructions for your particular server, then you need to consult with either your web-hosting company or your local .htaccess guru.
7. Still no good?
If the scheduler’s brokenness remains and is not caused by one of the above reasons, then the problem is almost certainly with your web hosting provider. If the alternative scheduler also fails, then you need to either contact your web hosting company for support (ask them if loopback connections work, and if not, if they can enable them); or failing that find a different web hosting company. If they confirm that loopback connections are disabled and say that it is necessary for security, then this is nonsense. (A website connecting to itself can do nothing more or less than anything else connecting to the website can). In such a case, you will need to find a new hosting company in order to use any scheduled task (including WP-Optimize) within WordPress (if you want UK-based hosting, then you could consider Simba Hosting – excellent WordPress support, a 1-click installer, and will give you a 20% discount if you mention this article at sign-up time).
Posted in: Troubleshooting
Recent Comments