-
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
Post Editor: Preview button was removed by a Site Editor change #44738
Comments
This one looks like it needs a fix before 6.1 RC. |
cc @jameskoster / @jasmussen / @richtabor for a design point of view. I can see an argument that this creates consistency across the editors and I can see an argument for having nuance in each. In the original PR that implemented this, it seems like there wasn't necessarily certainty there either #42331 (comment) For now, adding to the 6.1 board for consideration. |
Personal opinion: I like keeping it "View". The canvas itself is already a preview, and the View toggle offers query based sizes, and an option to view in a new tab. |
My personal opinion. I don't use Preview. I much prefer to Update and View Post. WIBNI if the View menu actually included the option to actually view the post. |
This is only true on well built block themes which make up a tiny slither of the current install base. The idea that the canvas is itself the preview is inaccurate on the majority of sites, as well as many of your own companies main offerings such as WooCommerce. Most custom and 3rd party blocks don't follow the WYSIWYG rule either. E.g. how would you preview an ACF interface. It's also not possible to preview the canvas at breakpoints other than the 3 predefined desktop/tablet/mobile, as well as testing that the post behaves correctly with 3rd party scripts and assets that aren't loaded in the editor. For these preview is required, and removing the wording removes the feature for most users. This will cause a large amount of support/customer/client confusion, removing the word "preview" is a regression. |
Also the site editor doesn't behave the same way that the post editor behaves, in the site editor viewing the site doesn't trigger the preview functionality, it actually views the site. That's not the case for posts. A user may make changes, click view expecting to see the unmodified site, see their changes, and think that their changes were saved and applied, only to be confused when they later visit and their changes are missing. Users who don't use the preview feature can continue to not use the preview feature, but I can see the value of the preview button changing to a view button if the current document has no changes E.g.
|
Just thought I'd leave a note that I agree that it's confusing to change it globally to "View". I like the solution suggested by @tomjn re: different state depending on the post's status. |
Please also note that there's already a link labeled "View" in the post editor, in the admin bar, which does something different than the button: It goes to the published post on the frontend. With this change, there are arguably two "View" links that do different things. I'm sympathetic to the reasons for labeling the button "View" everywhere, but I hope that what @tomjn says takes precedence. This is going to be a disruption for many users and the teams that support them. If it's going to happen, then, IMO, it deserves to happen deliberately and to get attention in a dev note and the field guide. It's too significant to happen as a side effect of a change to the site editor, which is a feature that a small number of users will ever see relative to the number of users with the ability to publish content. |
For context, this was initially done in the Site Editor (view) and ported over to the Post Editor. While I think it's good to have consistency, I can also understand where keeping preview makes sense, especially while previewing isn't possible: #28208 Since the functionality does exist in the Post Editor, it seems wise to have separation there and keep "preview" for now. In the future when there's more shared functionality, I could see having consistency between the two, especially when content is available in the site editor #44461 |
Update for folks here. Thanks to everyone who chimed in, offered feedback, and shared context around this initial implementation. Based on what's been shared, a PR was completed to add back in the "Preview" button to the post editor: #45074 I'm working to ensure it's backported for 6.1 and am going to close this issue out for now! |
Description
In #42331 the site editor was improved by changing the preview button to a view button. However this change wasn't just applied to the site editor, it was applied to all editors. I can understand why the change was made for the site editor, but it's a major regression for the post editor and other block interfaces.
This on its own will create tens of thousands of hours of support requests and problems.
It also heavily implies that you can no longer preview your changes, and that changes are applied immediately rather than on update.
Step-by-step reproduction instructions
( unless you are told that the view button can be used to preview the changes, how would you know? )
Screenshots, screen recording, code snippet
Environment info
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes
The text was updated successfully, but these errors were encountered: