Improvements to auto-embedding of links

[winzig]

Is this a bug report or feature request? (choose one)

🆕 Feature request

💻 Version of CKEditor

11.1.1 Balloon Editor build

Feature Description

We use iFramely for embed services, and are interested in integrating this with the new embed feature of ckeditor5. Ideally what we would like to do is detect when the user has pasted a URL (which we would want to auto-link), or the user links some text manually, and in that scenario, we would want to automatically insert the iFramely iframe embed (if there is one returned by them).

We would typically insert the embed below the link if the link is on a line by itself, or below the entire paragraph, if the link is part of a paragraph of text. We would only want to insert the embed one time per unique link (if the person is linking to the same thing over and over, just the first instance would auto-embed).

The auto-embed box would need some sort of capability of removing it.

If you're familiar with Slack, this is sort of similar behavior. Someone includes a link in their message, Slack "unfurls" it with a link preview (akin to the iframely embeds), and then the user can turn off the preview (embed) if they don't want it appearing with their message. Most of the time the embed is useful, so it's rare to remove them, and I think the same thing would likely be true for auto-embed in ckeditor.

We would likely also want to specify an ignore list of domains we never want to auto-embed.

Assuming these features are not something that is already available in ckeditor5, what would be the best mechanism for me to build it? I've looked through the plugin documentation, but it's not clear to me yet where I would start, or if this functionality would even be something to put in a separate plugin, versus just listening and acting upon existing ckeditor events?

[winzig]

After working more with the new embed feature, and discovering the existing auto-embed functionality, I'm changing the title of this request and the intent, to offer some feedback on possible improvements (or options) for the auto-embed functionality. (@Reinmar, is there a better place for me to put this request?)

The current auto-embed behavior seems a bit user-unfriendly. It removes the user's original URL and replaces it with the embed, and there's no obvious way for the user to reverse this action. It would be great if this could be tweaked so that the embed frame had an "X" remove button in the upper/right corner. If removed, the link is put back, ideally with some sort of data-attribute indicating the user explicitly requested it not be turned into an embed.

Auto-embed linked text. It would be nice if the auto-embed functionality could be triggered if the user links some text (rather than just when pasting a URL). If the text is in the middle of a paragraph or list, the embed would go directly after the paragraph/list. In that scenario, you obviously would not remove the linked text when the embed is placed, but like the other scenario above, if the user removes the embed with the "X" button, the link should have a data-attribute added to indicate the user does not want it embedded.

If there's no interest in these kinds of changes, I'm interested in finding out the best way for us to tweak the embed functionality, if possible. I've been reading the documentation, but it's still not clear to me how (or whether) there are events we can observe to modify what's happening during the embed process?

[Reinmar]

Hi! First of all, I'm very sorry for a late reply. We somehow missed your ticket.

I agree that the current way how the media embed feature autoembeds links doesn't make for the best UX. In fact, the only way to revert that action is to undo it... but this option may not be available on mobile devices where due to the limited size of the screen the undo/redo buttons are often removed.

Some sort of UI for reverting that action might help. Also, we might consider not embedding things completely automatically, but e.g. displaying some notification next to a pasted link that this can become a media embed if you click "here".

That said, we're not planning to work on improvements for this feature for now. There wasn't much feedback about media embed (that would indicate some problems) and we've got other features that we'd love to bring.

If you'd like to give this a try yourself, then here are a couple of tips:

• This is the current auto media embed feature: https://github.com/ckeditor/ckeditor5-media-embed/blob/master/src/automediaembed.js. You can find some inspirations there. It listens to the Clipboard#inputTransformation event, marks two positions in the model (live positions, so they will update together with the model). One is glued to the left, the other to the right so once the content is inserted at exactly this position in the model, a range of those two positions contain the inserted text. You could also listen to Document#change, directly on the model, to get all the changes applied to the model, but that'd also cover content inserted in other ways than just pasting, so that's why this event uses the clipboard event to initiate the process.
• If you'd like to learn when someone links a text, then there are two solutions. Listen to the LinkCommand#execute or to the already mentioned Document#change event to get changes in the model (you'll be looking for the linkHref attribute being applied on a text).
• There's a small util called findOptimalInsertionPosition() that we use to find a position before/after the current block. It's used by various "insert image/embed/table" commands to avoid splitting the current block and instead find the closest position next to it.

I hope that this would help.

[Reinmar]

cc @oleq

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).