Display a warning in the admin if cron tasks fail due to blocked HTTP requests

[prb22public@…]

I recently upgraded my very simple WP site to 3.5 where the following was in use:

Theme: Twenty Eleven
Plugins: None Activated

I have been completely unable to submit a post for publishing in a future date, when the time occurs, I get a "missed schedule" message.

The schedule entry in cron is as follows:

Next due (GMT/UTC): Jan 4, 2013 @ 11:28 (1357298880)
          Schedule: One-off event
              Hook: publish_future_post
         Arguments: [0]: 358

Increasing the timeout value in cron.php has made no difference.

I will need to remain on a lower release until this is fixed or a diagnosis "kit" is made available.

I am not using any software other that WP produced at this point and feel that the lack of wp-cron documentation and support in the public domain leaves alot of people clocking many hours googling in desperation...

Make a difference in 2013 and get 3.5 development priorities to de-mystify the methods of fixing wp-cron please :o)

[prb22public@…]

I have since re-installed wordpress from scratch using a fresh database and directory in a sub-domain ​http://dev.crinniswoodmanagement.co.uk

It has no plugins or themes or child data, literally "out of the box" and it fails to publish a scheduled test post where everything else works.

Happy to hand over the admin keys to the web interface if I somebody wants to look under the hood and assist/troubleshoot root cause...

[prb22public@…]

PHP Version 5.3.10

MYSQL details (obtained from phpMYAdmin on 8th January 2013)

Server: Localhost via UNIX socket
Software: MySQL
Software version: 5.5.25a-log - MySQL Community Server (GPL)
Protocol version: 10
User: xxxxxx@localhost
Server charset: UTF-8 Unicode (utf8)

[SergeyBiryukov]

Related: #19621. The only change to cron in 3.5 was #13449.

Does the site actually get visited in order for the cron task to run in time (see ticket:17888:4)?

[prb22public@…]

Replying to SergeyBiryukov:

The dev site I have setup specifically to diagnose the issue does not get visits from anyone apart from myself during the tests to get the scheduler to work.

I appreciate there is a need for a "visit" to kick off cron entries, but this does not appear to occur and posts stay in "missed schedule" status, implying one of two things:

1. wp-cron is not being triggered on webpage visit.
2. wp-cron is perhaps being triggered (how do I check this?) but is not picking up past entries/hooks that have missed the schedule date/time.

This does appear to be prevalent in 3.* versions of WP and perhaps increasing dependancy on the mechanism is causing a lot of concern in communities where debug documentation is poor. I'd really like somebody to deep dive into my dev site where they can see first hand the problem if they are unable to replicate elsewhere.

[prb22public@…]

I would really welcome development look over the installation to be able to diagnose the issue which could be useful to the wider community.

[SergeyBiryukov]

Your host appears to block local HTTP requests.

WP_Http_Curl didn't return an error, just an empty response (I've created #23310 for that). However, this simple example displays "Curl error: couldn't connect to host" when being run on your server:

function curl_test_23133() {
	$ch = curl_init();

	curl_setopt( $ch, CURLOPT_URL, 'http://dev.crinniswoodmanagement.co.uk/' );
	curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );

	$result = curl_exec( $ch );
	if ( false === $result )
		echo 'Curl error: ' . curl_error( $ch );
	curl_close($ch);

	echo $result;
}

Other transports also returned errors:

WP_Http_Streams: Could not open handle for fopen() to ...
WP_Http_Fsockopen: "110: Connection timed out"

The workaround is to use ALTERNATE_WP_CRON:
​http://codex.wordpress.org/Editing_wp-config.php#Alternative_Cron

Another option is to add DISABLE_WP_CRON to your wp-config.php file and set up a cron job on the server to hit wp-cron.php every 1, 5, or 10 minutes, or whatever you prefer.

We could probably detect this situation and display some kind of warning in the admin.

[SergeyBiryukov]

Related: #11831

[loushou]

possible patch for check and message

[loushou]

Hey there. I added a possible patch for this. The patch, twice a day, does a check to see if the server allows internal requests back to itself. If it does, we use the normal cron method. If it does not, then we force it to use the alternative method, and we pop an error in the admin showing that we are forcing the Alternate Cron method. We probably need someone to come up with some proper verbiage for the message if we are sticking to using a message here. If not, the check still does work, and could be used to force alternate cron as a fallback, without a message.

Loushou

[johnbillion]

If we automatically fall back to alternate WP-Cron, we should do it silently and not pester the user with an admin message. Or maybe only show it if WP_DEBUG is true.

[johnbillion]

As per my comment above, this needs a little more work.

[valendesigns]

Replying to johnbillion:

Or maybe only show it if WP_DEBUG is true.

+1

[SergeyBiryukov]

#34143 was marked as a duplicate.

[SergeyBiryukov]

#38359 was marked as a duplicate.

[goldsounds]

As a side note, in my experience for some hosts alternate cron is broken too. Yes, I know it seems crazy. So I'm not 100% sure about using it as an automatic fallback.

In addition, some hosts may have defined an external cron and that, too, might be broken - and the user still ought to be informed.

A technique which might work is to schedule a cron job to run once every 12 hours. The cron job sets a timestamp, and if that timestamp becomes stale (say, 48 hours old) then we let the user know that cron might be broken, and give them a link to click.

The link brings them to a page which checks the loopback functionality, and lets the user choose from available options, like:

If they have DISABLE_WP_CRON enabled:

"You have disabled WordPress' scheduler, but your external scheduler doesn't appear to be working. Would you like to fix this?"

• No, I know what I'm doing, everything is fine
• Whoops, this was a mistake - I will remove the line define('DISABLE_WP_CRON', true); from wp-config.php

If they have ALTERNATE_WP_CRON enabled, but we can tell that Loopback works fine.

"You have enabled ALTERNATE_WP_CRON but it doesn't appear to be working. Our tests indicate you can safely disable this flag and use WordPress' default scheduler. Would you like to do this?"

• No, I know what I'm doing, everything is fine
• Yes, I will fix this by removing the line define('ALTERNATE_WP_CRON', true); from wp-config.php

If they have ALTERNATE_WP_CRON enabled, AND loopback is failing.

"WordPress has detected that scheduled tasks aren't being run, and we can't figure out why. Please visit [link] for information on troubleshooting this issue"

Something like that would give us coverage of all the scenarios I can think of.

[peterwilsoncc]

I'm closing this off as the site health check includes checks both to confirm scheduled tasks are running and to confirm loopback requests are working.