The issue I'm experiencing is when inserting an image with the Media widget, the image cannot be resized initially. If I switch the textarea's format to Plain Text and then back to the Rich Text editor you can resize the image just fine. As a side note, sometimes after resizing the image and editing the page you can no longer resize the image.
In the images you can see in the first image that when I select the image it does not give the resizing handle in the bottom right corner, nor the drag and move handle in the top left corner. But if I switch to plain text, the inserted text looks accurate. And if I switch back and then click the image, I do indeed get the resize handle at the bottom right corner.
Can't seem to find any Javascript errors or any issues with the actual embedding of the image.
| Comment | File | Size | Author |
|---|---|---|---|
| #34 | unable_to_resize_images_2813413_34.patch | 763 bytes | Danny.Wouters |
| after-switching-back-to-rich-text.png | 501.95 KB | Justin Langley | |
| after-switching-to-plain-text.png | 111.4 KB | Justin Langley | |
| after-initial-inserting-into-field.png | 396.04 KB | Justin Langley |
Comments
Comment #2
m.abdulqader commented+ 1
Comment #3
joseph.olstadjust FYI if it helps for your image styling in wysiwyg, you can alternatively do it without css style:
you can alternatively set up image styles
admin/config/media/image-stylesand then add them to file entity display settings
admin/structure/file-types/manage/image/displayclick on
'custom display settings''Use custom display settings for the following view modes 'select as appropriate
Then go to
admin/structure/file-types/manage/image/file-display/teaseror
admin/structure/file-types/manage/image/file-display/previewselect the image style that you created earlier. Then when you go to your wysiwyg editor and click the media button you can select the desired display.
see docs on image styles for more info on that. image styles comes from the core 'image' module.
Comment #4
c2webdev commentedI'm having the same problem with this and I've tried the above steps, it is not working.
Comment #5
joseph.olstad@c2webdev , are you using ACF (Automatic Content Filtering ) ?
if so, add this to your ACF rules
properties;img[title,alt,src,data-cke-saved-src](wysiwyg-break,drupal-content);video[width,height,controls,src](*);source[src,type];audio[controls,src](*);img[*](media-element,file-default);p[class](*);h2[class,style](*);h3[class,style](*);h4[class,style](*);h5[class,style](*);h6[class,style](*);div[class,style](*);span[class,style](*)OR, alternatively, disable ACF.
Comment #6
rreiss commentedStill not working for me with the latest version.
And ACF = "ADVANCED CONTENT FILTER" (not Automatic..) .
Thanks.
Comment #7
brettshI'm having the same problem. Using the latest dev versions of: File Entity, Media, CKEditor (module and library) & "Media CKEditor".
I notice if I right-click on the embedded media image, I don't see the "Image Properties" option in the popup menu.
Comment #8
brettshFYI, I've manged to get the image resizing & image properties (popup) to work by rolling the CKEditor library back from 4.7.1 to 4.5.11.
Comment #9
joseph.olstadthe expected way (for file entites of type image) to do image style is to properly configure the file entity display modes.
/admin/structure/file-types/manage/image/file-displayfrom there you can configure an image style (provided by the core module called 'image') and set it to the desired display mode.
once properly configured, the drop down provided by the media browser image selection options will give you the display mode, for each display mode you can have an image style according to your requirement.
here is where you set the image styles:
/admin/config/media/image-stylesthe advantage of doing it this way (it is better because:) is rather than changing the image attributes rendered by the browser, the actual image it'self sent over the network is smaller. This means optimal bandwidth consumption, faster page loads, more efficient.
drupal crops the image to the image style, keeps the original image internally, but only renders the image style image, thus only sends that image to the client.
there are many default view modes, however if you need to add your own, you can download, install and enable the
entity_view_mode module and add some additional entity view modes at
admin/config/system/entity-view-modesComment #10
joseph.olstadas for a possible regression between the ckeditor library version 4.5.11 and 4.7.1 , please do submit a patch if you make one.
Comment #11
rreiss commented@joseph.olstad You are right about the advantages of image styles, but it won't cover all use cases.
Content mangers must be able to resize their images dynamically.
The only possibility (I can think of) to do that with image styles is with the ais (adaptive image styles) module and a custom div with width attribute that wraps the image.
Comment #12
andrewtur commentedHi,
I tried this on a fresh installation:
Setup:
Media: 2.10
Media CKe: 2.5
CKeditor: 1.19
File Entity: 2.2
CKe lib: 4.6.2 (lineuntils, widget,widgetselection, clipboard)
other dependencies newest stables (ctools ..)
I set this up according to recipe (https://www.drupal.org/node/2843391). But I too could not resize images (not by dragging).
I could also not open the image properties popup by right click or double click as long as the plugin widget st enabled. Turning it off gave me the option for the properties popup but drag still is not working. I tried the method mention in the issue description but to no avail. I made no changes to the file entities so the standard image (upload) is being used.
Comment #13
joseph.olstadconfigure your image styles as desired;
example: medium, large, small, extra small, extra large
Then to configure the various file displays used by the media browser have a look at
#2888472-4: Images shown as links
you can set up several different file displays, assign one image style per display.
Comment #14
andrewtur commentedHi,
the image is display just fine. But i have set it up now anyway.
But still i cannot resize the image in the editor mode by dragging the bottom corner of the image.
Comment #15
joseph.olstadIt has been reported above that downgrading ckeditor library from 4.7.1 to 4.5.11 helped, see:
#2813413-8: Unable to resize images inserted with Media
Comment #16
andrewtur commentedHi,
I was able to get the resizing to work again even with the Ckeditor 4.7.2. I did not know you needed the image2 plugin for the resizing but after seeing a demo and some investigating I found the answer. Nether the less I also have the Problem that I sometimes need to switch from WYSIWYG to Plain Text and back to get it to work.
Another drawback is that after resizing it is no longer a File entity but an image so all file entity fields are lost like source field. I am still looking for a better way to accomplish this.
Comment #17
joseph.olstadAndrew@Germany , from the description of your issue it sounds like your configuration is incorrect.
Please review the media recipe troubleshooting section and overall recipe.
Comment #18
andrewtur commentedHi joseph.olstad,
I followed the instructions from the recipe and include the #8 from this issue using the 4.5.11 version but both don't work unless I use the enhanced image plugin from the ckeditor which has the click drag feature. I can resize the entities by editing the code from the token but that's not something i can tell the editors to do.
I tried all of this in a Sandbox to avoid conflicts with other modules and only enabled the ones necessary. I would be awesome if you could set up a tutorial Video on Youtube or something like that.
Comment #19
joseph.olstadOne way to add view modes is to use this module: entity_view_mode by Dave Reid.
I'm currently working on a high performance, cutting edge distribution of Drupal 7 specifically for media that will help everyone see how an optimized configuration would work.
see the 'media_dev' project (distribution of Drupal for Media) hopefully in the next while you should see some progress.
Comment #20
joseph.olstadOtherwise, refer to the media recipe page as it's currently the most detailed installation and configuration instructions.
Comment #21
andrewtur commentedHi ,
joseph.olstad thanks for all the support up until now. I have finally figured it out. I used the media_dev and then a local sandbox and it work in both installations. I tried it in my project and there it failed. The reason was that we also use mathjax. By using mathjax the ckeditor puts a span wrapper around the image-tag preventing me from editing the image properties.
I still have to figure out why this happens if you have any idea or other information on this I would very much appreciate it. I will open a new issue for this in mathjax or ckeditor module.
The Element
Comment #22
andrewtur commentedHi joseph.olstad ,
I created a new issue since I thought my problem did not relate to this anymore. But I still keep at it and found some thing. I've update the issue and paste my findings into the quote beneath. I hope this is helpful. This can also be reproduced in the 'media_dev' project. All you need to to is download the Widget addon for the ckeditor and enable it.
BTW here is the link to the issue I opened: https://www.drupal.org/node/2905659#comment-12245765
Comment #23
joseph.olstadWow this is great detailed and helpful information.
Hmm, I'm wondering what the appropriate action would be from the module perspective? Whether or not there's a way to see if the widget plugin is available and somehow notify or warn people that they could be using this. Or if we just update the media recipe , there's probably a patch we could write for the ckeditor library that would enable this plugin.
sounds a bit complicated, but the workaround is quite simple. Thanks for sharing!
Comment #24
codechefmarcFollowing.
What do you mean by this? I'd love to see a patch or workaround that doesn't involve editing this module js directly as I don't want the changes to go away next upgrade. I did put the widget plugin into my libraries folder and pointed CKEditor there. Though there is no checkbox under editor appearance to enable the widget plugin. So, not sure how to enable the widget plugin.
Comment #25
vchen commentedAgreed, this should be turned into a patch. You shouldn't have to remember to edit the module files for the next upgrade...this feels very un-Drupal-like.
Comment #26
andrewtur commentedHi,
this was meant to be a quick fix not a permanent solution that is why i did not and won't create a patch for this since it does break/disable the widget plugin support. A better solution should be sought for this issue.
Comment #27
codechefmarcNo worries, Andrew, I figured there was a way to simply enable the widget plugin and avoid having to comment out the code directly. Have you been able to do that or are you still commenting out the code as a workaround? Thanks!
Comment #28
andrewtur commentedHi,
since i require the widget module for the mathjax plugin I cannot disable it globally and have to rely on this workaround/hack so yes i'm still running this. If you do not need the widget plugin for other plugins you can omit it on your ckeditor build and you should not have to use the workaround. Hope this helps.
Comment #29
vchen commentedAndrew,
Thank you for your last comment! It's tremendously helpful.
This has been confusing. All this time, I thought having the Widget module solves the problem--not the cause of the problem! I disabled the Widget module and am able to get image properties back in the option menu.
So the Widget module shouldn't have been required in the Media Recipe. I only enabled it because it was required.
Comment #30
mqanneh+1
Comment #31
joseph.olstadOK I will update the recipe removing the widget module
Comment #32
joseph.olstadI updated the recipe to make this a little more clear.
https://www.drupal.org/node/2843391
hopefully people will have more luck now with the image plugin.
Comment #33
robcarrI've followed Joseph's recipe (#32) - thanks for putting that together and that was incredibly useful.
However, I've found that enabling the Widget plugin empties any Longtext field that already has an inline image in it... so having followed the recipe, I left the Widget plugins disabled and the resize handle will only appear [after uploading/inserting any image] if the 'Switch to plain text editor' is toggled off then back again to the rich editor. The resize handle will also appear now on previously created content.
So my solution involves disabling the Widget plugin and only solution #1 works for me... !!
Comment #34
Danny.Wouters commentedThanks everyone for looking into this problem.
I created a patch for the fix mentioned in #22
Comment #35
joseph.olstadthanks for the patch, ya I guess if media_ckeditor isn't compatible with that widget we should just ignore it like that.
Thanks a lot for this patch, ping me if I haven't pushed a fix for this in the next month or so.
I hope to deal with this in the next month or so.
Comment #36
joseph.olstadI'm working on a clients site and they are not using this patch, yet everything works for them.
I think the trick maybe is that they're using all ckeditor libraries and plugins widget and widgetselection same version as well as lineutils same version and ckeditor library of same version 4.6.2 rather than 4.10.1
Anyhow, for my current client they're using all current versions of media and media_ckeditor except the library versions is 4.6.2 however there may be some other configuration involved.
If I find a definitive solution in my sandbox that I can reliably repeat I'll updated the media recipe with the ultimate definitive steps and details.
Comment #37
joseph.olstadI've updated the media recipe with the plugin versions I found to work perfectly.
so using the recipe, everything I tried seems to work, image resizing worked and right click worked with image properties.
https://www.drupal.org/docs/7/modules/media/media-recipes/media-ckeditor...
I also added the image2 plugin, not sure if it was required but it doesn't seem to hurt having it in there.
It seems that ckeditor 4.10.1 is problematic
ckeditor 4.6.2 works nicely and I updated all the plugin versions to 4.6.2, make sure if you replace your ckeditor library to also replace the plugins as defined in the recipe
Sorry for the trouble if I caused any, 4.6.2 is the goods.
No need to patch media_ckeditor
Comment #38
joseph.olstadok sorry for the long wait and all my confusion, I've finally gotten around to testing this patch out and it seems like it's the right way to go
I have one more test to do and then if that passes, it's going in.
Comment #40
joseph.olstadtagged release to follow shortly
Thanks, sorry for the delay!
Comment #41
sgdev commentedI don't like this patch. For our sites, all users are required to define their image size based on view modes, including view modes that are for scaling at different size.
Introducing this change opens a loophole where users can modify the image outside the pre-defined view modes within CKEditor. I would prefer if this was an optional selection in the Media CKEditor configuration settings.
Comment #42
sgdev commentedAnother problem with this patch is it strips the wrapper provided by the "Display fully rendered files in WYSIWYG" Media CKEditor setting so the image can be dragged around the page with its image handle. It only provides classes on the image itself and doesn't actually render it as a file.
I'm going to write a new patch to make this optional, we cannot use it.
Comment #43
sgdev commentedI've posted a patch for review to make this an optional setting, and not break sites that rely on the originally-intended method of generating images via view modes: https://www.drupal.org/project/media_ckeditor/issues/3068600
Comment #44
joseph.olstadRon_s , thanks for your reporting and for your patch in the other issue, however I've got some questions, what version of the ckeditor library are you using? Because anything higher than 4.6.2 the image properties seemed to stop working without the above change.
Comment #45
sgdev commentedSure, have been using the most recent versions, including 4.9, 4.10.1, 4.11.4, and now most recently 4.12.1. Nothing as old as 4.6.
What I'm having a hard time understanding is why someone would want to use the Image Properties with the Media Browser, since using the two together is confusing at best, and can lead to improperly saved image data and responsive design problems at worst.
When embedding images via the Media Browser, the user is given the option to select a view mode, align the image, and enter a URL to wrap it. If the Image Properties selection is enabled, a user can effectively override the view mode and alignment, and even create a conflict with what was originally selected in the Media Browser.
Also as I mentioned, it causes the image to lose the Media CSS classes that wrap it, making the Media Browser alignment options essentially null and void. If using the Picture module + CKEditor integration, the Image Properties popup window requires the selection of a image style breakpoint group, which will conflict with the Media Browser view mode selection. And since the image is not rendered as an entity via a view mode once Image Properties is enabled, the drag-and-drop handle disappears.
What we have in our configuration are different view modes representing different image sizes. If users want to resize the image, they just select a different view mode. This also allows us to keep all images consistent regarding responsive design. I would actually argue that allowing users to resize images on a one-off basis without any consistency is poor mobile device design.
Comment #46
joseph.olstadhi @Ron_s ya I understand the wanting to use image styles intead of image properties and I am in agreement with you, however it is a bit tough to set up, and even though I set this up and took the time to add many image styles and had image styles working perfectly with media embed, I set this up for my latest client and the client got really upset and started turning purple and blue in the face, I had to restore the image properties functionality and they were happy again.
image properties does the job, in this case my clients source images are already 'not too large' and they want to have the control directly in the editor.
in a perfect world we'd have a wysiwyg interface for image properties and would generate the image according to the exact spec at moment of editing, not presets.
ideally we'd also have a copy and paste to just paste in a clip of an image right into the wysiwyg as this is being done already in other systems, maybe even some contrib modules exist for this not sure.
Comment #47
sgdev commentedThanks for the response Joseph. Sure, I can understand it can be challenging to set up, although I think the approach we've taken has mitigated the concerns of at least our clients.
We have over 60 image styles that are all built programmatically. Nothing is stored in the database. If a client feels something is missing, it is literally about 30 minutes to add a new image style + picture formatter + file entity view mode with variations for different breakpoints. The styles range from those that are scaled while retaining aspect ratio, to trimming to fit specific sizes (16x9, 4x3, etc.), widths, etc. I have yet to see a situation where an image needs to be something outside of one of the options we have configured.
While I do know there are some power users who feel limited if they don't have access to HTML, my experience has shown they are the minority. Most just want to have the image "look good" with minimal intervention. Also for the client who turned blue in the face, is this someone who actually takes the time to see how images are displayed in mobile devices? I find that *most* of the time these users open the editor and get everything looking perfect on their desktop computer, but never once look to see how it renders on a phone or tablet.
We actually ban access to HTML source in CKEditor. I think it does more harm than good for 95% of users. Instead, we focus on providing all the tools users will need to make changes without accessing HTML. Yes, this means there is a lot more work for us to make this happen. We have made many CKEditor adjustments, including a long list of CKEditor "Styles" and "Formats". However, by doing so, we have syntactically correct HTML, and can ensure the site always looks perfect regardless of content and device size (while still allowing users to have a high level of customization).
I agree that less presets and more wysiwyg is a better approach, but obviously the tools for Drupal are not there as of now. Also, the disconnect between Drupal and CKEditor is enough of a problem that we have to put restraints on one or both to avoid loopholes. Regarding a copy/paste of a clip, do you mean like some type of shortcode for images that gets rendered as the actual image?
I'm fine that there are some people who feel this is a necessary answer to meet client demands, but it's not something we want. I think our approach meets the need, and as long Image Properties are an optional setting, that's ok.
Comment #48
joseph.olstad"over 60 image styles that are all built programmatically"
wow that's a lot of image styles, very cool.
Wondering if you have provided patches somewhere or custom helper modules to achieve this?
When I implemented the view modes I used the entity_view_mode module . I've done some interesting work on image style contrib modules like imagick (use the dev version) (image optimisation for jpg images using google recommended techniques, a good free alternative to tinypng)
sounds cool.
But ya, my most recent client is a university and even the content people are quite technical they're happy with what they've got (and didn't want me to mess with it).
Comment #50
junaidpvWe are also affected by change from #39. Media embedding became kinda screwed with this change.
We are using image_style based sizes for embedding images. There are pre-defined image styles for various aspect ratios. No image resizing is supposed within editor.
All of our production sites are affected! Bad thing is, we did not notice until one of client reported it.