perceptionistruth

What bugs me most about the WordPress.com stats plugin is that it doesn’t appear to be able to work out which page people are viewing. I consistently get a very short list of pages viewed with very high hit counts, instead of a large number of pages viewed each with small hit counts (that google analytics and cystats show).

Either WordPress.com stats is broken, or somehow template layouts are confusing it (which I find hard to believe). Either way, it’s useless.

You can run cron jobs now, just point to wp-cron.php?

My post was simply to make sure people are aware of what ISP’s can get wrong which block WP talking to itself in the background.

I just spent two days diagnosing an issue like this on my web host (which had been working fine).

In my case, it turned out that the web server wasn’t able to receive HTTP HEAD’s through the Squid proxy in front of it.

WordPress sends an HTTP HEAD to check that wp-cron.php exists before loading it, and that was failing, so it was never running.

You can test this by using the command line curl to send HEAD requests to your site,

curl –head “https://your.site.here.com/blog/wp-cron.php” for example.

If you get any errors back, then ask your web host to investigate.

The other issue is that the WordPress code sends that request to the same URI you use to connect to the blog so it has to be able to talk to itself. Some hosts block outgoing connections from the servers, or don’t set them to be able to route correctly to themselves. That’s harder to check if you don’t have direct access to the server, but you could always ask a host provider to make sure it works.

Fixed, web host has changed squid config.

So, if everything seems to be ok, but your cron stuff isn’t working in WordPress, make sure you’re seeing the HEAD requests for wp-cron.php in your log. If you’re not, ask your host if they’re running a reverse squid proxy and if it’s blocking them.

You can check this yourself with curl, just do a –head request against wp-cron.php and see if you get a 403 Forbidden.

This is bad,

curl –head “https://your.site.com/wp-cron.php”
HTTP/1.0 403 Forbidden
Server: squid/2.7.STABLE5
Date: Thu, 08 Jan 2009 16:19:59 GMT
Content-Type: text/html
Content-Length: 1126
X-Squid-Error: ERR_ACCESS_DENIED 0
Connection: close

This is good,

curl –head “https://your.site.com/wp-cron.php”
HTTP/1.0 200 OK
Date: Thu, 08 Jan 2009 16:24:04 GMT
Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.8b DAV/2 PHP/5.2.6 mod_perl/2.0.4 Perl/v5.8.8
X-Powered-By: PHP/5.2.6
Content-Type: text/html
Connection: close

Looks like my web hosts squid install is blocking HEAD requests to /wp-cron.php, I’m working with them now to get that resolved.

I’ve tried increasing the timeout on

wp_remote_post($cron_url, array(‘timeout’ => 10.01, ‘blocking’ => false));

in cron.php, and I’ve tried changing it to a wp_remote_get, neither has any effect.

No matter what I do, wordpress doesn’t process the cron in the background, but I can still get it run by loading wp-cron.php directly.

The Core Control plugin shows me that cURL is working (to my own blog as well), and using the cron module I try to ‘run now’ the relevant cron jobs but they don’t run then either. So something is happening in or around cron.php which prevents WordPress from trying or managing to load wp-cron.php but I’m struggling to locate what it is.