Provide a preview display setting for use in WYSIWYG editors, improves authoring ergonomics

Tested this on an 8.3.2 drupal site using entity_embed and it makes a really useful, reliably good difference.

Working well, though maybe the module maintainer will have comments in relation to line length in a few places?

Test on 8.4: apply cleanly and is doing the job!
Many thanks

Really useful feature and the patch is still working fine. Movin this to RTBC to get some attention to it. Code looks fine so far, maybe a maintainer will get an eye on it some time.

I am not at all convinced this makes sense. The whole point is that the content author can see exactly what it'll look like on the front end.

Is this perhaps driven by the fact that the default view modes are not very useful? I agree that the teaser view mode with its links for example is rather annoying. #2246533: Add 'embed' view mode for all entity types, to allow sensible embedding out-of-the-box could mitigate that.

The real reason, I suspect, that this issue is being raised, is that the current preview only matches the front end reality in its markup, but not in the way it looks. IOW, what's missing, is the CSS to make it look decent.

If #3 looks better, I can't help but wonder how terrible it looked before. It's extremely hard to discern where the embedded entity begins and the body text's own data ends. I think adding another view mode that is to be used only inside the text editor for previewing purposes moves us in the wrong direction.

So, I propose to change the issue title to Previews of embedded entities often look indistinguishable from the surrounding text, making for a very confusing UX.

The use-case in #3 isn't about how it looks but to allow for shorter, "placeholder" entities to be added, without needing the guess the requirements of the entity being added. For example, the entity being added actually contains a geolocation map which requires js to be available to render properly.
There are plenty of scenarios where using a different view mode for embedding makes perfect sense.

Thanks a lot for chiming in, @rachel_norfolk! With constructive feedback, even better! ❤️

For example, the entity being added actually contains a geolocation map which requires js to be available to render properly

Then let's just make that JS load inside CKEditor! It's totally possible, because for example https://ckeditor.com/cke4/addon/mathjax does it too. Wouldn't that be even better?

There are plenty of scenarios where using a different view mode for embedding makes perfect sense.

Can you name some other examples? That'd be very valuable information!

IMO we're discussing two seperate problems here.
1) Allow to display another view mode in the editor.
2) Render view modes better in the editor.

I think both are valid use cases. I have to say that indeed i've used this approach to actually avoid problem 2, but on it's own this is certainly a valid request to have simple placeholders in the editor (and not overload the textarea box when you embed a large full width entity)
Might be better to split this issue in 2 parts.

This issue then (problem 1) could work further on the existing patch. (Which works good). For 2) probably more research will be needed.

I have to say that indeed i've used this approach to actually avoid problem 2

That's exactly what I was gonna write in my reply! 😃

and not overload the textarea box when you embed a large full width entity)

Ah, but shouldn't that be fixed in a different way? Should that really require more view modes? Couldn't we make this automatic, say, if the widget takes up 20% or more of the vertical viewport height, then it's automatically animated to a smaller sized placeholder?

Using a different view mode is an elegant solution in that it uses existing Drupal concepts, but it comes with a non-negligible burden on the site builder, both in terms of requiring them to understand more (how different concepts tie together) and in terms of needing to manage/track more (create and manage this configuration over time).

In #6, I linked this to #2246533: Add 'embed' view mode for all entity types, to allow sensible embedding out-of-the-box. They're definitely related. They're even somewhat similar. But they have different goals: the goal there is to provide sensible embedding (perhaps even out-of-the-box), the goal here is to improve content author ergonomics. (Based on #3 and especially based on #9.)

#2 Hunk failed on D 8.6.4

patching file config/optional/embed.button.node.yml
patching file config/schema/entity_embed.schema.yml
patching file src/EntityEmbedBuilder.php
Hunk #2 succeeded at 72 with fuzz 2 (offset 13 lines).
patching file src/Plugin/EmbedType/Entity.php
Hunk #1 succeeded at 102 with fuzz 2 (offset 1 line).
Hunk #2 FAILED at 140.
Hunk #3 succeeded at 309 with fuzz 1 (offset 16 lines).
1 out of 3 hunks FAILED -- saving rejects to file src/Plugin/EmbedType/Entity.php.rej

I agree that this would be useful in certain use cases. If what is being embedded is a complex javascript based search widget with ajax, you might want to skip rendering it in the wysiwyg. I've seen instances where certain embeds causing problems with the ckeditor.

You can usually fix this bu having a separate admin theme to which you can add your own templates. But this could be useful, especially if done right.

Rerolling. We use this -- interactive embeds in the wysiwyg are generally troublesome and can do showstopping things like mess with scrolling or capturing clicks to prevent editing the embed. This is one of those cases where a little debt in terms of configuration helps out the content editors quite a bit.

Thanks, @ahebrank! Your comment confirms what I articulated in #11 and what @oknate explained much more clearly than me in #13: having a "embed preview"-specific view mode allows complex interactive embeds to have a different (non-interactive) representation.

That being said … the patch appears to be introducing a new type of plugin. That's a whole new realm of complexity.

I wonder if it wouldn't be better to improve the CKEditor plugin so that interactions with the embedded entity are impossible? In other words: what if click and scroll events (and more) would be ignored (or rather, couldn't reach the underlying content).

