Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I get this PHP Warning when accessing my fresh WordPress 3.4.1 install (Norwegian language).

Warning: fopen(URL_TO_MY_WORDPRESS_PAGE/wp-cron.php?doing_wp_cron=1341476616.7605190277099609375000): failed to open stream: Connection timed out in PATH_TO_MY_WP_FILES/wp-includes/class-http.php on line 923

This is of course with the WP_DEBUG flag set to true, as it's running on a development server.

enter image description here

This happens intermittently, so it seems to be a problem with wp-cron.

Is this likely an error in WordPress or something wrong on my server? Should I worry?

The server is a fresh Ubuntu Server 12.04 VM with the LAMP stack.

Google search shows I'm not the only one experiencing this. (See buffered/indexed versions of pages listed to see the actual errors.)

EDIT: I'm also getting this same PHP Warning on the front page. Could it be related to the fact that the webserver is being NATed to? Currently I've set up the firewall to point port 19235 to 80 on the development server.

share|improve this question
    
In your php.ini file, is allow_url_fopen set to ON? –  its_me Jul 5 '12 at 9:25
    
Yes, allow_url_fopen = On –  ohaal Jul 5 '12 at 10:19

1 Answer 1

up vote 10 down vote accepted

The answer is apparently YES, I should worry. After some research, I've found that the warning seems to be related to misconfigurations on the server that WordPress is hosted on (ie. a problem with my server, not WordPress).

Common misconfigurations:

  1. Server doesn't have DNS, and so it can't figure out who "example.com" is, even though it is itself.
  2. Server administrators, in a misguided attempt at security, have blocked "loopback" requests, so it can't actually make a call back to itself.
  3. Server is running something called "mod_security" or similar, which actively blocks the call due to brain-dead configuration.

The problem in my case was actually caused by my firewall (pfSense), which has "Disable NAT reflection" by default (listed as common reason #2).

On the server itself, I tried to reach myself using telnet, and the result was as follows:

$ telnet external.server.hostname.com 19235
Trying XXX.XXX.XXX.XXX...
telnet: Unable to connect to remote host: Connection timed out

To fix this, I had to uncheck Disable NAT reflection on my firewall. In my case, this was in the web interface of pfSense under System->Advanced->Firewall/NAT.
Source: http://forum.pfsense.org/index.php?topic=3473.0

enter image description here

Now I can connect to myself (on the server itself) through the firewall just fine:

$ telnet external.server.hostname.com 19235
Trying XXX.XXX.XXX.XXX...
Connected to external.server.hostname.com.
Escape character is '^]'.

and I am no longer getting the PHP warning about wp-cron.


I figured this out after reading this detailed answer regarding wp_cron, explaining how it works.

Short answer: Add this to the defines in your wp-config.php file: define('ALTERNATE_WP_CRON', true);

Really long answer, for masochists: Scheduled posts are not now, and have never been, "broken". The developers of WordPress cannot fix it because there is nothing to fix.

The problem lies in the fact that your server, for some reason, cannot properly execute the wp-cron process. This process is WordPress' timing mechanism, it handles everything from scheduled posts to sending pingbacks to XMLRPC pings, etc.

The way it works is pretty simple. Whenever a WordPress page loads, internally WordPress checks to see if it needs to fire off wp-cron (by comparing the current time with the last time wp-cron ran). If it does need to run wp-cron, then it tries to make an HTTP connection back to itself, calling the wp-cron.php file.

This connection back to itself is there for a reason. wp-cron has a lot of work to do, and that work takes time. Delaying the user seeing his webpage while it does a bunch of stuff is a bad idea, so by making that connection back to itself, it can run the wp-cron program in a separate process. Since WordPress itself doesn't care about the result of the wp-cron, it only waits a second, then goes back to rendering the webpage for the user. Meanwhile, wp-cron, having been launched, does its work until it's finished or it runs out of execution time.

That HTTP connection is where some badly configured systems fail. Basically, WordPress is acting like a web browser. If your site was http://example.com/blog, then WP will call http://example.com/blog/wp-cron.php to start the process. However, some servers simply can't do that for some reason. Among the possible reasons:

  1. Server doesn't have DNS, and so it can't figure out who "example.com" is, even though it is itself.
  2. Server administrators, in a misguided attempt at security, have blocked "loopback" requests, so it can't actually make a call back to itself.
  3. Server is running something called "mod_security" or similar, which actively blocks the call due to brain-dead configuration.
  4. Something else.

The point is that for whatever reason, your web server is configured in some non-standard way that is preventing WordPress from doing its job. WordPress simply can't fix that.

However, if you have this condition, there is a workaround. Add this to the to defines in your wp-config.php file:

define('ALTERNATE_WP_CRON', true);

This alternate method uses a redirection approach, which makes the users browser get a redirect when the cron needs to run, so that they come back to the site immediately while cron continues to run in the connection they just dropped. This method is a bit iffy sometimes, which is why it's not the default.

Source: http://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282#post-1175405

As stated in this great and detailed post, if you have no control over your servers configuration or, if applicable, the environment - a workaround is to put

define('ALTERNATE_WP_CRON', true);

in your wp-config.php file.

share|improve this answer
3  
Very nice report! –  brasofilo Jul 5 '12 at 10:10
2  
It's nice when people solve their own problems, but awesome when they come back to drop the solution. @ohaal So, is everything okay now? –  its_me Jul 5 '12 at 10:41
1  
@AahanKrish: As it turns out, I was a bit quick on the trigger finger. The problem was a bit more convoluted than first expected - the culprit was not, as initially anticipated, the apache2 error. I've updated my answer with the details. –  ohaal Jul 5 '12 at 12:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.