Editor: render publish date control when the status is future(scheduled)
#62070
Conversation
ntsekouras
added
[Type] Bug
ntsekouras
requested review from
Mamaduka,
youknowriad,
jameskoster,
jasmussen and
annezazu
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +197 B (+0.01%) Total Size: 1.74 MB
ℹ️ View Unchanged
|
I agree it's okay. Ideally in this case the status would revert to whatever it is currently set to on close. Would that be possible?
The date picker definitely needs some design love, but that's one to handle separately. For this PR the only changes I'd suggest:
On a similar note to that last point, would it be possible to disable all dates before |
ntsekouras
force-pushed
the
show/publish-date-control-when-future-status
branch
from
8106e7c
to
afa798b
Compare
|
I addressed these:
by making private components. Due to the nested components it's a bit more complicated to make specific changes like don't allow the previous dates, etc.. and I'd prefer if we look into them separately.
That would add some complexity too by needing some new side effects and I feel it would probably be better to explore separately. Are the above two a block for this one? |
|
Not blockers 👍 Generally I think this is in a decent spot given the constraints. My only remaining question is whether we could use
|
|
That's a good question. I'd personally be okay with omitting the fuller datepicker; can it be expand/collapsed easily? I'd love @annezazu's instincts here too. The main beat here is that the calendar allows you to more easily pick something later in the month, knowing weekends, etc, vs. typing in the number manually. |
Nik will know better but I don't think so. The full date picker with calendar is always available from the dedicated 'Publish' row though: 
|
Not very easily and I feel like we should dedicate time to that component separately to be more flexible. In this PR just for hiding the |
|
@ntsekouras is using |
@jameskoster you mean also hide it? |
|
Noting that I ran into a strange flow shown at the beginning of this where after selecting the schedule option, it's almost as if it kicked me over into the "Publish" module where I couldn't go back and change the status. I had a hard time replicating as you'll see in the rest of the video. Other quick notes are around the month only being bolded and not the year. Not sure if that's part of the component but it stood out to me. testing.publish.schedule.movIn terms of rendering the entire calendar view, I think we should for consistency. It's important to know the day of the week a post is scheduled, especially for large news rooms that have a cadence of themed posts per day of the week. |
There was a problem hiding this comment.
The changes look good and test well for me.
I wasn't able to reproduce @annezazu's issue, but my device has scroll bars enabled by default.
Unrelated note: I've noticed that a post might get accidentally Published/Scheduled if you're playing with the settings and the autosave functionality kicks in. I'm not sure if this is a new or old issue, but I would expect not to publish my posts accidentally.
Steps to reproduce
- Open a draft post.
- Change status to Published or Scheduled.
- Trigger an autosave -
window.wp.data.dispatch( 'core/editor' ).autosave(). - Reload the page, and notice you'll get unsaved changes warning.
- Notice that the post isn't a draft anymore.
|
I'd support Anne's instincts here. This is a sensitive part of the flow, we wouldn't want people accidentally publishing when they meant to schedule. I'm here for this particular flow, it seems to capture the best of both worlds. Question, however: in case we find out in the beta period that this is, after all, disruptive to some of our users, would it be possible in the beta period to change the behavior to the plan B outlined in #61488? |
Same here..
Is plan B: and the image below from the issue? If yes, probably, but it's quite different in terms of UI and when changing the publishing flow, it requires much testing. Personally it would feel to me though that we back tracking to the old flow though.. |
|
Plan B is this, and I hope we don't need to go there, I'm just a cautious person because this is a hugely prominent flow: We remove "Scheduled" from the Status chip, and rename "Publish" to "Public". So to schedule a post, you'd have to set these properties:
For a draft, you'd have:
For an already published post, you'd have:
This flow is similar to what exists in 6.5, but comes with the structural benefits of unifying in a status panel. |
|
I agree the size of the date picker feels wrong. I have to scroll the dropdown to actually make sense of it. |
|
I agree as well that it should be possible to switch to |
packages/block-editor/src/components/publish-date-time-picker/index.js
Outdated
Show resolved
Hide resolved
ntsekouras
force-pushed
the
show/publish-date-control-when-future-status
branch
from
afa798b
to
fa1af9d
Compare
|
I've updated to only use |
|
I'm going to try to track down some feedback from enterprise-y/news folks for now to get some initial thoughts too. Scheduling content, from what I've seen, is a common action there to help with everything from weekend coverage (scheduling posts to ensure content goes live over the weekend) to going live with a big piece that needs more coordination. |
…uled) (WordPress#62070) Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org> Co-authored-by: Mamaduka <mamaduka@git.wordpress.org> Co-authored-by: jameskoster <jameskoster@git.wordpress.org> Co-authored-by: youknowriad <youknowriad@git.wordpress.org> Co-authored-by: jasmussen <joen@git.wordpress.org> Co-authored-by: annezazu <annezazu@git.wordpress.org>
…uled) (WordPress#62070) Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org> Co-authored-by: Mamaduka <mamaduka@git.wordpress.org> Co-authored-by: jameskoster <jameskoster@git.wordpress.org> Co-authored-by: youknowriad <youknowriad@git.wordpress.org> Co-authored-by: jasmussen <joen@git.wordpress.org> Co-authored-by: annezazu <annezazu@git.wordpress.org>
What?
Related: #61488 (comment)
There are some suggestion on how to improve the scheduling flow in the editor with the new reused
PostStatuscomponent.This PR for now simply does:
scheduledstatus from the available statusesNotes
scheduledand not update the date, the final status will not befuture. 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.Testing Instructions
scheduledand the publish date and see how it feels and share feedback