#23133 closed enhancement (wontfix)
Display a warning in the admin if cron tasks fail due to blocked HTTP requests
Reported by: | Owned by: | ||
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | major | Version: | 3.5 |
Component: | Cron API | Keywords: | has-patch |
Focuses: | Cc: |
Description (last modified by )
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)
Change History (21)
#2
@
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)
#4
follow-up:
↓ 5
@
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
@
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:
- wp-cron is not being triggered on webpage visit.
- 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
@
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
@
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
@
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
#10
@
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
#13
follow-up:
↓ 15
@
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
@
10 years ago
- Milestone changed from 4.1 to Future Release
As per my comment above, this needs a little more work.
#18
@
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.
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...