-
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
Site editor: go direct to edit from manage all templates list #48764
Conversation
Just draft at the moment as this breaks the browser back button from the editor back to all templates list. I need to have a look at #48731 and work out if this will fix it, or if I am doing something wrong with the use of |
Size Change: +647 B (0%) Total Size: 1.34 MB
ℹ️ View Unchanged
|
#48731 does seem to fix the back button issue so we should probably just hold off merging this until that is merged and then I will retest this, but will also have a bit more of a look at it tomorrow to see if there is a smarter way to sort the back link to the manage all templates list without having to pass through the extra param. |
Flaky tests detected in 83e1969. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4358587853
|
… mode rather than via the view only screen
4af7926
to
d48192b
Compare
It would be nice if there was a way to get the backlink to work without the SiteHub needing to be explicitly aware that the template had been linked to from the all templates list, but I couldn't think of an alternative. |
Personally, I prefer largely the behavior in trunk. I think we're only seeing this as a problem because there's not much you can do yet from the sidebar of the site editor when a template is selected. |
The problem with the behaviour on trunk, in terms of UX:
|
I understand this but I still believe trunk is better personally. As seen in this PR, we need to store the "previous" location and change the behavior of buttons depending on that previous location, this is very fragile and make the experience inconsistent. The "W" button does two different things depending on where it's clicked. It's important to note that the "w" button is not a "back" button. Maybe that's how you picture it but I don't think that's what everyone sees. Again, when we'll have the possibility to change styles .... in the sidebar, I feel this feeling of an unnecessary step is just going to fade away IMO. |
I appreciate the desire to preserve the singular behavior of the W button in terms of the code. I don't actually see it as a back button FWIW, indeed it already has two functions:
The tricky part with the first point is what do display when zoomed out. In the Post Editor we 'zoom out' to the list view, which seems right in that context. Perhaps we leave the W button until we have a clearer picture of some broader workflows – something we'll be exploring more for Phase 3. To me, it still feels a bit unexpected to see the details interstitial via the Manage list. From the manage list I would expect to go directly to full screen editing... and if I wanted the overview I'd just click Templates > 404 rather than Templates > Manage > 404. Maybe we try:
If that doesn't feel good then we can close :) |
I'm ok with this as a compromise yeah 👍 |
Done. |
@@ -89,6 +89,8 @@ export default function Table( { templateType } ) { | |||
params={ { | |||
postId: template.id, | |||
postType: template.type, | |||
canvas: 'edit', | |||
fromTemplateList: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦 - gone now.
Let's just do go-directly-to-edit but don't change behaviour of W. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Glen, this is working well from the design perspective.
What?
If clicking on a template in the manage all templates list go direct to the editor rather than the interim view canvas for the template.
Why?
The interim view step is currently redundant as offers no additional functionality.
Fixes: #48702
How?
canvas=view
withcanvas=edit
in the link paramsfromTemplateList
param so the back link can be correctly generated in the editorTesting Instructions
Screenshots or screencast
Before:
all-templates-before.mov
After:
all-templates-after.mov