Embedded documents in the WYSIWYG can be very hard to delete

I have a problem where I used Entity View Modes (https://drupal.org/project/entity_view_mode).

This allows me to create additional view modes where I can add additional view modes.

I then created 3 different view modes for documents:
1) Link only (no icons)
2) Link with Left Icon
3) Link with Right Icon

With this I am able to give users an individual choice on where their icon goes or to not have an icon.

So we really need to come up with a more flexible solution that can handle any form.

Perhaps a redesign is really necessary.

I wonder if it would be better of to just create the "token" as an html/xml tag.
For example: <media></media>.
It would be the filters job to use the php DOM functionality to convert the tag to valid html image tag.

The idea is that we could use existing dom and js functionality to find and filter everything.
It could even have a file id label to use the appropriate JS for selecting a tag based on the ID and therefore simplifying the JS and DOM code.

Example:
- Lets say there is a PDF file called Fun.pdf with a file ID of 123.
- The code inside the editor would be:
<media id="media-fid_123" class="view_mode-link_icon_left type-media" attributes="file file_link file_link-icon file_link-icon_prefix media-element file-link-icon-before" link_text="" type="application/pdf; length=50122" alt="if this were an image, than this would be the image alt">Fun.pdf</media>

The JS or DOM would be able to find #media-fid_123 in a single function call.
The classes could be created as inline CSS so that the actual wysiwyg does not have to convert anything.
The attributes can be expanded when the filter processes the code.
If there was ever a filter problem, the fallback code would be less ugly to the viewer (they would see: Fun.pdf as unclickable text).

Thoughts?

minor clarification

I was able to confirm this working in Chrome 34 and Firefox 29.

I've re-rolled the patch to line up with the latest dev version of the module.

5: media-delete-embedded-document-2028231-5.patch queued for re-testing.

Attaching a patch to solve the issue for TinyMCE 3.x
Note: the "do-not-test" patch is against 7.x-2.0-alpha1.

Cheers,
Dan

I have tested patch #11 and I have found that it resolves the root problem however there is some odd behavior.

My test case was adding several documents via media browser into an unordered list. I have added 3 documents to the unordered list and then place my cursor at the end of the 2nd list item. I hit enter to create a new list item and it appears as if I have entered a soft return. If I add text or another document and save the node the result is 2 list items being created instead of 1, the first list item being blank. Additionally, if I attempt to go back to another list item (let's say the first list item) and add some more inline text, when I place my cursor at the end of the document and hit space bar, the editor forces a line break/ new list item which is un-expected behavior. I also find that I am unable to delete additional line breaks when this happens.

I have tested this in Chrome Version 38.0.2125.122

Looking at the part of the patch added in comment 4 to prevent duplicated files.

The patch is about spans but media seems to add divs to the wysiwyg not spans (recent change?)

Also I didn't understand the approach in comment 4. The issue with duplicated files is unrelated to selection, but the patch seems to only attempt to do something if you have selected the media element.

All I have to do to get duplicate files is to add a file to ckeditor, put my cursor just after it, hit enter (which creates a new media div with the same classes as the last one) and add text.

http://dev.ckeditor.com/ticket/8868

In my case, media integration fails completely when working with lists. For my own needs I prefer to always place cursor outside the file link, one can use remove formatting
before removing link in order for it to be removed correctly. Only use this patch if you are satisfied with the usecase described

I have applied patch #15 on the latest recommended release of Media, and although it resolved the duplicate file ID issue in lists but it does introduce a new bug. Now when you double click on the embedded file link to edit the link, the URL of the file is missing in the pop-up window. I tried manually entering an URL but this value is never saved.

Related issue for media_ckeditor: https://www.drupal.org/node/2591069

Regarding the comment on #17, that is hardly an issue since links added through media can't be edited directly anyways (they are media tags in the end, not links).

The real issue is that once you embed a media document for example, you can't edit it back anymore (as mentioned in this ticket https://www.drupal.org/node/2153089).

I have tried #15 and #11 and both work.

But #15 has the disadvantage that the file name (visible for users) can not be edited, because the cursor always moves to the end of the file name.

It's also true that #11 is somewhat erratic when files are put in a list. But it's not difficult to handle this and in the end I could complete a list as I wanted.

So, for me #11 is the best option so far.

Patch #15 only works for CKEditor and not other editors like TinyMCE. Patch #11 works for both TinyMCE and CKEditor but messes up lists(ul/ol). I'm setting it to needs work because that is what it needs, the issue is still not fixed.

This was fixed in media_ckeditor using media_wysiwyg , for instructions on using it, see the recipe for media_ckeditor with media.

For those using wysiwyg and media_wysiwyg, this could be improved, you'll maybe want to catch inspiration from the changes made in 2591069 for media_ckeditor
#2591069: Multiple media links break

Recent versions of media have resolved most of peoples concerns and is compatible with entity translation, multilingual and various advanced configurations. Due to the high volume of inactive and most often irrelevant issues we are Closing this as (outdated). If for whatever reason this issue is important to you AND you still have issues after checking the media recipe documentation, then let us know and we will review your concerns.

Otherwise, see the recipe documentation for how to configure media and for troubleshooting tips OR refer to the media_dev distribution if you want to see a working media setup.

As mentioned, feel free to make some noise in this issue if you still feel it is important to you or someone else.

Thanks,

Media team