Original image name, when too long breaks the attachment edit screen

[anantajitjg]

Original image section in the attachment edit screen breaks the layout when the file name is too long.

Steps to replicate this issue

• Rename any image above the threshold limit (2500 pixels) to a long name, for example to 121310f3a0d098002a8bd1b50bf34b81f5f85b1a1653464450.jpg.
• Then upload the image via Media Library.
• Now choose the list view instead of the Grid view and go to the media attachment edit screen or click 'Edit more details' from the Grid view.
• In the edit screen, the original file name takes the whole line and breaks the layout.

Expected Behaviour

The 'Original image' should wrap as same as the 'File name'.

[anantajitjg]

This patch should fix the issue

[anantajitjg]

Attachment Edit screen after applying the fix

[nidhidhandhukiya]

Hello @anantajitjg
I am not able to reproduce this issue.

Test Environment :-
wordpress Version :6.0

[nidhidhandhukiya]

I have attached screenshot for better understanding.

[anantajitjg]

Hi @nidhidhandhukiya

Please note that you have to use a long name and don't use hyphens for joining the names. You can try it with underscores or use the name I have mentioned in Steps to replicate this issue section.

[afercia]

To clarify a bit: the 'Original image' section appears only when the uploaded image width or height exceed the 2560 pixels threshold used in wp_create_image_subsizes().

When this happens, the image is automatically resized and its file name gets a _scaled suffix, while the original file name is shown below in the 'Original image' section.

The patch looks good to me. Moving to next minor release consideration, as it's a simple and self-contained improvement.

[anantajitjg]

Thanks @afercia

[sabernhardt]

We were already tracking this issue in #55393, with the same patch. Instead of marking one ticket as a duplicate of the other, would closing both with the same commit be preferable?

[sabernhardt]

File names may need to wrap within the details dialogs, too, so I uploaded two options on #55393 to consider more thorough approaches.

[peterwilsoncc]

Replying to sabernhardt:

We were already tracking this issue in #55393, with the same patch. Instead of marking one ticket as a duplicate of the other, would closing both with the same commit be preferable?

It's preferable to mark as a duplicate and close a single ticket as it's easy to miss duplicate tickets during the commit process.

As #55393 includes notes from the test team confirming the fix, I've marked this as a duplicate.