Allow editing of Width and Height of embedded <drupal-media> images

Created on 4 June 2023, about 1 year ago
Updated 16 June 2024, 12 days ago

Problem/Motivation

Over in CKEditor5, Provide a way to embed Media Image as primitive image in editor, to enable image edit functions Closed: duplicate , there is a discussion re: the difficulty site editors are facing with not having the ability to manually resize <drupal-media> elements. The solution provided in this thread was to add a configuration checkbox on the text format to use an <img> tag for the image media type, which would allow content editors to:

"Place Media image as a normal image element using <img> tag, rather than using <drupal-media>, to enable image editing options, i.e. resize by drag and drop and use other other image edit options."

However, there are several notable comments re: this approach as noted by:

@lauriii

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.

@seanB

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 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

.

Steps to reproduce

Proposed resolution

When a image is embedded in the editor allow editors to manually adjust the width and height of the image via fields for each value. For reference, see the contrib Media Embed Extra module .

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Feature request
Status

Active

Version

11.0 🔥

Component
Media 

Last updated about 17 hours ago

Created by

🇺🇸United States Chris Matthews

Live updates comments and jobs are added and updated live.
  • Needs usability review

    Used to alert the usability topic maintainer(s) that an issue significantly affects (or has the potential to affect) the usability of Drupal, and their signoff is needed. When adding this tag, make it easy to review the issue. Make sure the issue summary describes the problem and the proposed solution. Screenshots usually help a lot! To get sign-off on issues with the "Needs usability review" tag, post about them in the #ux channel on Drupal Slack, and/or attend a UX meeting to demo the patch and get direct feedback from designers/UX folks/product management on next steps. If an issue represents a significant new feature, UI change, or change to the general "user experience" of Drupal, use Needs product manager review instead. See the scope of responsibilities for product managers.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

Sign in to follow issues

Comments & Activities

Production build 0.69.0 2024