CKEditor5, Media Image is not rendered as img in source view.

Hello. I think this is a duplicate of ✨ Allow resizing media Closed: duplicate or one of its related issues. Can you confirm?

It definitely is! The only way you can resize images is to configure view modes as you like and then configure that view mode for to resize to whichever image dimensions you like.

#3245720: [drupalMedia] Support choosing a view mode for → introduced that — it looks like this:

When to add image from Drupal media, it now uses rather than to get benefits of image operation.

@Wim Leers You are mis-reading my intention.
I do not want that display mode options actually here.

I love image resizing function in CKEditor5 (by drag and drop), and I just want it for Media Image, too.
That's why I made this issue to create a patch.

However I do not demand to merge my fix into Core, as mine is just a workaround.

Having media library view mode available is good call, but sometimes users do not want that much, just they want simply drag drop.

Added configuration checkbox, whether use <drupal-medai> or <img> in Filter Option as shown in screenshot below:

Fix code standard.

Code standard fix included.

Build js in prod mode.

Guide

Once install patch, then visit text editor configuration page, enable `Use tag for Media Image type` option in Filter settings \ Embed media

Loving your enthusiasm! I've pinged my fellow CKEditor 5 module maintainers @lauriii and @bnjmnm to discuss whether this is an approach that Drupal core committers can agree on.

But let me definitely say: that's a very impressive first contribution to Drupal core! 🤩👏

@Wim Leers Thank you for your kindness. I really hope this feature would be a part of Drupal core, so that for those lovers of Media Library can continue using it in CKEditor5. Cheers.

Did you already research if it would be possible to enable resizing for <drupal-media> element? It would be really nice if we could do that because it would allow us to keep the data in a consistent format.

@lauriii I am not a CKEditor developer, and it would take much time for me to dig into CKEditor core to enable resize function on custom tag. Regarding the fact that it renders <drupal-media> based on Drupal tpl (which can be fully customized), there will be not bullet-proof methodology to make code> element resizable safely. (I hope you understand the point what I am pointing, right?)

Current media image edit dialog has only Alt and Caption, I felt there is really not a good reason to keep <drupal-media> tag.
Apparently users do not care about it actually, they more care about functionality like resize.
It 's actually very natural question, "I imported image, but then why do I see <drupal-media> tag there?"

That's why I came up with this solution in pretty normalized way ( because now all images will have same edit workflow).

Thanks for the additional context @Austin986! That is really helpful.

The argument about <drupal-media> is strong and would be a good reason to use your approach. I'm not against the proposed approach, I just wanted to check if you had given consideration to that option, and it sounds like it was considered.

I'm going to try to ping the media maintainers for their feedback on this, since this is essentially more to do with Media than CKEditor 5 itself.

This would be a great feature! But should it be targeting D10 and if it gets in before D9 EOL it can be backported?

@smustgrave So it sounds like I need to create D10 patch, too.
Do I need to create another branch for D10?
What is the standard process to make it mergeable for current Drupal Core dev?

You can create a new branch and in the dropdown select 10.1.x. Maybe append 10.x to the branch name.

or
Can upload a new file and before clicking "upload" select 10.1.x in the Test with dropdown.

Doing a testing review

Functionally seems to be working.
Turned the drupal-media into an img tag that was resized.

But in support of drupal-media what if there are additional fields on the media, like author? This would strip the additional fields from being used.
So really we aren't embedding media anymore just pulling the image from a media object to be used.

Is that correct?

@smustgrave By enabling use <img> tag option, no longer <drupal-media> is not used for Media Image.
This usecase is for those who use media library in CKEditor5 only to select images, not much than that.
People mostly love to use Media Library to manage images in CKEditor5 because it has good organized view there, rather than using Media Embed itself.

Not to be discouraging but I don't think this is the solution for resizing media. Because this patch isn't embedding media anymore it's just turning media into an image, same as the existing image upload button. So this is turning the media library upload button into the image file upload button more or less.

The use case you're describing for wanting to use media library is to be able to browse images, but again not to insert media but to insert just the file. Essentially what https://www.drupal.org/project/imce → does.

This kind of feature sounds like it would belong in contrib vs core but will let the subsystem maintainers decide that.

@smustgrave

It's rather frustrating.
It sounds more like Media Library is only existing for it's own sake, not for better UX.

