Steps to reproduce:

  • Using media, media_wysiwyg, media_wysiwyg_view_modes, media_ckeditor
  • Set up at least one file entity type with several view modes, one of them being 'Full Content' (value => 'full')
  • Check the 'Restrict in WYSIWYG' setting for the Full Content view mode.
  • Do NOT have the undocumented media_wysiwyg_wysiwyg_default_view_mode variable set to anything.
  • Click the 'Insert Media' button in the media browser, and choose a media item of the type being tested.
  • Click submit to get to the "Embedding [Media filename]" dialog which lets you choose the view mode that the media item is to be displayed as, and to provide values for any overridable fields.

Expected Results:

  • The media item is previewed in one of the view modes that are NOT set to 'restricted in WYSIWYG'.
  • The 'display as' list of available view modes only includes those which are unrestricted. Full content is not one of these.
  • The initially-selected view mode matches the one used to generate the initial preview.

Actual Results:

  • The media item is previewed in the 'Full Content' view mode
  • The 'display as' list does contain only the unrestricted options.
  • The 'display as' list has the first unrestricted option selected, but this is NOT the full content option, and is not the mode that was used to generate the preview

Possible consequences:

  • If the user makes no changes to field in the dialog, the selected view mode will give a very different result from the one they were expecting. This is going to confuse them, especially when there is no possible way to get back to that display.
  • If there is only one unrestricted view mode, then that is already selected (even though it's not shown), and so there's no way for the user to change to that selection and see the proper preview.
  • If the user makes changes to the view mode selection, there is no way that the initial Full Content preview will be shown again. Also confusing.
  • If the full content preview is too wide to fit in the media browser dialog (e.g. large images, full-width embedded PDF documents...) then the actual editable fields for the media item scroll out of view, which makes it difficult for them to pick something more useful.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

LittleRedHen created an issue. See original summary.

LittleRedHen’s picture

Here's a patch for a suggested solution: if there is no view mode selected yet (which is the case on initial selection of the media item), then use the default from the variable or full content only if that is in the list of unrestricted view modes (previously this was always used). If it is NOT in the list, then use the first entry from the list of unrestricted modes for that file type instead.

This ensures that a valid view mode is always used for the initial preview, and thus that the selected mode always matches the previewed one.

LittleRedHen’s picture

Title: Media browser selects full view mode even when it's restricted in WYSIWYG » Media browser previews full view mode even when it's restricted in WYSIWYG

Status: Needs review » Needs work

The last submitted patch, 2: browser-preview-only-unrestricted-view-modes_2833581-2.patch, failed testing.

LittleRedHen’s picture

That patch from #2 was a bit messy and missed the case where an existing media element was configured with a view mode that had subsequently been restricted: it was still rendering the initial preview using the restricted view mode.

Looking into the code a bit, I noticed there is a lot of duplication in the way that media_wysiwyg_format_form builds its form content: That function initializes the form with all possible view modes, fetches and caches all view-mode previews, and initializes the preview field with the rendered 'preview' view mode. It then calls media_wysiwyg_format_form_view_mode, which pretty much does all that again, only with the restricted view modes filtered out, only when it renders view modes for the second time, it allows for the special 'wysiwyg' setting (and when that's present, it re-renders the wysiwyg view mode as many times as there are permitted view modes. That's quite a bit of duplicated rendering!

I've therefore taken the liberty of refactoring the media_wysiwyg_format_form function to eliminate the duplication. In this newly patched version, only wysiwyg-appropriate view modes get rendered, and only wysiwyg-appropriate view modes can be selected. The preview field is always populated with the cached, rendered view mode which matches the selection.

In making this change, I noticed that the media_wysiwyg_get_wysiwyg_allowed_view_modes function which media_wysiwyg_format_form_view_mode is calling was almost identical to media_wysiwyg_get_file_type_view_mode_options, except that it filtered the options it identified. It was also marked deprecated, even though still in use. I have therefore merged the two functions to a single one called media_wysiwyg_get_file_type_view_mode, which takes an argument to specify whether the options should be filtered. The callers of that function have been altered to use the new signature.

This patch is working nicely on my test system so far (with media_ckeditor), but will need to be tested with other editor modules in case something was relying on one of the refactored-out functions.

LittleRedHen’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 5: browser-preview-only-unrestricted-view-modes_2833581-5.patch, failed testing.

LittleRedHen’s picture

Resubmit with the test tweaked so that the wysiwyg restriction is actually cleared before testing that the matching option is available in the form. Tests passing on my own system: fingers crossed for the testbot as well.

Status: Needs review » Needs work

The last submitted patch, 8: browser-preview-only-unrestricted-view-modes_2833581-8.patch, failed testing.

The last submitted patch, 8: browser-preview-only-unrestricted-view-modes_2833581-8.patch, failed testing.

joseph.olstad’s picture

Hmm, I kicked it a second time but didn't help.

brockfanning’s picture

Off-topic but... @LittleRedHen you don't happen to use the WYSIWYG module do you? From your digging into this issue, I was wondering if you might have any insights into #2153089: Cannot edit embedded files that don't render as images in the WYSIWYG.

More on-topic: I like the direction of the refactoring here - unfortunately I haven't had the occasion to test this though, because my site doesn't have a "full" view mode for files. I'm hoping this gets done though, because at a brief glance it seems like it removes some unnecessary code.

brockfanning’s picture

@LittleRedHen, disregard that question, I think I've got a handle on #2153089: Cannot edit embedded files that don't render as images in the WYSIWYG.

letrotteur’s picture

After applying this patch to media-7.x-2.0-rc3 this error pops up in the media browser window after uploading or selection a media to display:

Parse error: syntax error, unexpected '[' in /home/drupalpro/websites/testarchive.designmontreal.com/sites/designmontreal.com/modules/contrib/media/modules/media_wysiwyg/includes/media_wysiwyg.pages.inc on line 45 Call Stack: 0.0001 644832 1. {main}() /home/drupalpro/websites/testarchive.designmontreal.com/index.php:0 0.2333 27238296 2. menu_execute_active_handler() /home/drupalpro/websites/testarchive.designmontreal.com/index.php:21

G42’s picture

This issue seems to be resolved in the latest 2.0. Setting the WYSIWYG default view mode for a specific file type such as at: admin/structure/file-types/manage/image
will make all media images in the WYSIWYG editor display with the selected mode. So all images will use Preview, Teaser, Default, etc. When you view the content the view mode you selected in the Media Popup will properly display.

However there is one issue I am encountering. If you use a default WYSIWYG view mode that is smaller than a view mode you select in the media popup widget, then the display mode you selected will not be used when viewing content and it will use the selected default WYSIWYG view mode (set in the admin path above).

I have tried many configuration settings, if I am missing something please let me know. Confirmed this behavior on a clean install with only media module and WYSIWYG with ckeditor being used.

Michael-IDA’s picture

> Do NOT have the undocumented media_wysiwyg_wysiwyg_default_view_mode variable set to anything.

Uh, yeah, running into this patching media_wysiwyg.pages.inc code as well.

As far as I can figure this should be an option that's set on

Media browser settings /admin/config/media/browser

Yes???

It can certainly inherit WYSIWYG view mode admin/structure/file-types/manage/image upon module install, but they are radically different things:

WYSIWYG view mode: View mode to be used when displaying files inside of the WYSIWYG editor.

media_wysiwyg_wysiwyg_default_view_mode: What the image is going to actually be displayed as on the rendered node.

As a side issue, why are both picking up display types /admin/structure/file-types/manage/image/display and neither are using Image styles /admin/config/media/image-styles?

kevinquillen’s picture

I can't figure this out either. A recent upgrade on the 2.x branch broke this in the edit window, and I cannot figure out how to get it to show a small thumbnail. It keeps showing the original size, blowing up the modal. None of the settings have any effect.

Even though the HTML wrappers on the media item say 'preview' and 'thumbnail' - neither view mode settings are respected.

joseph.olstad’s picture

For diagnostic purpose, try this using the latest media_dev distribution by clicking on the screens i recently added to the media project page or Also on the media_dev page.

See if you can reproduce the situation , otherwise refer to the default configuration provided by media_dev

Following here, maybe we can fix the redhen patch to pass testing.

Does the patch help?

joseph.olstad’s picture

As a workaround have a look at the media_dev distribution (recently updated) simplytest.me
See link on project page

kevinquillen’s picture

I don't know what the media_dev distro is. All I see is no way to affect the thumbnail in the media browser box like before.

brockfanning’s picture

Just a tidbit about the way it works for me: There's some AJAX happening whenever the user switches the view mode, and the preview changes based on what the new view mode. For example, if there were 4 allowed view modes: default, small, medium, large, then the preview will display in the modal as whatever the "default" view mode is configured as. Then if the user switches to "small", the preview changes to whatever display the "small" view mode is configured as.

I also happen to be controlling the starting view mode with a form alter. In case it's useful to anyone, this is the basic idea:

/**
 * Implements hook_form_FORM_ID_alter().
 */
function MYMODULE_form_media_wysiwyg_format_form_alter(&$form, &$form_state, $form_id) {
  $format_to_use_as_default = 'my_view_mode';
  // Any other logic to control the starting view mode...?
  $form['options']['format']['#default_value'] = $format_to_use_as_default;
}
joseph.olstad’s picture

@kevinquillen the media_dev distro is a fully functionning Media module configuration / Drupal stack , you can easily try it out simply by clicking on this link:
https://simplytest.me/project/media_dev/7.x-2.0-beta5

Follow the onscreen prompts you'll have media_dev up in running in a few mouse clicks.

From there you can run tests to see if you can reproduce the issue , or copy the working configuration options to your environment so that your environment will work.

add a node, use the wysiwyg editor, select from the media_dev library images , insert it into wysiwyg, see media project page screenshots
media dev demo image, click here to try it

kevinquillen’s picture

No, not the display. I mean in the media browser itself when previewing the image.

joseph.olstad’s picture

screenshot?

can you try repeating this on simplytest.me ?
http://simplytest.me/project/media_dev/7.x-2.0-beta5

joseph.olstad’s picture

Status: Needs work » Postponed (maintainer needs more info)
jghyde’s picture

If anyone is stumbling on this, here is what I found (no patches required).

The media browser view selects the file->image from the WYSIWYG view mode for image files. Set the size of thumbnail you want on this admin config page:

admin/structure/file-types/manage/image/file-display/wysiwyg

Chris Matthews’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

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