[5.x] FR: Previews in element slideouts

[mmikkel]

It'd be awesome if Preview was made available in element slideouts.

In lieu of Matrix-in-Matrix, and particularly since slideouts were introduced in Craft 3.7, I've leaned pretty hard into the "entries as nested modular content" approach.

With nested entries and element cards in Craft 5.0, this approach to content modelling is likely only going to become more popular. This means that going forward, a lot more content editing is likely going to happen in slideouts.

Slideouts are great, and everybody loves them. The one thing they're missing, and pretty much the only thing that has been reported to me from clients as a frustration with the slideout AX, is that the slideouts offer no way for authors to preview work in progress.

In Craft 3 and 4, I've generally taken the care to add custom preview targets to all my "faux-nested entries" sections. In reality this has been almost meaningless work, since authors generally interface with this content via slideouts 90% of the time (opening a slideout entry in its dedicated entry page, just to access Preview, makes for a very disjointed workflow; nobody does that).

Adding Preview to slideouts for "bona fide" entries seems pretty straight-forward. If an entry belongs to a section, and that section has URLs and/or preview targets defined, Craft knows what to preview, and adding the "Preview" button at the top of the slideout modal should probably be doable?

Then there's Craft 5, which introduces a core concept of nested entries. From a previewing perspective, these entries are going to be even worse off than my faux-nested entries, since they won't be attached to a section and thus have no way of being previewed at all, outside of closing their slideout and opening the owner element's preview (again, a pretty disjointed workflow) (and, their dedicated edit pages won't have a preview).

I guess the primary problem w/ preview for nested entries is probably "how will Craft know what to render".

Element partial templates could potentially be surfaced as previews for nested entries – i.e. if an entry using an entry type that has a partial template, Craft has something to render for that element and a "preview" rendering that partial template could potentially be exposed.

In reality, I'm not sure if that approach is viable, as element partial templates might not always be developed to render "standalone".

Possibly the better option would be to basically treat entry types (and other field layout providers) as "sections light", adding a "Preview Targets" setting to them. This would enable developers to add previews to nested entries where appropriate and/or needed, with full flexibility in terms of what gets rendered; even making it possible to have multiple different preview targets for a single nested entry (I can think of the use cases for that!). This approach isn't as streamlined as simply rendering an element partial for the preview, and the setting might seem a little bit awkward for entry types specifically created for inline-editable Matrix fields (where preview for nested entries make less sense) – but I'll stop typing now :)

[thupsi]

Agree on all counts +1

[mmikkel]

...I wanted to revive this idea, with the glimmer of hope that maybe something could happen with it for Craft 5.9 😇

I recently upgraded a massive Craft 4 site to Craft 5. As part of the upgrade, I was able to get rid of several sections by moving their entries to Matrix fields using the Cards view mode (this move made all the sense in the world, as these sections should've been nested from the start).

The client loves the new nested entry setup, except for one thing: On Craft 4, I had set up custom preview targets for the mentioned sections (whose entries had no URLs). And as it turned out, even if the client loved the content now being nested, they really missed being able to preview these entries "standalone"!

I was able to bring back the preview targets for the relevant nested entry types when they are being edited via their dedicated edit pages, with a little bit of code:

Event::on(
    Entry::class,
    Entry::EVENT_REGISTER_PREVIEW_TARGETS,
    static function (RegisterPreviewTargetsEvent $event) {
        /** @var Entry $element */
        $element = $event->sender;
        if ($element->getType()->handle !== 'tripSchedule') {
            return;
        }
        $event->previewTargets[] = [
            'label' => Craft::t('app', 'Preview'),
            'url' => UrlHelper::siteUrl("preview/trip-schedule/$element->uid"),
            'refresh' => true,
        ];
    }
);

Which is great, and helped a lot. BUT, it would be extremely awesome if

a) it was possible to define that preview target via the Craft UI; not only via a custom module and
b) it was possible to add preview targets to entry slideouts (this is the big one!)

[thupsi]