Wouldn't that also solve it? That'd introduce far less complexity.

I'm about to start working on improving the CKEditor integration, so if this sounds like it could also solve your problem, it'd be great to have you testing what I'll be doing :)

It might be that, sometimes, interactions are desirable.

We might be beginning to try too hard to guess the environment in which the embedding takes place - as a content editor for the website owner, probably on the admin theme. I know every place I’ve used this functionality so far, it’s actually being used by end users, in the main theme.

Being able to optionally choose an alternative view mode for the ckeditor means that the site builder can consider the environment and build accordingly. It really does “just work”.

I’m struggling to understand why the approach in #2 isn’t an obvious choice. It is known to be working really well in live sites.

interactions are desirable.

Interactions with embeds inside of a text editor?!

I’m struggling to understand why the approach in #2 isn’t an obvious choice. It is known to be working really well in live sites.

Because this module is already pretty brittle and very hard to maintain. This would make that worse.

On top of that, I'm working on bringing a subset of this module to Drupal core. So I'm also looking at this from a "what would work in Drupal core?" point of view.

That's why I'm saying in #15 that preventing interactions with the embedded content solves the authoring experience problem without the need for additional configuration and complexity. Since you referred to an older comment, I went back and read those too: you talked in #7 about making the embedded content in the text editor "shorter" and mention the need for JS for certain embedded content. I responded along the same lines: let's make the preview load the JS, so that the preview actually matches what you'll see. This is exactly what the CKEditor Widget system was developed for: https://ckeditor.com/blog/CKEditor-4.3-Beta-Released/.

Because words cannot express experiences as well as experiencing it yourself: please go to https://ckeditor.com/ckeditor-4/demo/ and copy/paste a YouTube URL in there. It renders exactly like it would on the final page, but you can't interact with the YouTube player. Exactly what I'm proposing, and what tens of thousands of sites using CKEditor's own oEmbed support have been using (and validating the UX for) for years. 😀

I hope that makes more sense now :)

let's make the preview load the JS, so that the preview actually matches what you'll see.

That would be great e.g. for Blazy integration: #3054032: Blazy breaks in ckeditor

We could add a hook_theme_suggestions_HOOK() implementation to allow the theme to provide an embed-while-in-editor-specific representation of a particular view mode. Thoughts?

Yes, that would be nice. Pluses:

1. Low effort to implement.
2. Doesn't do anything unless template added to theme.

Sounds good to me. Some text on admin/config/content/embed/button/manage/BUTTON to that effect would be helpful as a memory aid (e.g., tacking on to the allowed display plugins help text: "If none are selected, all are allowed. Note that these are the plugins which are allowed for this entity type, all of these might not be available for the selected entity. An additional preview theme suggestion is provided for the selected view mode to manage the entity's display while editing in the WYSIWYG editor.")

+1 for #19. That's what after some discussion we came up in our team too.

EDIT: The discussion went on, see below.

#20 & #22: noted!

#21: that should not be necessary: the UI you mention is for site builders, yet what we're talking about is for themers (front-end developers). If they enable Twig's debug mode, they'll see the template suggestions in the HTML output anyway 😊

Point taken. The original patch was for sitebuilders, though, so it might be nice to let them know what to tell the themer.

> That would be great e.g. for Blazy integration: #3054032: Entity embed entities not visible in CKEditor

I missed that blazy 2.x already supplies an input filter which works nicely with entity embed.

> I missed that blazy 2.x already supplies an input filter which works nicely with entity embed.

No. It doesn't work
When view mode for media has Blazy enabled - in WYSIWYG image never shown.

> No. It doesn't work

@podarok you're right! I only updated my comment in the other issue. The supplied blazy filter only works for simple images (not media entities), but not for embedded entities.

The patch #28 is working for me.

+1 for @Wim Leers' #8:

> Then let's just make that JS load inside CKEditor!

So created #3084312: Make (embedded entities') JS work inside CKEditor and working on it.

#30:
@Wim Leers informed me that #8 was outdated by discussion in #2844822: The preview in CKEditor does not use the same Twig template as the one on the front end (default theme).

To not waste further energy i created #3085273: [Meta] Preview embedded media / entities in ckeditor to settle on a strategy for core/media AND entity_embed.
Postponing on that for now.

Another use-case where this would be useful: we're using Entity Embed + the DFP module to embed ad slots in our content. But those ad slots are set up to be invisible if no ads are delivered. The end result is that if a slot isn't currently delivering ads, then the content editor can't actually see that they've embedded the slot in the WYSIWYG.

Instead we'd rather deliver some sort of placeholder in the WYSIWYG context to make it clear that there's an ad slot there.

Updated this patch to work with 1.1.0.

Just as another data-point for this discussion, we inherited a site that uses entity embed to embed entire nodes in other nodes, where it used as a paragraphs-like system. I would not have built this like this myself, but it is what we haveto deal with right now.

The version of the module in the site was fairly outdated, so we updated to 1.1, which now renders the embedded nodes close to how they show on the frontend, but to our customer this is mostly a regression; they do not see the node title anymore, so they can not easily identify which content was embedded, and the lazy-loading mechanism that loads images in the frontend doesn't work either, so they can not see images that are in the embedded nodes.