For media types which don't have nice ways to embed them (only images do now), we should at least create a link to the file using the generic file link formatter.
This one is tricky because right now our media tag looks like this:
is actually not a formatter, but a "view_mode" which means when the media is rendered in _media_markup, we call this:
$file_field = media_get_file_without_label($media_obj, $media['view_mode'], $settings);
This will say:
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.
2. You can't really sanely include alternate formatters (like this issue wants to do).
We could solve this issue by:
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.
Are there any updates for this issue? I'm looking also for a way to set a simple text (download) link to a media file.
Most of the work has already been done for this. It's just a matter of linking the media_link view mode with the file_link theme in file_entity.
Can't we do this already with Manage File Display, using generic file formatter or url link? [Edit] Oh, we can't, and I guess that's what this issue is about. Whoops.
We were talking about this issue in #drupal-media this morning, and discussed a temporary solution: https://gist.github.com/3012194
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:
$settings['wysiwyg'] = TRUE;
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! :)
In light of being able to only use images it seems the only solution to inform the user what image went with which file would be to embed the title of the file into the image like this:
Not unlike textimage.
Any thoughts on this abomination of a proposal?
@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...
The Generic file formatter currently exists in Media 7.x-2.x and even works with remote media such as YouTube videos.
I opened #1792738: Allow custom file view modes for WYSIWYG display which deals with the WYSIWYG issues and takes note of the advice in #1, #3, #10.
Closed (fixed) for development (unstable) version 7.x-2.x, but should it work in production version 7.x-1.2?
Or will there be a fix for 7.x-1.x soon?
I installed the latest drupal 7 version last three days,, same tricky problem still exist.
can anyone help please?
Drupal is a registered trademark of Dries Buytaert.