Still support all FRs that bring Matrix fields closer to full blown nested sections 🙂 (see #17967)

Another thing that still remains to be ironed-out is the relations to such nested entries (see #17966). I wonder @mmikkel , since you are using this approach in larger projects, how do you handle this?

[mmikkel]

@thupsi So far, I've actually avoided using nested entries for content that authors could feasibly want to "link to", or relate to other entries, mainly due to the caveats outlined in #17966.

The sections I converted to Matrix as per the comment above, were good candidates for nested entries partly because the original sections were never available to any Entries fields, i.e. these nested/modular entries are completely inherent to the (root) owner entries and the only reason they were sections to start with is because I didn't want to use a plugin for Matrix-in-Matrix.

Aside from the mentioned caveats, I'm also not completely sure how I feel about the concept of relating to a nested entry, but I did give #17966 an upvote though, as it'd be great if it was possible to actually do it in a more natural/less hacky way, in cases where it makes sense.

Once 5.9 drops, #17779 might shake this up as well...

[thupsi]

Yeah, lots of tangents I could go on about here 😅. Don't mind if I do:

I'm eagerly awaiting 5.9, in large part due to #17779. I've tested it localy and it's this close to matching and even improving the element grouping that existed in the pre-entrification era, so I'm pretty pleased! But...

The one area where it still feels awkward is when you have custom sources that contain only a single. Let's say I have a whatever "page" (the new term for top level content groupings) that has just a whatever custom section with just a whatever single. I would love if pressing "Whatever" in the side nav would take me directly to the whatever single. For a more detailed take on this see #17760. But yeah, basicaly this was allowed by the "Globals" UI, and I hope we get something similar (as an option) for singles.

Rumbling over now 🙂, apologies for hijacking the thread!

[thupsi]

Hi again @mmikkel! Not your main point, but why not set a url via the UI for those nested entries? Wouldn't that give you the preview on dedicated edit pages for free, without custom code? Of course you should make that url only available for previewing purposes.

[mmikkel]

Good thinking, that didn't occur to me!

I've gotta say I don't love the idea of giving nested entries URLs just to be able to preview them, though. So I'll probably continue to add preview targets programmatically, to enable previewing from dedicated edit pages.

...but, this got me thinking that the ideal solution here probably is to give Matrix fields a "Preview Targets" setting, not entry types 🤔

And yeah, the main point w/ the FR is to enable previewing from slideouts, which would benefit regular section entries as well, not just nested entries 😊

[wmdhosting]

Proof of concept, as @mmikkel suggested on Discord: we get a working "preview in the slideout" for nested entries today, but only with a hack that shows exactly where core could step in.

How it works

• Every block entry type gets a Template UI element in its field layout, pointing at a CP template.
• That template renders an <iframe> whose URL is a site route: /_cp-preview/block?id={{ element.id }}.
• The route loads the entry by ID including provisional drafts, and hands it to the same Twig dispatcher the front end uses. So the iframe shows the real block, in the real layout, with the author's unsaved edits.
• A small script adds desktop / tablet / mobile width presets and a drag handle.

Because the URL is per entry ID, the same UI element works for all 63 block types in the install with no per-type config. Authors edit a nested block in its slideout and watch it render underneath the fields. Nobody opens the dedicated edit page anymore.

Entry type settings: the Template UI element sits in a "Preview" tab of the field layout, next to the block's variant field.

Result in the editor: two nested blocks (Entry List, CTA Banner) each rendering themselves under their own tabs, with viewport presets and the variant ButtonGroup below.

Where it is fragile

The render half is boring and stable: a field-layout UI element, a site route, our own templates. The refresh half is the hack. To know when to reload the iframe, the script listens for the form's change/input events, Garnish's updateFieldValue, pokes the elementEditor instance for the draft-save callback, and sits on a hard-coded delay so it does not reload before the provisional draft is committed. All of that is undocumented surface and can go stale on a minor release.

What core would need, based on this

1. Preview targets on entry types, not just sections. The event route (EVENT_REGISTER_PREVIEW_TARGETS) already works per entry type, it just is not reachable from the UI or from slideouts.
2. A Preview affordance in the slideout that reuses the existing draft autosave. The autosave already exists; the only missing piece is a signal ("provisional draft saved") a preview frame can subscribe to. That single signal would remove every fragile line in our script.
3. For nested entries with no URL, "render via the element's partial template" is a good default preview target, as you proposed. Our dispatcher is effectively that, just outside core.

Re @thupsi's point: a URL on the nested entry type gives a preview on the dedicated edit page, but the slideout is where 90% of nested editing happens, so it does not close the gap.

Happy to share the templates if it helps scoping.

[brandonkelly]

We’ve added Live Preview support to slideouts in Craft 6! #14298