Is not Media Library purposed to provide better media management experience?
Why would users have to deal with folder-structure based file browser when they prefer manage images in Media Library?
I am afraid it could be one reason why people will prefer to use other CMS that UX is a kinda complicated and not unified.

People love to use Media Library because they can browse previously uploaded images in nice page view with search function.
That 's the reason people choose to use Insert Media over Insert Image.

It will be great there is the way to place media images using <img>, so that they can be configured same way with normal images.
I do not insist my solution is good enough (because it disables <drupal-media> for images for specific configuration), but this feature is really needed for better UX.

Maybe there can be 1 more button saying "Insert as Image" on Add Media dialog, so that user can choose how they like to use.

Please consider providing a way to place image into <img> via Media Library in future Drupal Core.

Would say the media library button allows you to embed an entity reference to a media object. Allowing for the entity display displays setting to be used. That reference has now been lost and replaced with the img tag. So the media library and view mode settings aren’t used anymore and as mentioned entity reference is lost.

Didn’t test but looks like if you add a media, which becomes an img, and edit the media object it won’t reflect on the node as the reference is gone.

Which seems like a regression.

This patch enables additional option on Filter Settings of Embed Media in Text format configuration page: Use <img> tag for Media Image type , and the default value is FALSE (unchekced)

When you add a media, it becomes img only when

• you checked for Use <img> tag for Media Image type, and
• media you are adding is image type.

I do not see why it becomes regression when it has additional option available.

Also, by default, Media image is rendered with <img> tag in published view (unless you made custom tpl for specific display mode to use somewhat different tag), so I do not see why we could not allow them in <img> tag in CKEditor5.

I see the the benefits of display mode, which is useful if you want to provide various rendering way for image, that's why I made an option available.

Also I am gonna change the title of this issue because in deep, it does not make Media Image resizable.

I do not care if my patch would become a part of Core or not, but at least I want things to be considered for UX perspective.

Patch for Drupal 10.1.x

Patch for Drupal 10.0.x

Patch Notes

Patch for Drupal 10.0.x

Just patches are probably fine for now. To save you time

Changes are causing test failures (least for 9.5)
Will need its own test coverage
Upgrade path
And maybe some other parts.

But left in review for the submaintainers to decide if it’s worth going forward.

If so it will need work for those other pieces

@smustgrave Thank you for your notes.
I created branch from 10.1.x as you guided, but when I clicked Merge request, it processed as if I requested to merge into 9.5 dev.

Is there any configs I m missing?
What is the correct way to issue right merge request?
Just curious as I am new for this part, so any tips would be appreciated.

On the MR you want to be for 10.1.x, https://git.drupalcode.org/project/drupal/-/merge_requests/3992, in the three dots menu you should be able to change the target branch.

Only you and maybe committers can change target branches. On older tickets you may see MRs for 9.2, 9.3, etc

When creating the new branch there should have been a dropdown saying what do you want to branch off of too.

@smustgrave Thank you for your kind direction, I did not see that there. Also I did not know that I should login again there, too. (did not notice I am a guest when checking MR)

Never really ran into this before. The main benefit of view modes is that you can have responsive formatters. Resizing in CKEditor to a fixed size might be good for some images, but for responsive sites you probably want to have better formatting than a fixed size.

I'm afraid we also can't skip the Drupal media tag since not every media item is an image. Thet being said, how about allowing to set a width / height attribute first? The attributes are passed to the media templates and can be used to set a width and height on the image tag. Not that familiar with the CKEditor code and how easy it is to make freehand resizing possible, but maybe that could be a followup to make it even nicer.

@sean B Have you read full thread attached here?

First of all, this patch includes option to use <img> on <drupal-media> and default value is FALSE.

Never really ran into this before. - It does not mean that others wont run into this problem, I brought this from end users' perspective and requests.

The main benefit of view modes is that you can have responsive formatters - I do not see the point frankly. In order to make it fully responsive, need to edit TPL file any way (which will be handled by dev) and then question here is why dev needs to create 2 separate responsive CSS for both cases when it s same image posted in CKEditor.
I just simply wanna remind that there is another easier workaround, too.

CKEditor to a fixed size might be good for some images, but for responsive sites ... - Not really, when we build site using Drupal, we create responsive css for images in CKEditor, too, also there is modules to support responsive size option → for individual images (not sure if it works for CKEditor 5 though. )

I'm afraid we also can't skip the Drupal media tag since not every media item is an image. - I mentioned clearly in my comment, as well as it 's obvious by code itself, it only use <img> tag for Image types.

