Matrix: a page preview view, where clicking a block opens it in a slideout

[wmdhosting]

The idea

Matrix fields already let authors choose how nested entries are shown (Cards, Card grid, Blocks, Index). For page builders, the view authors actually think in is the page itself. We'd like a Preview switch on the field, next to the existing view:

• Blocks | Preview above the field. Preview shows the owner's rendered page (its preview target) in place of the list.
• Hovering a block outlines it and shows its entry type name.
• Clicking a block opens it in the element editor slideout, as clicking a card does today.
• Move up / Move down on the hovered block, doing what the block's own reorder button does.
• The preview reloads after a slideout save, a reorder, an add or a delete.

The same markers would make blocks clickable inside Live Preview, which is what #2811 asked for in 2018. Craft 6 now has every piece (Live Preview, element editor slideouts in the preview pane, reorder buttons), only the glue is missing.

Templates would opt in by marking blocks, e.g. a Twig helper that prints attributes only during a CP preview:

{% for block in entry.pageBuilder.all() %}
  <section {{ previewAttrs(block) }}>…</section>
{% endfor %}

Why

Pages built from many large blocks are hard to read as cards or collapsed blocks, and dragging a tall block past others is awkward. Authors want to see the page, point at the part they want to change, and edit it there. Front-end editing tools do this for the public site; this would bring it into the CP, with Craft's own editor, drafts and permissions.

What we built to try it

A field layout UI element above the Matrix field renders the page in an iframe (blocks wrapped in data-* markers), and a script in the previewed page:

• dispatches craft:edit-element on the parent window to open the slideout,
• moves a block by dispatching craft-reorder on the block's craft-reorder-button in the editor (found by li[data-id] in Cards view, by data-key inside the list's shadow root in Blocks view),
• listens for craft:element-saved to reload, and asks Live Preview to refresh with craft:refresh-previews.

It works, but it leans on internals that can change in any release.

Screenshots

1. The page builder in Blocks view, with the closed Page preview bar above it.
2. Preview open: the hovered block shows its entry type and ↑ ↓ (↓ is off on the last block).
3. Clicking a block opens it in the element editor slideout over the page.

Smaller hooks that would let plugins build this cleanly

If a native view isn't planned, these would make it a supported plugin feature:

1. A documented way to open an element editor slideout from a preview iframe (craft:edit-element as a public event, or a @craftcms/cp function).
2. A public way to move a nested entry up or down (craft:move-nested-element, or moveNestedElement(id, direction)), and events for nested reorder, add and delete.
3. An event for Matrix block action menus and header buttons. Matrix::blockActions() is private, so adding "Open in a slideout" needs a Matrix subclass bound in the container, and Craft then writes the subclass into project config when the field is saved.
4. Default preview targets for nested entries (the owner's page, ideally scrolled to the block). Today Entry::previewTargets() returns none for nested entries, so Preview isn't offered on a block's own edit page or in its slideout.
5. A trusted option on the Template field layout element, which sanitizes its output and makes it inert. That's why we keep our own UI element for in-form previews.

[wmdhosting]

Update after #14298 was answered today with slideout Live Preview (#19964):

• Hook 1 is covered: Craft.openSlideout(url, {onSaved}) and the craft:edit-element event are now documented in docs/slideouts.md. We'll use those.
• Hook 4 matters more now. A slideout offers Preview only when its element has preview targets, and a nested entry with no URL has none. So page-builder blocks still get no Preview in their slideout, which was the original case in [5.x] FR: Previews in element slideouts #14298. We add targets with an ElementPreviewTargetsResolving listener: the block on its own, and the owner's page. A built-in default of the owner's page would cover most sites.
• Hooks 2, 3 and 5 are unchanged on 6.x: there's no public way to move a nested entry, Matrix::blockActions() is still private, and the Template UI element still sanitizes its output and makes it inert.