Future Posting Bug (2.1 REV 4722)

I can't reproduce this one. Can you give some details of your environment? PHP version, http server, etc.

Ryan, sorry to take so long to reply. I have this on PHP Version 4.3.8 and mySQL 4.1.21. It was a fresh install that I have on a test site. I haven't touched it since, but am upgrading to 2.1 RC2 right now and testing it. I will report back.

Trent

I have thrown up some content on this blog and did an upgrade to 2.1 RC2 and timestamp edited a new post to post in future. Showed up as scheduled in dashboard with 4 minutes to post. 10 minutes later, it showed up as 6 minutes until it posts and increases every minute. This is a fairly major issue and I can't figure out why is not working.

http://wordpress.onvertigo.com

Sorry....apache server using Fedora core 2 on a tera-byte.com server

Can you check your access logs to see if wp-cron.php is ever being accessed? Future publishing is done by firing off a request to wp-cron.php from the current request. Maybe the server is somehow blocking that request to wp-cron.php.

Checked logs and it seems that it was calling the file fine and still no go. I changed the permissions on the file a couple of time (wp-cron) and tested it again. It seems to be working now. My only logic would be that the permissions were wrong on the file somehow. How, I am not sure. Seems to be cleared up and closing the ticket.

Trent, nice work tracking it down and following up here! I have been going crazy trying to reproduce this!

What were the wrong permissions? Was it just the one file?

It seems this is still an issue. Is the resolution CHMOD wp-cron.php 666? It was 644 in my install.

wp-cron.php does not need to be writable. It shouldn't need any special permissions beyond being readable by the web server like all of the other files in the WP distribution. We're still not sure what the cause of the problem is.

Thanks, ryan. I've been thinking that it could be a server-specific issue that Trent and I share. Not that we're on the same host, but perhaps we are using the same software. I'm getting my WP via Subversion on the stable trunk. Would that have anything to do with it?

You were right; chmod 666 didn't work. Maybe TextDrive don't allow cron-esque operations. I'll post this to their forum.

I've got the same problem here. I'm using WP2.1.2 on Site5 server (PHP4.4.4/MySQL4.1.21). Site5 ALLOWS cron-esque job unless it's excessive, so I guess there's something more than TextDrive/Cron? issue.

With all due respect, this has been an ongoing issue with wp.com and WPMu for quite some time. There's a number of threads about it in the wp.com support forums.

Only thing I can add in is that the cron record for that post does get pulled out/ removed from the options table for that post. I never had the chance to follow up on it afterwards.

I'm experiencing the same problem, running WP 2.1.2 with PHP 4/MySQL 4.1.

I'm not getting any permissions error in the httpd log.

I'm seeing the same issue with the default DreamHost configuration (WP 2.2, MySql? 5).

With a brute hack, finally i got this feature working again. Sorry for the last 3 posts, but i'm making a lot of test and i reported each single progress. To solve it:

chmod -R 775 * to set executable flag to each wp script.

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

#if ( $_GETcheck? != wp_hash('187425') ) # exit;

#if ( get_option('doing_cron') > time() ) # exit;

Then edit index.php and force the execution of wp-cron.php each time that the index.php webpage is loaded (yes i know that it will increase database calls... this is why it's a brute hack). To do so change your index.php with this one:

<?php /* Short and sweet */ define('WP_USE_THEMES', true); require('./wp-cron.php'); require('./wp-blog-header.php'); ?>

Now everyting should work, when the timestamp is reached && an user views your blog, it's automatically updated with new posts.

I'm still working for a "real" fix for this problem. until now it seems that normal wp 2.2 installation can't call wp-cron.php.

Ps: probably there should be a better solution, but for now it works...

Solved: It was a problem with DNS. Now it works like a charm now. You should be sure that request for your domain are answered with the same ip address of your host server. To do so i set up a custom bind9 server on the pc in which wordpress is installed.

I think that it's NOT a wordpress bug.