how about allowing to set a width / height attribute first? The attributes are ... - Rather edit sources to wrap with new div assigned specific width and height. Again, this patch is for those who want simply use <img> tag rather than <drupal-media> tag, to simplify and unify UX for Image handling in CKEditor.

It is so sad you do not see what I see.

Basic CSS is available for those who choose the option to make img responsive. We use .img-fluid for all of our images, which handles nearly all of our use cases. Not having the basic ability to resize a Media image cripples the editing experience in Drupal. We do not use media for this specific reason, and rely on the old upload image.

Editors demand to be able to resize images in the editor. Media caused an UX regression many years ago and was never fully addressed. This new img tag option is a major pain point relief. Thank you! Austin for stepping up to make Drupal more usable for editors.

This still needs someone to look into whether it is possible to extend CKEditor's resizing functionality to see if it can work with <drupal-media> tags.

This is very important feature which is always requested by client, but I don't think using img instead media-image is correct approach.

@dehacker
Thank you for your kind words, it 's my great pleasure to see someone really understands what I tried to cover.

@DamienMcKenna, @m.abdulqader
First of all, there is patch for Media resize (not sure if it works though) https://www.drupal.org/project/entity_embed/issues/2932871 ✨ Allow manual scaling of embedded image entities in CKEditor Needs review
And the purpose of this patch is to provide option to use <img> tag than <drupal-media> for Media Image in CKEditor, so that exactly same edit action can be applied to Media Image, too, for unified and easier UX.
I came to this solution per customer requests, and I do not see what makes you think this is not correct approach.

I am so fed up to explain every details one by one, even if it's so obvious that this additional option is actually provide better UX.

As long as Drupal is not a academic & scientific research project, I do not see right reason why we should reject progressive additions which provides better UX.

I no longer demand this function to be merged into Drupal. Good luck.

Let me thank all of those who freely spend their time to handle enormous projects such as Media, being particularly difficult. I understand it is often a thankless task.

I've been building in Drupal since D6. The fact that we had more practical capability to resize images over ten years ago suggests that Media may be over-engineered and inflexible in certain instances. These are, however, very basic instances. Drupal is always compared to other CMSs for its editing capabilities, and having resizing and positioning as basic features is a must. This is why we often avoid using Media. It's a shame because we just want to provide editors with a repository of images to choose from, and perhaps add an image style upon insertion if desired.

Content Editors expect the ability to resize with handles. I've never encountered a use case that required the extended functionality of beyond what typically provides. Others may have, but this comes at a cost to the broader community. Drupal needs some flexibility within structured data to compete, especially when it comes to this use case. Maybe someday a more structured way to handle this will emerge, but living with this inflexibility is impractical for a basic editing experience.

That's my two cents. If I had the skills to contribute to such an achievement, I would be eager to contribute. But I can speak as a dedicated builder struggling to keep companies and sites moving forward due to this issue Again, thank you to the maintainers of Media and the general core architects for all the work put into Media.

Saying this respectfully as this ticket has gotten hostile it seems.

My 2 cents

What makes the media library button useful is that it embeds an actual media object. That media object can be edited without needing to update each node that's using it. Also the view display can be alter and picked like a true reference to an entity.

From what it seems the desire is to use the media library as a way to browse media but not use it as media but as pure images.

This feature seems to undo a lot of features for media library to turn it into pure images.

Opinion is this would be better suited as a contrib module vs core as it introduces too many regressions of media library

But leaving up to sub-maintainer for that.

Agree w @smustrave on all points, especially with the idea that a contrib module for this feature would be suitable. When neither Media, or Media Image Tag solutions are overly opinionated, but can work modularly to suit a sites particular need, we get back to what Drupal does best.

Most use-cases I would be very happy to use a contrib module that enables this feature. Often, usage speaks to the need for core to then absorb some of these features in future release. I hope @Austin986 would consider this approach, as Drupal really needs more contributors with this kind of UX and dev skill.

Updated to avoid error when to use Remote Video option.

I 100% agree that the lack of resizing of media images is a problem. This is true even though many use cases could be covered by view modes and image styles. This is something we've heard from several users, and looks like there are several folks on the issue agreeing with it as well.

However, the problem is with the proposed solution which creates other problems that we haven't addressed such as the fact that it completely bypasses view modes. One idea I had earlier was to try to create a new special view mode for rendering media as "raw". This way we would integrate the view modes to the proposed solution here.

