I was recently working on a project which involved using WordPress cron for some automated tasks. Although the function wrapping the call to the WordPress even scheduler reported being called, the ‘work’ was not being done (in this case retrieving data from a remote server).

This was particularly strange because if I ran the functionality manually it worked.

Note: I inherited this system from another developer so any references to code duplication are not of my doing!

Upon closer investigation I noticed immediately that the logic called in the wp_cron functions was different to the logic called when manually running the importer from the back end. This is actually one of my pet peeves so I immediately wanted to reduce that into one function.

Because the manually version worked, that was my obvious choice. The manual version worked by calling an updater page in the same installation using an ajax via jQuery’s get. Nice! Now all I’d have to do is call wp_remote_get on the same page and we’d be set.

I’m not quite sure what possessed me to believe that things would be this easy. Perhaps it was ‘the triumph of optimism over experience’, or perhaps it was bottle of extra-caf coffee I’d just polished off but for a brief moment the world looked bright and all my troubles seemed so far away..

I sat around for the next few minutes waiting for the confirmation mail to come in.. Then I waited a bit longer… Eventually as the last bit of optimism drained from my coffee infused soul I came to the stark realisation that once again I’d have to actually earn my keep. As the accountants say, “TANSTAAFL“!

I decided to leave it till the next morning. This turned out to be a fortunate choice because the next morning I did get 1 mail from the system:

  [http_request_failed] => Array
  [0] => cURL error 28: Operation timed out after 5005 milliseconds with 0 bytes received

It turns out the the cron task was timing out. Well that’s not so bad, I’ll just google for how to set that time and off we’ll go… Again, ‘the triumph of optimism over experience’. It turns out that I have a new maxim which states that ‘Google can answer any question about any topic, except the one you really really need right now’.

I eventually stumbled upon a some info about http_request_timeout which is set to 5 seconds by default, which corresponds nicely to my 5005 millisecond message above.

To fix that I simply needed to add a filter to my plugin’s main file to overwrite this value. Here’s what that looks like:

function overwrite_wordpress_timeout( $timeout ) 
    return 60; // seconds
add_filter( 'http_request_timeout', 'overwrite_wordpress_timeout' );

Having done that I’ve kicked the WordPress curl timeout up the bum and my code runs every 10 minutes like it should…

For now I can pretend that the world is perfect again as I sip on my hot brew…

Leave a Reply

Your email address will not be published. Required fields are marked *