WordPress › Support » Schedule a post to be published at a future date: Does not work

jorgemarsa
Member
Posted 2 years ago #

jonlandrum said that find the solution with this:

Just edit wp-cron.php, comment out these two lines:

'6 if ( $_GET['check'] != wp_hash('123456') )
7 exit;'
and set up an hourly Cron job executing wp-cron.php using a CLI php binary like this:
/usr/local/bin/php /users/home/USERNAME/web/public/wp-cron.php

And it seems that worked for Terry too.

But I don't understand how to do it in wordpress 2.2.2. My archive is cron.php in which the most similar lines I have found are:

'if ( $argyle )
fputs( $argyle,
"GET {$parts['path']}?check=" . wp_hash('187425') . " HTTP/1.0\r\n"
. "Host: {$_SERVER['HTTP_HOST']}\r\n\r\n"
);
}

function wp_cron() {
// Prevent infinite loops caused by lack of wp-cron.php
if ( strpos($_SERVER['REQUEST_URI'], '/wp-cron.php') !== false )
return;'

What have I write exactly to fix the problem in those lines? I would appreciated any help, because I'm getting mad with this problem.
jorgemarsa
Member
Posted 2 years ago #

Does anybody knows some way or at least a clue about how to resolve the problem when the future posts don't appear in wordpress? Sorry if I insist, but it is a very serious problem to me.
Otto42
Moderator
Posted 2 years ago #

The fundamental problem is that your server is configured incorrectly or otherwise can't access itself.

No editing of the code will correct this fundamental problem. You can hack it to kinda/sorta work, but that's a crappy solution.

I'd suggest fixing the server. Lots of people have found that their server's DNS didn't work properly, or that their host was blocking fsockopen to local or things like that.
wpdprx
Member
Posted 2 years ago #

You can check out this simple plugin: http://wordpress.designpraxis.at/plugins/cron-demo/
to see if cron is kicked off or not.
jorgemarsa
Member
Posted 2 years ago #

I install the plugin cron-demo, but it seems the cron does not work. It does not send the e-mail, and when I clik to refresh this is the message: Cannot load cron-demo.php. Thank you, wpdprx, but I do not know how to do it after that.

Thanks to you too, Otto42, but could you be more specific, because I do not know what "fixing the server" means, or what to do it to figure out. I talked to my hosting, but they said to me they do not see nothing extrange in my server (I have host other two domains and blogs with them and work perfect: one in the same machine with wordpress 2.0, and the other one in a diferent machine with the same wordpress 2.2.2) and they need something more specific to try to help me.
Otto42
Moderator
Posted 2 years ago #

The problem is that we cannot tell them what's wrong with their server. We don't know what's wrong with their server.

WordPress makes an fsockopen request to the same website to run wp-cron.php in a separate process. If the server doesn't allow that, for whatever weird reason, then wp-cron fails to work.

Example:

Website: http://example.com/blog

A hit comes in to the site. It hits http://example.com/blog/index.php. This activates WordPress.

WordPress makes an fsockopen to http://example.com/blog/wp-cron.php.

If that fails, for any reason, wp-cron is not run, and the whole shebang is broken. There's lots of reasons it can fail:
- Some webservers stupidly can't lookup their own DNS names, so example.com cannot be resolved.
- Some webservers can do the lookup, but then can't connect to themselves due to the network layout.
- Some webservers are specifically disallows from doing fsockopen to themselves.

Who knows? The point is that a normal server *can* do this correctly. A server with some weird config or strange restrictions on it will break. Something about your hosts configuration is incorrect or broken. I have no idea what the problem is. All I know is that it is there.

Note that WordPress 2.0 worked in an entirely different way. It does not trigger this sort of problem on the server.
jorgemarsa
Member
Posted 2 years ago #

Thank you, Otto42. I will use your explanation to talk to my hosting and we will see what they say.
jaguar000
Member
Posted 2 years ago #

inspired by gosuser:

1)
edit wp-cron.php and comment the following lines:

#if ( $_GET['check'] != wp_hash('187425') )
# exit;

#if ( get_option('doing_cron') > time() )
# exit;
-------------------------------------------
2)
chmod 755 for wp-cron.php
-------------------------------------------
3)
then use http://www.webcron.org/ service and set new cron every hour http://mysite/wp-cron.php

it works!!!

Radek
Choco-cookie
Member
Posted 2 years ago #

Hitting the wp-cron.php, after making the edit, does not work for two of my WP installs.

I write my future posts

they sit there, pending

after the time passes, the clock starts clicking up

If I go into the sql tables, the status still says future. What I need is something to hit the status and change it to publish. hitting wp-cron.php is doing nothing

As for my host setup being the problem, I don't think that's the case. I have my own wp setup on a host (ace-host.net) and future posts don't work. I do the technical work for my friend's wp install on a totally different host (godaddy.com), and it too does not have future posts working.

there seems to be something wrong somewhere or there wouldn't be all these users having problems with something that worked perfectly fine before. Makes me wonder how many have just given up and are living without this awesome feature.

I wish I could do more in terms of finding a fix, but I don't know how to write in php, or how to make a script that would talk the sql tables into flipping the status of my posts.
jummy
Member
Posted 2 years ago #

Thanks for persisting on this, Choco-cookie.

I have tried searching for resources but no one seems to have an answer for why this function suddenly stopped working.
Otto42
Moderator
Posted 2 years ago #

