Make WordPress Core

Opened 16 years ago

Closed 15 years ago

#3565 closed defect (bug) (invalid)

Future Posting Bug (2.1 REV 4722)

Reported by: trent's profile Trent Owned by:
Milestone: Priority: high
Severity: normal Version: 2.2
Component: Administration Keywords: cron future
Focuses: Cc:


I am testing with REV 4722 and found that if I post a post in the future, it shows up under the 'scheduled entries' and has the countdown (in 10 minutes) with it. Once timer expires, the post doesn't publish or switch in the database from 'future' to 'publish'. The post timer actually starts increasing (in 2 minutes, in 3 minutes, etc). The only way to publish the post is after expiry (when it should post), is edit the post and push 'publish' and then it works. This is on a new install of WP 2.1 REV 4722


Change History (23)

#1 @ryan
16 years ago

  • Priority changed from normal to high

#2 @ryan
16 years ago

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

#3 @Trent
16 years ago

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.


#4 @Trent
16 years ago

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.

#5 @Trent
16 years ago

Sorry....apache server using Fedora core 2 on a server

#6 @ryan
16 years ago

  • Keywords cron future added

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.

#7 @Trent
16 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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.

#8 @foolswisdom
16 years ago

  • Milestone 2.1 deleted

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?

#9 @foolswisdom
16 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#10 @foolswisdom
16 years ago

  • Resolution set to worksforme
  • Status changed from reopened to closed

#11 @jonlandrum
16 years ago

  • Milestone set to 2.1.2
  • Version changed from 2.1 to 2.1.1

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

#12 @ryan
16 years ago

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.

#13 @jonlandrum
16 years ago

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?

#14 @jonlandrum
16 years ago

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

#15 @SCadente
16 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Version changed from 2.1.1 to 2.1.2

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.

#16 @drmike
16 years ago

  • Cc drmike added

With all due respect, this has been an ongoing issue with and WPMu for quite some time. There's a number of threads about it in the 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.

#17 @foolswisdom
16 years ago

  • Milestone changed from 2.1.2 to 2.3

#18 @zerohalo
16 years ago

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.

#19 @lizandlaura
15 years ago

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

#20 @gosuser
15 years ago

  • Version changed from 2.1.2 to 2.2

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:

/* Short and sweet */
define('WP_USE_THEMES', true);

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...

#21 @gosuser
15 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

#22 @foolswisdom
15 years ago

  • Milestone 2.3 (trunk) deleted
  • Resolution fixed deleted
  • Status changed from closed to reopened

#23 @foolswisdom
15 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.