WIP: Unify publish flow between post and site editors #60289
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ntsekouras
added
[Type] Enhancement
ntsekouras
changed the title
|
Size Change: +1.34 kB (0%) Total Size: 1.72 MB
鈩癸笍 View Unchanged
|
ntsekouras
force-pushed
the
try/unify-publish-button-panel
branch
from
2ea1f87
to
b2f6576
Compare
|
Phew. Big PR! What are some of the main things to look out for? In a bit of quick testing of the site editor and post editor, the behavior felt reasonably solid. Here's a GIF showing that testing session, which involved publishing a page, editing a page after the fact, then bundling up some changes, style variations, etc.
|
@jasmussen I think that since we want to unify the publishing flow, we need to decide is what to do with the This PR makes it easier to see the differences and inconsistencies and will hopefully help us make informed decisions about the end result. So:
|
|
I'm personally leaning towards "1" (aka the site editor behavior) because it feels more simple. Everything works in a unique way (save button) except when the the post is draft (you have a publish button). The post editor behavior is a bit more involved but also more confusing (some options actually trigger a publish right away, like making things private...) |
ntsekouras
force-pushed
the
try/unify-publish-button-panel
branch
from
b2f6576
to
0b40d06
Compare
|
I would also lean towards 1, as the post editor panel has its own share of problems. I think that's also the plan @jameskoster is working off of, and ultimately I'll defer to him on this. |
ntsekouras
force-pushed
the
try/unify-publish-button-panel
branch
from
0b40d06
to
ae1568c
Compare
Yup, that's what we've been working towards. Designs for reference:
|
|
Thanks for sharing the designs @jameskoster. What would be the text of the Modal's trigger when in other post statuses (like draft, scheduled, etc..)? |
|
Minor visual details may need tweaking but this is what I've been exploring for the different status chip configurations: 
|
|
Nice designs, thank you for including the full editor context. Seeing it like that, I wonder if the same visual treatment should be used for status and visibility as we use for the color flyouts, like these:
|
|
Ideally all popovers use the same component and inherit the styles/metrics accordingly. The main difference seems to be the exclusion of the title / close button, happy to try that 馃憤 |
|
I agree with option 1 and seeing how that feels. Some quick feedback and notes as I know we're working through how best to unify. I'd say "successfully drafted" as upon creation it's not live:
After updating a page, "site updated" feels a bit extreme as it's just a page that's been updated. I think we should change that to "page updated" unless there are additional changes to the broader site:
I found myself missing both the pattern picker from the Site Editor > Add page flow (a known issue) and this post publish screen where you can copy the link:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Part of: #59878
Current state of this PR:
Publishbutton/panel/actions/slots/preferences in editor package(ex PluginPostPublishPanel). Noting that some of them were already there.Publishandsave draftbutton in site editor where they are rendered only if we have a page indraftstatus and we don't have any changes in other entities. If the above conditions are not met, the currentsavebutton is rendered. The direction should be to have a singlepublish/savebutton for both editors.The extra nuances here are:
publish/savebutton or if we should do it iteratively. Additionally I'm not sure I can I split this PR in smaller PRs - maybe moving some stuff in editor package without adding it in site editor? 馃publish/savebutton we need to unify the status change flow, because they are different right now between editors. In post editor we have less statuses available and we infer some of them based on the coupled fields(ex Scheduled status and future publish date). In site editor right now we have all the statuses available but not baked in the publish flow.