How can I reduce any printing delays in the WordPress scheduled task system?

Some of the content of this article is more technical; it is not necessary to understand it unless you have a specific problem you are trying to solve. If you are unsure of something, then your web hosting company are the best people to help you with any particular technical advice in this article.

When a print job is created, it is registered in WordPress’s scheduled task system (known as “WP Cron”), with a time of “now”.

Though this usually means that the task runs within seconds, it does not guarantee that it will run instantly, because WordPress runs its scheduled tasks on a “best effort” basis. The list is consulted when new pages are visited (so if your site has few visitors, this may not be instant), and there may be others ahead in the queue. Some web hosting companies also degrade the WP Cron system based on a mistaken belief (unfortunately promoted in some articles by bloggers) that it has a performance impact. (The writer of this article has extensively reviewed and made minor contributions to improve WordPress Cron code, so claims to know it much better than bloggers passing on hear-say!). Also, some site owners disable the WP Cron system (usually for mistaken reasons) and replace it with a system of only calling it every few minutes, which makes it much less responsive. (If you have done this, you are strongly advised to reverse it).

Eliminating the WP scheduler #

If you wish to cut out the WP Cron system entirely, and send the print job directly at the checkout, then you can do so with these steps. Note that printing from the foreground in this way can mean the customer sees spinning icons for a few more seconds as the print job is prepared and sent. (This is why by default it is instead printed in the background using the scheduler).

To do this, you will need to use a WordPress filter:

  1. Create (if it does not already exist) the folder mu-plugins inside your wp-content folder, i.e. wp-content/mu-plugins
  2. In that folder, create a file with a name ending in .php – e.g. printnode-customisations.php
  3. Put content like this in the file:
add_filter('woocommerce_printorders_printnode_via_cron', '__return_false');

Trouble-shooting the WP scheduler #

If you want to use the WordPress scheduler, but print jobs go into it and don’t come out (or come out only very slowly), then here are some items to look at.

Maintenance mode? #

Firstly: is your website in maintenance mode? This disables scheduled tasks of all kinds – so turn it off first.

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.

Is your scheduler explicitly disabled? #

Perhaps your site has WordPress’s scheduler disabled in the configuration. You would normally know if you have done this, though perhaps someone else has worked on your site. 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.

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.

A convenient way to see if scheduled tasks are running is to install the free plugin “WP Crontrol”. After installing it, in the “Tools” sub-menu of your WP admin dashboard there is an entry allowing you to see registered tasks, and the times they should run out. You can use that to see if you have any overdue ones.

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);

Try adding 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.

You could also schedule external automated calls to the scheduler by using a service such as EasyCron – see: https://www.easycron.com/cron-job-tutorials/how-to-set-up-cron-job-for-wordpress

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 can get quite complicated. If you are not sure of the correct instructions for your particular server, then you may need to consult with either your web-hosting company or your local expert.

Still no good? #

If the scheduler’s brokenness remains and is not caused by one of the above reasons, then the problem is likely 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).