-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Unify publish flow between post and site editors #60289
Conversation
Size Change: +1.34 kB (0%) Total Size: 1.72 MB
ℹ️ View Unchanged
|
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...) |
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. |
0b40d06
to
ae1568c
Compare
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..)? |
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: |
What?
Part of: #59878
Current state of this PR:
Publish
button/panel/actions/slots/preferences in editor package(ex PluginPostPublishPanel). Noting that some of them were already there.Publish
andsave draft
button in site editor where they are rendered only if we have a page indraft
status and we don't have any changes in other entities. If the above conditions are not met, the currentsave
button is rendered. The direction should be to have a singlepublish/save
button for both editors.The extra nuances here are:
publish/save
button 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/save
button 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.