I do the technical work for my friend's wp install on a totally different host (godaddy.com), and it too does not have future posts working.

This is false, future posts *do* work on GoDaddy hosting. I know, I use GoDaddy for a few blogs, they all work fine.

As for my host setup being the problem, I don't think that's the case.

I'm sorry, we really can't make it any more clear than we've tried to do. This is definitely not a WordPress problem, it's a problem with your host. You say you don't know much PHP scripting and such... Well, we do, and we're telling you the facts of the matter. You can not accept those facts all you like, but not accepting them does not change them.
Choco-cookie
Member
Posted 2 years ago #

Otto: your godaddy installs may be working for a number of reasons, different server, different hosting package (dedicated, virtual, shared), fantastico install vs manual install. My friend's wp blog has a future post that was suppose to show up over 130 days ago, so no, it's not working for all godaddy installs.

I'm going to keep plugging away at trying to figure this out, but at this point it's down to doing a complete wipe and reinstall. I'm afraid to bring over the sql database to a new install in case the bugs are buried in the tables, but I also don't want to abandon my 5+ years of posts.

My host (acehost.net) has been nice enough to check on the suggestions made in this and other support tickets (fsockopen, dns, etc) but could not find any problems.

And since I'm not the only one posting this problem, following this ticket, I'm not convinced "changing hosts" is the solution.
Choco-cookie
Member
Posted 2 years ago #

Fixed on one site:

Step 1: deactivate all plugins

Step 2: via filemanager/filezilla/ftp delete ALL PLUGINS & WIDGETS not in use. I'm prone to installing, trying, disliking, deactivating. I also had some plugins that didn't work with the current version of WP. I could activate them, but they didn't do anything (specifically King_framework). Messy, messy, much like my housekeeping.

Step 3: I delved into the sql tables. Some of the plugins I've used in the past made their own tables (who knew!).

Specifically:
wp_democracyA
wp-democracyQ
wp_events
wp_secureimage

I "dropped" these tables since I had deleted the plugins/widets in step 2. I first made a backup though!! While I was pretty sure they weren't in use, I wanted to be sure I could plop them back in the db if I was wrong.

Step 4: force upgrade the db. It pops up a few errors, but then says it's successfully upgraded. The errors are probably just housekeeping after dropping tables.

Step 5: delete any previously scheduled posts. I guess you could publish them again, but mine were all tests, so easily ditched

Step 6: set up a future post for a few minutes in the future.

Step 7: Wait...

Step 8: after the alloted time, refresh your blog home page (to run the cron processes). Did the test post publish? Did you wait long enough?

Step 9: after you have successfully published a test entry, start activating the remaining plugins you actually use. You can do it all at once (I did), or one by one if you are worried about conflicts.

Deactivating plugins did not fix the future post problem. Only the combination of dropping unused tables, forcing the upgrade, and deleting the unused plugins/widgets did it.

I would have never braved the sql tables if I didn't do a full site backup first. I also tested the other tables in a second fresh install, so I could figure out what tables were necessary, and which were just taking up space.

I would have never braved the sql tables if I didn’t do a full site backup first. I also tested the other tables in a second fresh install, so I could figure out what tables were necessary, and which were just taking up space.

Keep in mind that the wp-categories table is converted to wp-terms, wp-taxonomy, & wp-relationships when upgrading to 2.3 If you are testing in 2.2x, your sql will have this variance. If you’ve already upgraded to 2.3, do NOT delete the terms, taxonomy & relationship tables. These have the ‘categories’ and the new ‘tags’ feature.

Now I'm off to fix my friends wp install. I hope this helps someone else.
abatie
Member
Posted 2 years ago #

It may be a server configuration problem as suggested, but it's damn-all hard to know what wordpress is trying to do that's not working if it doesn't log an error somewhere when it tries to do something and it doesn't work. If the problem is some fsockopen call, if it would log what arguments it used and what error it got, it would probably take about 5 seconds to find and fix the problem. As it is, all I can see is that the scheduled time went by and the post didn't appear. Everything else about the site is working fine, including socket support enabled in php. Good error logging is the difference between a happy user and an extremely frustrated user.
abatie
Member
Posted 2 years ago #

OK, found one problem: in the Manage page, it shows my scheduled post test as I intended:

203 2007-10-27
9:15:49 pm Scheduled posting test

However, when I look in the database for the cron option value that wp-cron is fetching, I find it contains the timestamp "1193548549", which corresponds to 10:15:49 pm (using both perl and php's localtime function, and this is on the server system, so there shouldn't be any time setting inconsistencies to worry about).

I spent some time adding syslogs to try to see what was going on, but sure enough, after 10:15 rolled around, the post appeared. I thought maybe wordpress had some sort of safeguard making future posts be at least an hour in the future or something (just trying to give them the benefit of the doubt!), but put in a scheduled post for a few days from now, and it too was an hour off (late).

At this point, I've put more time into it than I want to; I only care about daily posting, so an hour or two isn't a big deal, but hope this helps someone who knows the system better than I do to track down the problem.

PS: this is with 2.3.1; I just upgraded before trying this stuff out to start with...
treedog
Member
Posted 2 years ago #

I have resently upgraded my client to 2.3.1. I don't see the "Future" status available in Manage/Posts. How can I find "scheduled" posts?
samudasu
Member
Posted 1 year ago #
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";
}
?>
```
liberalgeek
Member
Posted 1 year ago #

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 http://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.
ShropDave
Member
Posted 1 year ago #

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.