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.
Going back to edit the article, the original image size is preserved, but the wrong file is referenced, so the "default" image looks fuzzy.
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.
Comment | File | Size | Author |
---|---|---|---|
#26 | only_one_view_mode-2308451-26.patch | 2.64 KB | marcvangend |
| |||
#22 | only_one_view_mode-2308451-22.patch | 3.47 KB | junaidpv |
| |||
#19 | only_one_view_mode-2308451-19.patch | 3.76 KB | brockfanning |
media_view_mode3.png | 156.48 KB | mariacha1 | |
media_view_mode2.png | 110.69 KB | mariacha1 |
Comments
Comment #1
adam-delaney CreditAttribution: adam-delaney commentedI can replicate this issue and confirm the bug.
Comment #2
fonant CreditAttribution: fonant commentedDitto, same bug here.
Comment #3
AndrewTur CreditAttribution: AndrewTur commented+1
Comment #4
drupalove CreditAttribution: drupalove commentedThe patch given in issue 2194821 should fix this problem.
Comment #5
camhowardI'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?
Comment #6
victoriachan CreditAttribution: victoriachan at Torchbox commentedI'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
Comment #7
aimevpMaybe 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:
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).
Comment #8
brockfanning CreditAttribution: brockfanning commentedI'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.
Comment #9
brockfanning CreditAttribution: brockfanning commentedI should add, it's not just the view mode that is affected by this - it's also all the overridden fields as well.
Comment #10
brockfanning CreditAttribution: brockfanning commentedA little documentation change for clarity. For details, see #8.
Comment #11
aimevpHi 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):
This is after I hit the source button 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.
Comment #12
brockfanning CreditAttribution: brockfanning commented@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"?
Comment #13
aimevp@brockfanning:
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.
Comment #14
brockfanning CreditAttribution: brockfanning commentedI 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.
Comment #15
aimevpI have applied the patches you mentioned and it seems to be working now.
Comment #16
brockfanning CreditAttribution: brockfanning commentedThanks, 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.)
Comment #17
brockfanning CreditAttribution: brockfanning commentedI 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.
Comment #18
brockfanning CreditAttribution: brockfanning commentedEarlier 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
Comment #19
brockfanning CreditAttribution: brockfanning commentedI noticed that each time I changed attributes of the embedded item, it would generate a new delta. This update fixes that.
Comment #20
brockfanning CreditAttribution: brockfanning commentedComment #21
rooby CreditAttribution: rooby commentedNote that part of this patch is also the proposed solution for #2317519: Blank WYSIWYG with existing multiple Media content (see #56).
Comment #22
junaidpvJS 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.
Comment #24
joseph.olstadfixed in dev 7.x-2.x
Comment #26
marcvangendI 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.
Comment #27
slashrsm CreditAttribution: slashrsm at MD Systems GmbH commented@marcvangend asked me to move this back to NR.
Comment #29
joseph.olstadCommitted 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.