-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Provide filter/option to disable responsive view controls and revert to preview button #23126
Comments
#23404 highlights a good use case for making this feature easy to disable. It is not usable in its current form on sites which include meta boxes on their post edit screen. The incredibly popular Yoast SEO plugin's meta box collapses the editor to near zero height, leaving just a confusing strip when mobile or tablet preview are activated. |
Would also like to disable this behaviour as the breakpoints do not match my front-end, I would target it with CSS via editor CSS but there seems to be no class to target on .editor-styles-wrapper it just hard-codes a style on it. Is there a filter to change the breakpoints? |
Agreed that we need a means of disabling this feature. We might be moving toward full site editing, but there will always be sites with sidebars and other layout constraints that mean this preview isn't representative of the actual site. |
cc @tellthemachines , is there a means of disabling this functionality similarly to how image cropping can be disabled with the |
+1 For possibility to remove. Would also be nice to be able filter to change breakpoints and naming of the breakpoints. |
+1 to this feature. The preview modes break our ACF custom blocks, pulling their meta into the sidebar and creating a weird preview mode you can't seem to restore from. |
To answer the question, currently there's no way to revert to the simple preview button (although it's still used on mobile viewports instead of the dropdown). I'm guessing if the main use case for this is related to plugins that provide non-WYSIWYG customisations for the editor, ideally this should be a filter of some sort that can allow the plugins themselves to disable responsive preview? The problem with that is users may not expect it to be disabled when installing a plugin. Would it make sense at all as an editor preference? |
Personally, I'd prefer a filter that plugin and theme authors can use or not use depending on their use case, like any other filter that's available in WordPress. My use case is that I'm building fully customized publishing systems for organizations and if a feature doesn't work for their editorial team I'd like to be able to remove it for all users. Sometimes the responsive preview doesn't do a good enough job reflecting the reality of the front end, and that confuses the team. |
The preview button has recently been changed to a responsive view control (#13203). Although I can see what is trying to be accomplished with the new control, there are an infinite amount of reasons why the edit screen may not replicate the front-end, and in these cases the standalone preview button that opens a preview in a new tab (current WP behaviour) works fine.
This new control works great when what you see on the edit screen is an exact replica of the front-end, but it serves no purpose if what you see on the edit screen is not a replica of the front-end.
What comes to mind is plugins like WooCommerce (which is still using the Classic editor for products) Easy Digital Downloads and many others that are doing all kinds of stuff with meta boxes to manage data. These sorts of plugins add CPTs that are more focused on manipulating data than achieving an exact replica of the front-end. In these instances a visual representation of the front-end is a nice to have, but is not essential.
If the eventual plan is to replace the classic editor with Gutenberg then Gutenberg should cater for instances when the editor does not look like the front-end.
But adding this new control, and not making it easy to bypass it, makes it that bit harder for Gutenberg to be a full and proper replacement for the classic editor in those instances when an exact visual representation of the front-end is not the primary aim.
The text was updated successfully, but these errors were encountered: