Wp-calypso: Posts: scheduled posts aren't published after clicking "Publish" in the posts list

[designsimply]

Steps to reproduce:

1. Create and schedule a new post
2. Go to https://wordpress.com/ > My Sites > Blog Posts > Scheduled
3. Click "Publish" below the post

Result: clicking "Publish" in the list of scheduled posts triggers two messages, "Updating Post …" and "Updated," however, the post does not get published and remains in the scheduled posts list (2m52s)

^{Seen at https://wordpress.com/posts/scheduled/watchingstormsrollby.me using Firefox 45.0.1 on Mac OS X 10.11.13, also tested with Chrome 49.0.2623.87 on Mac OS X 10.11.13}

Possibly related: #3886, #3969

/hat tip @helenhousandi for the report

[lancewillett]

I can repeat this one — "Publish" action does not actually publish the post; I'd expect this action to change the post publish date to now (current day, time) and publish it, regardless of the future scheduled setting.

[alisterscott]

Confirmed this is still an issue:

[hoverduck]

This is still a problem. I did some investigation, and found the problem is that the API request (here) to publish it only sets { status: "publish" }. If you make it instead { status: "publish", date: new Date() } then it acts as expected, publishing the post with a timestamp of Now rather than whenever it was originally scheduled.

Of course I'm sure that by itself would have unintended consequences, and needs to be further refined, but I'm not familiar enough with how everything connects to say offhand what the full solution should be.

Hat tip to @catehstn for the ping saying it's still an issue

[lancewillett]

Another nudge today from @catehstn

Steps:

1. Schedule a post for PM
2. Realize you wanted AM
3. Click "Publish" to publish it now instead
4. Nothing happens

[mcsf]

Related: promoting a draft to published from within Posts

1. Go to Posts > Drafts
2. Click _Publish_ on a draft

3. Wait for completion

   • Expected: either remain in Drafts and have that selected post disappear once it's published, or be taken to Published and see that post in that list
   • Observed: navigation still stays _Drafts_ (_Rascunhos_ in screencast), but post counter is updated to reflect published count instead of drafts count.

[mcsf]

Concerning scheduled posts, two observations:

• Seeing the label _Publish_ in _Posts > Scheduled_ can be confusing ("didn't I already say I wanted this published in the future?"). What that button actually aims to do is "Publish Now Instead".
• From what I see, the editor itself doesn't offer such a "Publish Now Instead" option for scheduled posts. Instead, it allows the user to set the publishing date to something in the present/past and publish. Same goes for WP-Admin.

Coming up with a transversal way of dealing with scheduled posts that is clear and comforting for the user would be nice.

[lancewillett]

Related to this flow, but I know separate for the implementation, are two glaring bugs or UX gaps:

1. https://github.com/Automattic/wp-calypso/issues/13769 — the time zone and format in the scheduled post picker doesn't always match the blog settings (24-hour setting but shows AM/PM text label; time zone of the local user shown in the picker instead of the blog's time zone).
2. https://github.com/Automattic/wp-calypso/issues/11316 — can't set the time zone for a Jetpack site in Calypso yet.

[iandunn]

To expand on Scott's findings, the root cause is that Core's wp_insert_post() expects posts being published to have a post_date_gmt in the past. If it detects a future date, then it'll override the post_status to future.

I can reproduce the issues that @mcsf reported above, but they seem to have different causes.

For context, Core doesn't have a similar flow to Calypso for this, where you can publish from the All Posts list. In wp-admin, you have to navigate to the Edit Post screen, and either:

• A) change the status from Scheduled to Draft, then update the post, then publish the post; or
• B) set the date to be in the past, and then publish the post.

If you do A, then Core wipes out the date, and wp_insert_post() later sets it to be the current timestamp, because wp_insert_post() doesn't expect drafts to have a date set. If you do B, then you've explicitly set a valid date, and everything gets processed succesfully.

Back to Calypso... The WPCOM API endpoint already explicitly sets valid dates for drafts before wp_insert_post() is called, so it seems like we'd just need to expand that to cover scheduled posts as well.

@hoverduck, you mentioned some unintended consequences, though. I'm not seeing anything in my testing so far, can you point me in the right direction?

[iandunn]

If anyone's curious, I've prepared D6575-code with the proposed changes.

[iandunn]

This is fixed as of r160864-wpcom.

Since it was API-side, it'll need to be merged into Jetpack to work on Jetpack sites. The patch was tested with one, though, so it should work without any modifications to the endpoint. CC @dereksmart