search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.36k stars 4.13k forks source link

Publish flow: ensure setting date to the past sets the status to draft #62151

Open annezazu opened 3 months ago

annezazu commented 3 months ago

In testing this PR for 6.6 https://github.com/WordPress/gutenberg/pull/62070 I noticed that I could set the status to scheduled but then pick a date in the past and the scheduled status wouldn't update. I think the status should be "draft" since it's not yet published but curious for @WordPress/gutenberg-design feedback.

To replicate, set status to "Scheduled" then change the Publish date to the past or now. Notice the status remains as "Scheduled" while the Schedule/Publish button changes:

https://github.com/WordPress/gutenberg/assets/26996883/bef0e7ed-66fa-4cdc-a520-8c78b33d502e

^Note this shows two bugs I'm opening to give a full view of the current flow. cc @ntsekouras

ntsekouras commented 3 months ago

In this PR I mention that there are still some nuances due to the many different possible flows.

This has some nuances similar to the problem it solves, but on the other way around. For example if a user sets the status to scheduled and not update the date, the final status will not be future. I think that's fine since the rendering of the control will be very prominent to the user to also select a date, but just mentioning.

Status and publish date are quite connected, but because they are different props we already have some side effects to update one when the other changes and we should see to refine holistically. That is because by handling a use case might cause other problems and the example for this specific case is:

  1. User opens post status panel and sets scheduled, so the time picker renders.
  2. User makes a mistake and chooses a past date
  3. Status goes to draft or whatever and the time picker is not rendered there now..

Having said that, with a temporary inconsistency created by the user, if they save, the status will be updated properly to reflect what it should be. I thought the direction is try to be a bit less 'smart' when trying to guess user intentions and not be too eager to update other props automatically.

Refining and unifying the publish flow has still lots of work and this is mostly due to the big complexity there. I'd suggest try to explore how we can do this holistically (when/how to be smart and auto update) and not try this for 6.6.

I'm happy to hear others' thoughts too for this one.

jameskoster commented 3 months ago

I think this is another great example of why Status and Publish date should be combined in a single UI for unpublished posts. That UI should not allow incompatible date + status to be applied. Status updates should feel like more definitive actions, whether it's publishing, scheduling, or unpublishing. There's a Figma here with some longer-term concepts around these flows. Feedback very welcome!

With separate controls we open the door to all kinds of shenanigans, and (as Nik already mentioned) must include additional logic to conditionally update values in the background. This is confusing to use, and adds more code, lose/lose.

Having said that, with a temporary inconsistency created by the user, if they save, the status will be updated properly to reflect what it should be

This is what happens in wp-admin 'quick edit' experience and seems acceptable to me. A user choosing to schedule a post then selecting a date in the past is probably an edge case. Though it's worth noting in this flow the status is updated from scheduled to published rather than draft.

annezazu commented 3 months ago

I think this is another great example of why Status and Publish date should be combined in a single UI for unpublished posts. That UI should not allow incompatible date + status to be applied. Status updates should feel like more definitive actions, whether it's publishing, scheduling, or unpublishing. There's a Figma here with some longer-term concepts around these flows. Feedback very welcome!

Very much agreed here.

Refining and unifying the publish flow has still lots of work and this is mostly due to the big complexity there. I'd suggest try to explore how we can do this holistically (when/how to be smart and auto update) and not try this for 6.6.

I hear you and don't want to switch things up too much either. With that said, I worry a bit about changing the flow for folks when it's the key part of using WordPress (publishing content) when these issues haven't been solved.

jameskoster commented 3 months ago

I feel this flow is in an acceptable spot for 6.6. The exact same problem has existed in wp-admin for years: you can quick-edit a scheduled post and set a publish date in the past. If you do this then the status automatically switches to published behind the scenes. It's definitely not ideal, but I have to question how often we expect users to intentionally do this?

The decision was made early in the 6.6 cycle to align publish flows around the site editor due to it's better handling of multi-entity saving. If we reverted this work to align with the post editor I fear we'll be creating a lot of headaches for ourselves down the road. It doesn't seem worth it to cater to what is arguably an edge case.