Currently when i drag an atom it can be dropped to any textfield. After the drop the atom's sas code is in the field.

I seem to remember that back then when the textfield did not have scald enabled the atom just went back to the library, but now i cant find any evidence of that.

Im not sure if this is a new feature request, or a bug somewhere.

Comments

jcisio’s picture

jcisio commented

It has been always the case. When the atom is dropped into a richtext, it is rendered with the full HTML markup. When it is dropped into a plain text target, it is rendered in the SAS format.

nagy.balint’s picture

nagy.balint commented

Was considering creating a list of scald enabled targets, and then the js could check at dragend whether the target should be dropped to or not.

jcisio’s picture

jcisio commented

I think we should not limit it. We can drag and drop an atom into any textarea (even not CKEditor) and still have the rendered atom. You don't have to care about enabled plugins, which editor is using for that textarea etc. Funny fact: you can drag and drop an atom into a richtext editor in another browser tab, or even into a different browser.

nagy.balint’s picture

nagy.balint commented

I understand that. But it does not solve the issue when the user drops an atom to a place where they should not be able to (taxonomy autocomplete text field, resumé textarea, title, autopath whatever). It is basically a UX problem.

jcisio’s picture

jcisio commented

You are 3 vs 2 saying that there is a UX problem ;-)

Would it be a black list rather than a white list? I think if a user is allowed to insert images into a text format field, he/she is allowed to drop an atom into that. Therefore, a blacklist will start with: title, autocomplete.

nagy.balint’s picture

nagy.balint commented

Yes, for simple textfields it should not be possible to drag and drop, as it will never be possible to display that there.

Good question about textarea-s. Maybe drag and drop could be enabled for all textarea-s. But then we have the summary field, where we can also never enable scald later to display the dropped in atom. So that should somehow be blacklisted as well.

An other solution would be to somehow have an extra hidden element next to each scald enabled field, so then the javascript could check if the target has this element there and then it allows the drop or not. It might not work when dropping to another browser though then, but then we could not drop into textareas that are not scald enabled and would just show a [] sas code instead of the image.

jcisio’s picture

jcisio commented
Issue summary: View changes
Issue tags: +UX improvement
jcisio’s picture

jcisio commented

With #2073413: Alternatives of drag and drop to insert atoms: double click and/or Insert button getting in, it is now easier to do this.

jstoller’s picture

jstoller
he/him
commented

I'm starting to review media solutions for a large project and am interested in Scald, but this seems like a big issue to me. I need to strictly control what media goes in what field. In most cases I'll probably want to restrict media to special media fields, rather than placing it directly in the text. In the cases where I might open that up to placing media in a rich-text editor, I'll want to strictly control which media can go into which fields. For instance, on one node I may have a teaser field and a body field. Both of these will be long text fields, but they will use different text formatters with different WYSIWYG configurations. I would want to allow some media in my body field, but no media in my teaser field. IMHO, the default should be to disallow drag-and-drop media in any field that isn't specifically configured to accept it. Attaching media configurations to text formats may be a good way to handle this and there is precedence for that with WYSIWYG profiles.

jcisio’s picture

jcisio commented

If you want strict control, then go with a field hook to filter the data.

We can pretend to do it, but there is nothing in the UI that can prevent a user to drag and drop anything (even a local file) in a rich-text area. So this issue is about UX rather than strict control.