Get the media type.
Find out what the formatter is for the view_mode we pass in and format the file accordingly. So for images, media_large defaults to styles_file_style_large (which is another abstraction of doom).

The Pros of this approach are:

1. You can change the formatter for the media_large view_type on images and then all images which have been been embedded on your site will change to that format.

2. It limits the formatters to show to a set the user can limit. So if the user sets the "small" view_mode to "hidden" it doesn't show up on the formatter form. If we showed all available file formatters, it would look like crap.

The Cons are:

1. If you don't want the 1st Pro (change the setting and all files using it change), it's not ideal.

A). Keeping the functionality the same, but adding an additional view_mode (link) and adding the link formatter to it. This is simple, and requires very little code (if any). The view_mode screen could get out of hand of course if we keep adding them.

B). Do A, but also change the functionality to embed by the formatter and not the view_mode. So we wouldn't have the change once, change all issue. But that's kinda secondary.

C). Keep what we have in terms of view modes, but allow the media tag to have view_mode:custom, formatter: custom_link_formatter. This would then format it using formatter while disregarding the view_mode. This pretty much means supporting both approaches. If we do this, we'd have to hardcode somewhere a list of appropriate formatters outside of the normal view_modes.

I quickly prototyped option A). It worked *pretty* well. The problem is that the WYSIWYG code operates on an img as a placeholder for the media tag. This is actually a bit tough to get around because of ckeditor.

Basically, the problem is the we render [[media:....]] as something in ckeditor and then upon save, we have to translate it back. An img tag works well because it is self-contained. The moment you start adding stuff around it, then the user can go in and modify the contents of that tag, add tags inside of it, etc. When that happens, we can't sanely convert it back to a [[media::] tag. We can guess via jQuery, etc but of course we'll lose the user's changes then :( This makes the link option a lot less attractive.

right now because of the shortsighted wysiwyg handling, you just see an icon for the file link in the editor (because our replacement code only works with the img) and then when you save and view it on the page, you see the proper link.

This is really a usability problem because we can prompt the user for the link text, etc but then we can't really let them change it in the editor....

Subscribe. Using the rendered link text as the eventual output seems totally reasonable and the icon as a reasonable wysiwyg placeholder given the restrictions. WYSIWYG sure would benefit from a "immutable" tag :)

So is there anyway to actually inset files using the wysiwyg? I was able to upply a patch (http://drupal.org/node/1016376#comment-5400668) to enable the user to insert a file. The problem is the display is not correct but I suspect this can be configured through the Media file display settings. However, it is not straight forward. In any case, it would be much appreciated if anyone has any thoughts on the matter.

Basically, WYSIWYG editors require an image placeholder for any insert; for images and video, this works transparently, since they can provide a realistically sized image or thumbnail, but we don't currently have a fallback for things that do not render as images.

However, when we call media_get_file_without_label(), we do pass a $settings['wysiwyg'] = TRUE; flag, so media formatters can potentially pick this up and provide an appropriate placeholder. The proper solution would be to:

Add a fallback in media_token_to_markup() to turn the render array into a generic placeholder image if it isn't an image already

Update our media formatters (basically just the link formatter) so that they provide an image placeholder when the wysiwyg flag is passed

The fact that we can't insert non-image media styles using WYSIWYG is a bug, and here is a plan for fixing it. Needs work! :)

@Jackinloadup hmm, interesting idea! Maybe we could put the file type icon before the text, too. We can't really assume that the text in an image will match the size or face of surrounding text, but it's something to experiment with. Ultimately, whoever starts the patch will set the priorities...