Future Posting Functionality Broken

[bloodylamer]

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

[ryan]

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

[masquerade]

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.

[bloodylamer]

Masquerade...I hope this is sufficient.

PHP VERSION: 5.1.2
CentOS release 4.3 (Final)
Kernel 2.6.9-34.EL
SAPI: CGI
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.

[masquerade]

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?

[bloodylamer]

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.

[bloodylamer]

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

[robmiller]

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

[bloodylamer]

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.

[ryan]

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

[bloodylamer]

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

[ryan]

[4077] fixes a few things.

[ryan]

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

[johnmarkschofield]

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

[Otto42]

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