Make WordPress Core

Opened 10 years ago

Closed 8 years ago

#2715 closed defect (bug) (fixed)

Future Posting Functionality Broken

Reported by: bloodylamer Owned by: ryan
Milestone: 2.1 Priority: high
Severity: major Version: 2.1
Component: Administration Keywords: future-posting future post
Focuses: Cc:


When date & time are set to sometime in the future, the post fails to appear @ set date/time. It merely sits in the manage post page @ the top & no sign of it on the actual website.

"Scheduled Post" section on the dashboard is no longer there as w/ 2.02 & previous versions.

Version: Using latest trunk from 5/10/06 of 2.1Alpha1

Change History (17)

#1 @ryan
10 years ago

[3773] fixes the "Sceduled Entries" section of the dashboard.

#2 @masquerade
10 years ago

To help debug the rest, I'm going to need some more info.

First, PHP version, webserver version, SAPI (apache module? ISAPI (IIS)? CGI? Fast-CGI?). I'll work on whipping up a plugin to test if the cron is working sometime this weekend if we still haven't resolved the issue.

#3 @bloodylamer
10 years ago

Masquerade...I hope this is sufficient.

CentOS release 4.3 (Final)
Kernel 2.6.9-34.EL
Apache/2.0.55 (Unix) DAV/2 PHP/5.1.2 Server

Also, following Ryan's fix of the "wp-admin/index.php" I did a test to see how scheduled entries would appear on the Dashboard.

I set it 5 minutes into the future. On the dash, the scheduled entry appeared reading "in 5 min." Once the time arrived for posting, the entry started to count up rather than posting on the front page. For example, after 10 minutes passed (includes the initial 5 minutes), it read "5 mins left." Hopefully a simple little bug...

I hope that helps. Please let me know if you require additional information.

#4 @masquerade
10 years ago

It appears my testing of this on CGI environments wasn't extensive enough. Like skeltoac warned before, it looks like the faux-fork we do isn't working.

I'll work up a patch this weekend that will transparently run the request to the cron daemon via iframe in themes (this will require compliant themes or the user to visit the login page or admin, is requiring a compliant theme something we can rely on (We just need a hook to the header and footer area, header to add a tad of css to hide our iframe, and footer to inject our iframe.)

Optionally, we could (Matt, this is pinging you), have requests that should trigger the spawn on CGI environments ping a special script on the wp.org server that would cause the wp.org server to spider the wp-cron.php file, although this does bring up worries on uptime on such a script.

Can anybody else think of another way besides the two listed above to achieve what we need?

#5 @bloodylamer
10 years ago

In reference to my last post, I have some more information.

That test post I referred to actually posted, but did so exactly 1 hour after it was set to post. Also, when it posted, the img src tag was stripped of the img url so image failed to appear when the post went live on the front page.

#6 @bloodylamer
10 years ago

  • Severity changed from normal to major

masquerade, have you made any headway on getting the scheduling functionality up & running? Let me know if you need anything else from me.

#7 @robmiller
9 years ago

If it happened exactly one hour after it was supposed to, are you sure it's not an issue with timezones/DST?

#8 @bloodylamer
9 years ago

Also, in reference to http://trac.wordpress.org/ticket/2737, when the post eventually goes live on the front page, any images that are in the post are stripped of the url & hence the image fails to post.

As for the this being a timezone issue: everything on my end is setup fine in terms of time. Maybe something is screwy in the WP code that is responsible for scheduled posting? I'm just a tester :-(, so sorry I cannot be be of much help.

#9 @ryan
9 years ago

Make sure the "Times in the weblog should differ by:" field in Options->General reflects the DST change. DST is not adjusted automatically.

#10 @bloodylamer
9 years ago

It is set to -4 as the weblog is based in the EST.

#11 @ryan
9 years ago

  • Owner changed from anonymous to ryan

#12 @ryan
9 years ago

[4077] fixes a few things.

#13 @ryan
9 years ago

Working okay for me now. Re-open if there are still issues.

#14 @ryan
9 years ago

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

#15 @johnmarkschofield
8 years ago

This does not appear to be fixed; possibly I posted my comment on the wrong bug: http://trac.wordpress.org/ticket/3742#comment:9

#16 @johnmarkschofield
8 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#17 @Otto42
8 years ago

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

If there's another ticket, please don't reopen this one.

Note: See TracTickets for help on using tickets.