I tested this with Simplytest me and media_dev 7.x-2.x.

Given an article with the one WYSIWYG field (the body field) if I attach an image with the view mode set as 'default', then attach the same image with the view mode set as 'preview', both images will have the view mode of preview.

In other words, it seems that all files with a given file id are given whichever view mode was last applied.

When I publish the article, then, the two images look the same size.

Published article

Going back to edit the article, the original image size is preserved, but the wrong file is referenced, so the "default" image looks fuzzy.

Fuzzy large image

Adding another image with a "default" view mode changes all files to the "default" mode. Publishing the article, it looks correct now, but really, the Teaser image is shrunk.

All are default now

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

adam-delaney’s picture

I can replicate this issue and confirm the bug.

fonant’s picture

Ditto, same bug here.

AndrewTur’s picture

+1

drupalove’s picture

The patch given in issue 2194821 should fix this problem.

camhoward’s picture

I'm also experiencing the problem described in the issue summary.

I read through issue 2194821 recommended by @drupalove in #4. That issue culminates in committing the patch in #49 of that issue on July 13, 2015 and is included in Media 7.x-2.0-beta1+9-dev from Oct. 1, 2015, which is what I'm using.

I'm using "Full file entity rendering" in config/media/browser because the help info for that setting says "Full file entity rendering is the best choice for most sites. It respects the file entity's display settings specified at admin/structure/file-types."

However, every image inserted into the body field (which uses CKEditor as the WYSIWYG) displays with the same view mode after the node is saved, even when different view modes are selected at the time of inserting the images.

Is there another solution to allow different images to use different view modes in the WYSIWYG?

victoriachan’s picture

I'm having the same problem too. And this doesn't just affect view modes, but other attributes such as caption, description etc media fields too.

Maybe Media WYSIWYG is identifying the instances by fid and would update all images with the same fid in the WYSIWYG window whenever one of them is updated? Would probably need some other form of id if Media WYSIWYG were to be able to differentiate between the instances of the same file.

See also this other duplicate ticket: https://www.drupal.org/node/2544522

aimevp’s picture

Maybe important to add it's not just an image problem, as suggested by this title. It's a problem for all file types. I was experiencing the same problem for documents when I tried to use the default view mode and a custom "file download" view mode. Both got changed to file download when I saved the node.

I tried to do some digging (using media 7.x-2.0-beta1+10-dev). Haven't found a solution yet but I also ended up looking at the logic in "media/modules/media_wysiwyg/media_wysiwyg.filter.inc" around line 179 in the function "media_wysiwyg_token_to_markup" where you find:

if ($wysiwyg) {
    ...
  }
  else {
    ...
  }

What I noticed if I added a devel dpm message in each case was that when I opened up the media browser I got a message telling $wysiwyg was TRUE and I was able to select the same file with different view modes and view them in the editor correctly. When I save the node I get the message $wysiwyg was FALSE and like everyone both instances of the file get the same view mode.

I'm not completely sure but I suspect that once you hit the CKEditor "SOURCE" button or when you save the node, the media input filter takes over and the view mode gets lost in translation when it translates the markup to a token. Imho that's where we must continue to search for the bug.

As soon as I have some extra time I'll try to dig deeper but that's all I've come up with so far. Maybe it's a good starting point for a seasoned developer (unlike me).

brockfanning’s picture

Title: Only one view mode possible per image per field » Only one view mode possible per file per field
Status: Active » Needs review
Related issues: +#2544522: When embedding same file with same fid twice, you wouldn't be able to choose different view modes for each
FileSize
3.19 KB

I'm attaching my attempt at fixing this. It adds an extra section to the Media tokens called "fields_deltas", intended to distinguish between each separate embedding of a given file. This should definitely be tested thoroughly, because I wrote quickly and it does change the token markup that is produced. My intention was to not cause problems with already-embedded files, but that should be confirmed.

One particular section I'm not sure about is the removal of the clearing of Drupal.settings.tagmap, at the beginning of replacePlaceholderWithToken(). That change is necessary for this to work, and doesn't break anything for me, but there are so many different configurations possible with Media, I would not be surprised if some other wysiwyg/version/branch/etc was affected by that.

Also, there is probably room for improvement. Currently, the field overrides for all instances is contained in the token - that may not be necessary. But anyway, it's a start that seems to be working for me.

NOTE: This patch may require other patches. See #14.

brockfanning’s picture

I should add, it's not just the view mode that is affected by this - it's also all the overridden fields as well.

brockfanning’s picture

A little documentation change for clarity. For details, see #8.

