Schedule a post to be published at a future date: Does not work

On my host the problem was that the server could not connect to itself with fsockopen(“www.myserver.com”) at it’s external ip address due to firewall rules. This is exactly what needs to happen in order for wp-cron.php to run correctly. My fix was to add an entry to the server hosts file enabling fsockopen() to open www.myserver.com at it’s internal ip address.
In my case the new hosts file entry looks like this..

10.10.10.123 www.myserver.com

Here’s a quick script that tests your internal/external ip addresses and lets you know if fsockopen() is working correctly. Like i said it’s quick and not guaranteed to work but it won’t hurt anything. Change line 2 and save it as iptest.php in your wordpress directory then open it with your browser.

<?php
$siteurl = "www.yourserver.com"; //change this to the url of your site
$external_url = gethostbyname($siteurl);
$internal_url = $_SERVER['SERVER_ADDR'];
print "<pre>\nExternal url: $external_url\n";
print "Internal url: $internal_url\n";
$fp = fsockopen($siteurl, 80, $errno, $errstr, 30);
if (!$fp) {
    print "$errstr ($errno) - There's a problem with your server configuration.\n";
    print "It's also possible that fsockopen() is disabled on your server.\n";
    print "Have your server administrator try adding a line in the server hosts file that reads:  $internal_url\t$siteurl\n</pre>";
} else {
    print "Your server configuration seems to be ok for using Post Timestamp.\n";
}
?>

Hi all,

I was having the same problem once I moved to a new host. I have figured it out. Luckily, the hosting company is run by a friend of mine. YMMV.

The issue that I was having was caused by the design of the network on which the site is hosted. In order to improve the performance, my host load-balanced across 3 servers using some form of load-balancer. The nodes that actually serve the pages have private addresses. Finally, my site is hosted with name-based virtual hosting (several sites behind a single IP address). I would think that this is a VERY common design.

WordPress apparently executes a request originating from the node to blogname.com/wp-cron.php. That does not work from the nodes. The nodes do a DNS lookup, but it returns the external address and sends the request out to the load-balanced address. This usually won’t work due to NAT issues.

If you have shell access to your site, you can test this by issuing the command:

wget https://blogsite.com/wp-cron.php

It will likely fail. If so, we have found the culprit. Now how do we fix it?

I see several possible solutions, but the easiest seems to be to create an entry in the /etc/hosts file on each node to trick the server into hitting its inside address. This could be integrated into Fantastico and others’ auto-installs. However, some hosts might be iffy about doing it.

You could build loopbacks on the nodes (same as the outside address), but you would also have to add the loopback to the apache vhost config. This would trick the server into staying local to fetch the URL.

The ISP could have different DNS for the inside to serve the nodes the private addresses.

Ideally, WordPress will change the code to execute the fetch differently. I’m a network guy, not a coder.

One of the websites I work on has been having this problem on frequent occasions. Their problem is that some future-dated posts do not get published once their time comes around, and on a couple of rare occasions they have had a future-dated post getting published months early!

My searching has led me to the scheduler within WordPress. As far as I can tell future-dated posts get an entry within the scheduler which will publish the post (via publish_future_post) once the time comes around. However, the posts we have problems with aren’t listed in the scheduler. Choco-cookies forcing a database upgrade seems to work because afaik it re-creates the entire schedule from a raw database request of all future posts.

There must be a bug, caused by (so far) unknown conditions that causes a future-dated post to be removed from the scheduler and thus never get published.