I'm personally not opposed to the idea proposed here as long as we make sure it doesn't create other major problems. I'm not a subsystem maintainer of media and this involves them, so we may need their input too.

To maximize the chances to close this issue, I would personally suggest remaining open to alternative solutions just in case we can come up with something else that we believe is easier for us to implement. After all, the problem we are trying to solve is that we'd like to allow content editors to resize images, and there could be multiple ways to achieve this.

I would personally suggest remaining open to alternative solutions just in case we can come up with something else/blockquote>

What are the alternative solutions? Media has been out for over 8 years and Drupal still doesn't easily resize a Media image in the basic editor. We're about to lose a major client to another CMS due to lacking editor experience.

Set src-type by MediaSourceInterface->getPluginId(), to enable feature for custom media types.

There are reasons that media works the way it does, and I wholehearted agree that we need alternative solutions. With that said, what I am absolutely not OK with losing is the ability to track media within WYSIWYG content. That would be a huge step backwards for Drupal.

When you think of resizing an image in WYSIWYG what you are doing is contextually passing parameters in the media token to create an image derivative. Right now, the core media implementation is not pluggable to support extra features, like cropping.

Here we have a core problem, most noticeable in fields, but also applies to media embedding. Normally we add media to the library, but we may want to use that same image to create a banner, portrait, square, etc. Right now you need to upload that same image multiple times, and on the media item you set the crop. What would be better, would be upload that image once, and each time you select it, you have the ability to render the media with contextual settings.

There is a core issue covering this ✨ Override media fields from the reference field Postponed and a contrib module Media Library Media Modify → that provides this functionality. Going further, there is Media Contextual Crop API → which opens the door to allowing us develop integrations with any of the existing image cropping/resizing tools. For WYSIWYG media token support there is Media Contextual Crop Embed → which currently supports Focal Point and ImageWidgetCrop.

Using the above suite, we now have the ability to modify the image in the "Edit media" popup within CKEditor, here is a focal point example:

This is pretty much the closest you are going to be able to get with Drupal currently, and you can still use Responsive Image so your WYSIWYG images can pass Lighthouse testing. You are free to help out with adding more plugin types. Unfortunately this will stay in the contrib space until at least Drupal 11. There is a lot of work still left to do.

Normally we add media to the library, but we may want to use that same image to create a banner, portrait, square, etc. Right now you need to upload that same image multiple times, and on the media item you set the crop.

Isn't this what different view modes are for, with each view mode able to use a different image style? Why do you need to upload different versions of an image for different use cases?

Isn't this what different view modes are for, with each view mode able to use a different image style? Why do you need to upload different versions of an image for different use cases?

I had mentioned that it is more apparent when using media within fields ie; entity reference fields setup with the media library. View modes options are not selectable on the admin form, and for modules like Focal Point, the focal points are saved directly to the entity, not the entity that is using it. If a user updates the focal point on a media item, it will update that image everywhere it is used, but say that author only wanted that particular focal point on that particular node in that specific instance.

The core issue and Media Library Media Modify allow the media system to store contextual data along with the reference field. For this issue in particular, the media embedding within WYSIWYG can also benefit from this, for custom crops, resizes, whatever data you need to override when rendering the image.

First of all, I want to emphasize that I think we can/should definitely add improvements in core to address this. Even though I understand the frustration of core moving slow, let's please focus on finding a proper solution.

Like I said, If we would like to have a relatively simple solution, allowing the width / height attributes to be set in the media edit popup could be the easiest improvement. This would address the problem if I'm not mistaken? The attributes can be passed down to the rendered image tag. Having a manual dragging resize feature would definitely improve the UX, but would also be a much bigger / complicated patch to get in. I would suggest creating a separate followup for that, so we could at least have some improvement in core.

Changing the drupal-media tag to an img tag seems to be a hack around getting drag resizing to work for drupal-media tags. It also definitely has some side effects, most importantly, not being able to differentiate media and files in WYSIWYG data. Custom/contrib modules relying on this would definitely break. If people really want it, that's fine, I think contrib should be able to handle it. For core I would vote against doing this.

Drupal: 9.5.9
PHP: 8.1

Using the patch in #59 ✨ CKEditor5, Provide a way to embed Media Image as primitive image in editor, to enable image edit functions Closed: duplicate for 9.5, I'm unable to insert images and just get the following AJAX console error:

@fsabbagh First of all this patch is not a perfect one, and I did not get some time to refine this patch.

