-
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
Allow extending editor preview in more ways #65005
Comments
Thank you for summarizing the needs here so well :) This would really go a long way! |
Another example from core itself could be the Style Book—rendering on the canvas as a target. The cases where we render a pattern or a template part in isolation also seem relevant since elements like resize handlers could be part of the API. |
Interesting use cases. It makes me wonder whether we need to replicate the same SlotFill behavior we have for the sidebar. It feels like it would make perfect sense and could become an interesting option for extenders. I'm surprised we don't change the URL or store the visit to the Style Book in the browser history. Going back in the history 7-8 years, that was most likely the primary concern for opening the canvas for extenders. |
This is great! I'm a huge fan of "Allow extending the editor canvas"- some additional use cases:
|
Something that I am coming back to every time I am using this API is that we need a better way to manage body classes (inside the iframe) for many of the preview options to be possible. Just look at this example from @ndiego about how to manually add a custom class name to the iframe: https://github.com/ndiego/dark-mode-toggle-block/blob/341188f6c46c39a1c1ce34384cabb61f43998c48/src/index.js#L91-L149 This new extensibility entry point would be so much more powerful if we had an API for managing these classes :) |
Hi, @simison is there a timeline for adding support to manipulate the canvas size? On my plugin I wanted to add support for other screen sizes, but the fact that the iframe only appears with Tablet and Mobile ( and not in desktop ) make it challenging ( I don't think is a good practice to intereact with the DOM either ) I think the way the preview menu is extended with the new component is kind of static, there should be a way to update the preview dynamically as well from anywhere, the same way we update to Tablet, Mobile & Desktop devices:
|
What problem does this address?
In #64644 we allowed extending the "preview dropdown" in a simple, fairly restrictive manner:
This is great for gathering feedback from real usage.
Extending the preview menu and canvas allow variety of publishing flows and tools, some examples:
An example of more complex preview capabilities from Substack done directly in the canvas:
Screen.Recording.2023-07-26.at.12.03.19.mov
Another simpler example from Jetpack Social, opening a modal for previewing:
What is your proposed solution?
Allow extending pre-defined device sizes list
Extending existing devices list is simplest step, as the API could be purely declarative (size, icon, label) and hook into existing functionality:
Examples might be slideshow presentations, TV screens, watches and other more exotic devices. WP is used to build not just websites.
Allow extending preview dropdown menu with multi-selection items
Selections would work in conjunction with existing device-size selectors, and work well with allowing extending editor canvas:
In above scenario you can preview post as a "free" or "paid" subscriber in various device sizes.
Some concerns come from having multiple plugins extend the menu in their own way, and how the menu should then look like. Do we force each plugin onto their own sub-menu or section? Should selections from one plugin clear selections from others? What are the defaults? How do we allow branding show up?
Allow adding multiple sections to preview dropdown menu
Expanding on above example, one could also introduce multiple devices/platforms that are separate from device sizes, such as "email" and "website":
Allow extending the editor canvas
Extending canvas could be done in multiple ways. We could allow:
Allowing replacing the canvas brings up questions like do users expect to always be able edit what they see in the canvas, or can canvas work purely for "previewing" too?
The text was updated successfully, but these errors were encountered: