Allow extending editor preview in more ways

[simison]

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:

• Social media share previews
• Previewing same content in different formats such as website, email, RSS, printed
• Displaying with different membership or paid access restrictions/without
• Dark mode for websites that implement it while editor stays light mode by default
• Additional display sizes for more exotic targets such as televisions, watches
• eBook previews
• AMP format previews

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
• Allow extending preview dropdown menu with multi-selection items
• Allow adding multiple sections to preview dropdown menu
• Allow extending the editor canvas

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:

• completely replacing canvas with custom preview like custom built editor,
• passing alternative styles like dark/light mode, print/TV/website/email
• passing meta info to existing canvas (like free/paid) user

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?

[fabiankaegy]

Thank you for summarizing the needs here so well :) This would really go a long way!

[mtias]

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.

[gziolo]

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.

[skorasaurus]

Some additional contexts to extend the preview window:

#33578
#27837
#34655

A request to be able to remove the filter window if you wish - #23126

[bacoords]

This is great! I'm a huge fan of "Allow extending the editor canvas"- some additional use cases:

• similar to the "watch" example, we have post types that also feed their block data to mobile apps, where the blocks render a bit differently.
• swapping out the canvas for a 'fields/data mode' where you can populate custom fields (instead of having to use the sidebar or a modal to show custom fields)
• advanced developer plugins that might want to let you view a post as it's 'data model', for example, what does this post look like as it's REST API endpoint, what does it look like to my GraphQL plugin - those tools could integrate right into the editor.

[fabiankaegy]

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 :)