Make WordPress Core

Opened 12 years ago

Closed 5 years ago

Last modified 2 years ago

#23133 closed enhancement (wontfix)

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

Reported by: prb22publicgmailcom's profile prb22public@… Owned by:
Milestone: Priority: normal
Severity: major Version: 3.5
Component: Cron API Keywords: has-patch
Focuses: Cc:

Description (last modified by SergeyBiryukov)

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)

Attachments (1)

cron.php.diff (4.6 KB) - added by loushou 10 years ago.
possible patch for check and message

Download all attachments as: .zip

Change History (21)

#1 @prb22public@…
12 years ago

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

#2 @prb22public@…
12 years ago

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)

#3 @prb22public@…
12 years ago

  • Keywords dev-feedback added; needs-patch reporter-feedback removed

#4 follow-up: @SergeyBiryukov
12 years ago

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

#5 in reply to: ↑ 4 @prb22public@…
12 years ago

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.

#6 @prb22public@…
12 years ago

  • Keywords 2nd-opinion added

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

#7 @SergeyBiryukov
12 years ago

  • Keywords 2nd-opinion removed

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.

#8 @SergeyBiryukov
12 years ago

  • Keywords needs-patch added
  • Summary changed from wp-cron fails to schedule posts to Display a warning in the admin if cron tasks fail due to blocked HTTP requests
  • Type changed from defect (bug) to enhancement

#9 @SergeyBiryukov
11 years ago

  • Description modified (diff)

Related: #11831

@loushou
10 years ago

possible patch for check and message

#10 @loushou
10 years ago

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

#11 @loushou
10 years ago

  • Keywords has-patch added; needs-patch removed

#12 @SergeyBiryukov
10 years ago

  • Milestone changed from Awaiting Review to 4.1

#13 follow-up: @johnbillion
10 years ago

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.

#14 @johnbillion
10 years ago

  • Milestone changed from 4.1 to Future Release

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

#15 in reply to: ↑ 13 @valendesigns
10 years ago

Replying to johnbillion:

Or maybe only show it if WP_DEBUG is true.

+1

#16 @SergeyBiryukov
9 years ago

#34143 was marked as a duplicate.

#17 @SergeyBiryukov
8 years ago

#38359 was marked as a duplicate.

#18 @goldsounds
8 years ago

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 (which is set to a default value of the current time if empty), 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.

Last edited 8 years ago by goldsounds (previous) (diff)

This ticket was mentioned in Slack in #core by sergey. View the logs.


7 years ago

#20 @peterwilsoncc
5 years ago

  • Keywords dev-feedback removed
  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.