aimevp’s picture

FileSize
135.47 KB
47.34 KB

Hi brockfanning,

I tried your patch but it doesn't seem to work for me. I've taken some screenshots to illustrate.

This is just after inputting 2 documents (same file/different view mode):
media input in ckeditor

This is after I hit the source button in CKEditor:
media source in ckeditor

Something I'm wondering looking at the source: you added the delta but it seems it's empty after hitting the source button. Maybe there lies a hint to what may be the problem.

brockfanning’s picture

@hatznie: Thanks for the feedback. I'll see if I can replicate that. A few questions about your setup:
1. Are you using the Ckeditor stand-alone module, or the WYSIWYG module + the Ckeditor library?
2. Do you have any other patches applied to your version of Media?
3. What version of the Ckeditor library are you using?
4. On /admin/config/media/browser do you have it set to do "Full file entity rendering" or "Legacy rendering"?

aimevp’s picture

@brockfanning:

  1. I'm using the CKEditor standalone module (7.x-1.16+15-dev) with Media (7.x-2.0-beta1+10-dev).
  2. I do have some patches applied to Media:
  3. The version of the CKEditor library is ckeditor_4.5.8_full.zip
  4. At /admin/config/media/browser I have set it to do "Full file entity rendering".

I'm also using the module media_ckeditor (7.x-2.0-alpha1+4-dev) as suggested in this comment: https://www.drupal.org/node/1898958#comment-10819788

Actually, if this gets solved, I think I might have the ideal Drupal/CKEditor/Media recipe that just works.

brockfanning’s picture

I have quite a few patches applied to both media and media_ckeditor. Here are a few relevant issues that have patches I'm using:

#2416701-30: WYSIWYG Alt and Title overrides do not override
Needed for alt/title attributes on images (requires token module)

#2710841-5: The toolbar button does not open/edit selected media in latest CKEditor
Not technically necessary, but it's hard to test this without this patch.

#2713757-2: Open media popup on widget double-click
Again not technically necessary, but makes testing easier.

#2455557-4: CKEditor Plugin - Field values
Necessary for this patch.

#2707177-2: Ckeditor not recognizing widget on re-load (files saved as text)
Necessary because the Ckeditor widget is pretty much broken without this, if you're using a recent version of the Ckeditor library.

aimevp’s picture

I have applied the patches you mentioned and it seems to be working now.

brockfanning’s picture

Thanks, I've updated my earlier comments to note that there may be other patches required. The state of media and media_ckeditor right now is such that you will need to apply a lot of patches to get them to work, especially if you use a recent version of the Ckeditor library. (I actually have yet more patches applied to these modules, but they aren't relevant to this issue.)

brockfanning’s picture

I noticed that each time I switched to source mode and back in my wysiwyg, a duplicate delta was added. This update fixes that for me.

brockfanning’s picture

Earlier in the ticket I mentioned several patches that I have installed. For completeness' sake, here is a full list for my Media (and Ckeditor) recipe: #2730285: A working Media + Ckeditor recipe

brockfanning’s picture

I noticed that each time I changed attributes of the embedded item, it would generate a new delta. This update fixes that.

brockfanning’s picture

rooby’s picture

Note that part of this patch is also the proposed solution for #2317519: Blank WYSIWYG with existing multiple Media content (see #56).

junaidpv’s picture

JS error happens if we try to edit nodes with old media tags once patch from comment#19 is applied.

Here is the new patch that makes it compatible with old media tags without field overrides. Also rerolled against latest dev as part of earlier patch got committed at #2317519: Blank WYSIWYG with existing multiple Media content.

joseph.olstad’s picture

Status: Needs review » Fixed

fixed in dev 7.x-2.x

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

marcvangend’s picture

I still got the same problem when embedding the same image (identical fid) 3 or more times. That may be an edge case, but it is what clients do when testing a site, so I'd rather not have them running into edge case bugs :-)

The cause of the problem was the line delta = Drupal.settings.mediaDeltas[fid] + 1;, which cannot guarantee that the resulting delta was not already in use.

Here is a follow-up patch that uses a more robust approach for generating a new delta.

slashrsm’s picture

Status: Closed (fixed) » Needs review

@marcvangend asked me to move this back to NR.

joseph.olstad’s picture

Status: Needs review » Fixed

Committed to 7.x-2.x dev branch , please report any regressions asap as we're hoping that rc5 was the last release candidate before 7.x-2.0 , although that's not been decided yet. There still may be one or two more release candidates. I think we're getting close to a 7.x-2.0 release.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.