You are seeing the error because you did not place [Insert Image] tool on toolbar.
The best scenario with this patch will be
- Use [Insert Image] only for remote images (by not allowing upload image)
- Use [Media] for insert images uploaded in the system already.

Made a fix to cover the issue for #64

- Logic updates
If image is not activated, this option wont work.

- UI Updates
Added description to explain this option is only applied if Image tool is activated.

seanB mentioned in #63 ✨ CKEditor5, Provide a way to embed Media Image as primitive image in editor, to enable image edit functions Closed: duplicate

If we would like to have a relatively simple solution, allowing the width / height attributes to be set in the media edit popup could be the easiest improvement. This would address the problem if I'm not mistaken?

I think that is right on, which is where a contrib module like Media Embed Extra → comes into play and would IMHO be a worth addition to Core.

That is wonderful, thank you so much @Austin986 → ! Works as intended, with the Image button in the WYSIWYG enabled.

@chris The related ticket is working to address media resizing. And the current proposal is something like media embed extra. But that module currently doesn’t work ckeditor5 I believe.

Yeah, I guess I was just attempting to re-iterate what Sean mentioned,

Having a manual dragging resize feature would definitely improve the UX, but would also be a much bigger / complicated patch to get in.

Therefore .... I 💯 agree that we should start with a relatively simple solution, allowing the width / height attributes to be set in the media edit popup, and then build upon that.

From the Drupal 7 Media days ...

Editors not being able easily resize an image to their liking, apart from a View Mode which requires a site builder to setup, definitely seems like a UX regression and adding a width/height modifier seems like a step in the right direction to merge structured content & flexible content together.

I agree with @seanB.

Let me also be clear about:

• I definitely think we need drag-and-drop resizing in core. It's just a really basic feature and the lack of it (and the need to hack around with view modes) is very noticeable, painful, and cumbersome. So I have an enthusiastic +1 for this feature in general.
• I also think that falling back to an img tag is not the appropriate solution. It breaks the data relationships that are the foundation of the media system, and that's going to cause a lot of other problems down the line. So I too am not convinced that this particular implementation is appropriate for core.
• People might also want to be able to resize other media types, like YouTube videos. This should be made to work for as many different kinds of media as possible.

So I think we should either rescope or close this issue, and transfer credit to another issue where we, y'know, make drupal-media widgets drag-and-drop resizable! Let's do it right.

Removing the subsystem maintainer review tag, since both Sean and I have now weighed in here.

Based on the reviews from the subsystem maintainers above, I'm closing this as a duplicate of ✨ Allow editing of Width and Height of embedded images Active . For core, we'll go that direction instead. (Maybe this approach could be used in contrib if anyone is interested in doing that.)

Thanks everyone for all their thoughtful discussion on this issue.

CKEditor Media Resize → looks like a promising contrib solution.

We tried adding the patch but I get this, Looks like Drupal 10 gets this patch installed but my drupal_media is not converted to img tag

Applying patches for drupal/core
https://www.drupal.org/files/issues/2023-05-12/3359725-ckeditor5-media-i... →
(CKEditor 5 media image patch)
Could not apply patch! Skipping. The error was: Cannot apply patch
https://www.drupal.org/files/issues/2023-05-12/3359725-ckeditor5-media-i... →

Please help test the CKEditor Media Resize module → as it lets you resize media images right in the editor using a drag 'n drop interface. The main developer has it working pretty well at this point, we just want to improve documentation and bug test different scenarios before making a stable release.

@DamienMcKenna CKEditor Media Resize module does not allow to freely resize images, it is forcing to a set of default image styles your plugin creates, even if I have disabled using image styles in Media settings.

Just chiming in to +1 a few things:

1. Drupal core obviously needs arbitrarily (with aspect ratio locking) resizable media embeds. It is a common and frustrating request to fulfill, which we have, at this point, digressed to adding both Media and Image buttons to the toolbar (yuck!). Explaining and getting your average user to understand the differences is nearly impossible.
2. Keeping the tracking (and thus <media-embed> tag approach) is critical.
3. I also checked out CKEditor Media Resize module, as @amityweb mentioned, does not at all do what is being discussed here. It simply bypasses the need to use view modes for embedded media resizing and you are still limited to image styles; no arbitrary resizing.

Will keep an eye on ✨ Allow editing of Width and Height of embedded images Active for further developments. Thanks to @austin986 for trying to come up with a viable solution.