Publish date remains date created instead of allowing for "Immediately"

[sararosso]

When drafting a post, if the date between creation & publishing is different, the post will often retain the creation date as the "publish time" instead of the "Publish: Immediately" default with no date/time associated with it.

If the post is scheduled, this the "default publish date" is overridden.

I did: Drafted a post one day and published it the next.

I expected: The post to have the date/time of actual publishing, since it wasn't scheduled.

I saw: The post had the date of drafting. "Publish: immediately" wasn't available either during the drafting process.

[danielbachhuber]

@sararosso just to confirm, in the Post Submit box, did the UI indicate the post was going to be "Publish: Immediately"? Or did it say "Publish: [Indicated Date]"?

[danielbachhuber]

Also, it would be tremendously helpful if you spent a little time trying to see if you can reproduce it consistently. My suspicion is that, even though it may happen more often than you'd like, it's specific to VIP and sporadic.

[sararosso]

It said "Publish: [Indicated Date]" where the date was not even the same day, but rather the day the draft had first been created.

I will absolutely try to recreate it again - it's happened several times.

[creativeround]

I'm having the same issue. It's taking the date the post was created instead of using the current time when "Publish Immediately" is clicked.

So what is happening is the post is published, but its old already because it could of been created a month before and now just published.

[creativeround]

I just wanted to fill in what is going on here

1. when you create a new post is says "publish: immediately" in the meta box
2. when you come back an hour later to the same article it will say "publish: June, 5th, 2013 14:23"
3. next, when an author clicks "Publish" button, it publishes at this date, not the current date.

It's almost as if the jquery is grabbing the hidden publish date and using it to save the post.

Anything I can do it test or help, please let me know.

[bruno-fernandes]

Experiencing the same thing. Any solutions for this at all?

[cojennin]

Similar issue #210

[cojennin]

Think this branch may fix the issue. If anyone has a moment to test it, that'd be excellent.

[creativeround]

I think you fixed it, here is what I did to test.

Testing Method #1:

1. Took an old post that was create in draft status on 10/20/2013 with a 10/20 last modified date.
2. Changed it to a different custom-status, clicked save.
3. Publish Immediate was still displayed.
4. Clicked Publish and the date was updated from 10/20/2013 to today's current time and date. Post permalink slug was also updated to reflect this publish date.

Testing Method #2:

1. Took an old post that was create in draft status on 10/14/2013 with a 10/14 last modified date.
2. Publish Immediate was displayed.
3. Clicked Publish and the date was updated from 10/20/2013 to todays current time and date. Post permalink slug was also updated to reflect this publish date.

Would you like me to test another method?

[cojennin]

Great! For Testing Method 1, you had not scheduled the post when you switched it to a different custom-status and clicked save? It was previously on published immediately and stayed on publish immediately when you switched, correct?

A Testing Method 3 might be checking if the post correctly stays scheduled when you switch from one custom status to another. I believe I already tested that case and it seemed to work, but another set of eyeballs would be excellent.

[cojennin]

I've pushed the changes onto master with the following commit: 00bc533. While this does fix issues related to dates and publishing times, we're still left with a small bug. If you schedule a post and save it then revisit the post later, reschedule it for the current time, Publish: immediately will be displayed instead of the scheduled time.

One of the issues with core is that a number of comparisons are made to 0000-00-00 00:00 (time when post has not been published). Since the time is always set with EditFlow custom statuses, we can't really make the same comparison.

If someone has some ideas on how to better implement this, that would be greatly appreciated. In the meantime, this commit should suffice until a better solution comes along.

In the meantime, I'll leave this issue open.

[cojennin]

Noticed a few more issues cropping up around this. Going to take it back to the drawing board and see if there's another possible alternative to fixing it.

[cojennin]

Things are looking pretty good so far with recent fixes. I'm going to punt this forward to the v0.8.1 milestone and leave it open, since I'm not 100% confident we've seen the last of datetime issues with custom statuses.

[cojennin]

Superseded by #301, should be fixed by #343. Closing.