Make WordPress Core

Opened 5 years ago

Last modified 5 months ago

#48485 accepted enhancement

Custom image size not generated if identical to original size

Reported by: brampeerlings's profile brampeerlings Owned by: joedolson's profile joedolson
Milestone: Future Release Priority: normal
Severity: minor Version: 5.2.4
Component: Media Keywords: needs-screenshots has-testing-info needs-patch
Focuses: ui, administration Cc:

Description

When defining a custom image size using add_image_size and uploading an image that has exactly the same dimensions of that image size, the new image size is not added. This also means that -- when adding the newly defined image size -- to the Insert Media screen using the image_size_names_choose-filter, the custom image size does not appear in the dropdown menu.

Even though I can understand why this happens from a server load / storage point of view, I feel the unexpected behaviour (to end users) is a bigger problem. An even prettier fix would be to detect the custom image size is identical to the original size and map the custom image size URL to the original file URL (e.g. through a symbolic link).

<?php
if ( function_exists( 'add_image_size' ) ) {
    add_image_size( 'project-photo', 1920, 1080, false);
}

function custom_media_sizes( $sizes ) {
    return array_merge( $sizes, array(
        'project-photo' => __( 'Project-foto' ),
    ) );
}
add_filter( 'image_size_names_choose', 'custom_media_sizes' );

Change History (25)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 years ago

#2 @afercia
5 years ago

  • Focuses accessibility removed

Discussed during today's accessibility bug-scrub: not sure this issue is related to accessibility, removing the accessibility focus for now.

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


19 months ago

#4 @antpb
19 months ago

  • Milestone changed from Awaiting Review to 6.2

This was mentioned in the Media component meeting and we were able to reproduce the report.

  • To reproduce add the provided snippet with the sizes attribute exactly matching an image available
  • Upload that image
  • Insert that image to a post and notice that the custom size is not available.
  • Upload any other image that is not the same size
  • Insert the second image into a post and notice the custom size _is_ available

We need to catch for the case of custom sizes matching the uploaded image and use the originally uploaded image for that custom size.

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


18 months ago

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


17 months ago

#7 @antpb
17 months ago

this is likely not to make it into the 6.2 milestone. This should move to 6.3 when possible.

#8 @sabernhardt
17 months ago

  • Milestone changed from 6.2 to 6.3

#9 @oglekler
13 months ago

  • Keywords needs-patch needs-screenshots added; 2nd-opinion removed

This ticket was mentioned in Slack in #core by mukeshpanchal27. View the logs.


13 months ago

#11 @oglekler
13 months ago

  • Keywords has-testing-info added

This ticket was discussed during the bug scrub. To help bring further feedback on the suggested paths forward, we agreed to add the has-testing-info keyword.

Additional props: @mukesh27 @costdev

#12 @azaozz
13 months ago

  • Keywords close added; needs-patch removed

When defining a custom image size using add_image_size and uploading an image that has exactly the same dimensions of that image size, the new image size is not added.

Yes, this is the expected behavior. The same thing happens when the uploaded image matches exactly one of the default sizes, for example "large". There's no point in having two image files with exactly the same size.

An even prettier fix would be to detect the custom image size is identical to the original size and map the custom image size URL to the original file URL.

Not sure about that. Having two "entries" for the same image file would be pretty confusing. Would also make it messier when generating the srcset for the image.

Imho this should be closed as worksforme. Plugins that depend on having specifically named image file sizes can add or replace the names that appear in the "Insert Image" drop-down.

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


13 months ago

#14 @joedolson
13 months ago

I think that what this needs for a user is to adjust the information in the insert image dropdown. There's no need to actually have the image or a symlink to it; it would be solved as easily if there was an option to insert that size that just inserted the other image.

What would make sense to me is to show the custom image size in the dropdown. I assume that right now this only shows up as the 'full' size - and the problem with that is that everything has a full size, and it doesn't tell you anything about what size the image actually is.

Where custom sizes can explicitly tell you what this image is, which is much more useful for the user.

I don't think we should change anything about the image upload behavior, but I can see justification for a change to the UX.

#15 @brampeerlings
13 months ago

As it has been quite a while since I reported this bug, I can't recall in what project it was, and in what issues / inconveniences this behaviour resulted.

I feel @joedolson makes a good point. Nevertheless, to then (as a user) be able to judge whether the 'full' image size is the right one to choose, would still require that user knowing (by heart) what the dimensions are of the custom image size (s)he's looking for ('project-photo' in this case). As such, I would feel that having an additional entry in the dropdown be beneficial. Or, alternatively, indicate the custom image size as 'synonym' for the 'full-size' entry? That would prevent from creating any srcset-issues @azaozz is referring to.

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


12 months ago

#17 @joedolson
12 months ago

  • Owner set to joedolson
  • Status changed from new to accepted
  • Type changed from defect (bug) to enhancement

Since we're not going to change any behavior, and only modify the UI for a smoother user experience in selecting the image they want, I'm shifting this to an enhancement. I still think it's plausible for 6.3, but we'll see.

#18 @joedolson
12 months ago

  • Keywords close removed
  • Milestone changed from 6.3 to 6.4

This is pretty entangled; I don't see an easy way of making the match between the dimensions of the full size image and the name of the custom image. Because this is going to take a bit more doing, I'm punting it to 6.4. We're too close to beta for this to happen in time.

#19 @joedolson
12 months ago

  • Keywords needs-patch added

#20 @oglekler
10 months ago

  • Focuses ui added

From the conversation, it isn't easy to grasp what is the problem. Possibly screenshots will not illustrate the issue and this ticket needs video recording of what is actually happening with UI.

comment:4 has an instruction to reproduct the bug.

#21 @joedolson
10 months ago

I'm not sure a video would be an effective way of conveying this; it's hard to show something not happening. But I think I can describe it fairly clearly.

1) When a custom image size has been declared, uploading a new image creates that size along with all other standard sizes.
2) If you upload an image that is the same size as a defined custom image size, the custom image size is not created.

This is a reasonable chain of events, but the end result is that the desired custom image size (e.g. "Post header image") is not available to be selected. You can still get that size, but you have to get it by selecting "Full", which is neither intuitive nor readily discoverable.

This ticket was mentioned in Slack in #core-media by joedolson. View the logs.


10 months ago

#23 @oglekler
9 months ago

  • Milestone changed from 6.4 to 6.5

There is no patch and no time before Beta 1 to finish and test it, so, I am moving this ticket into the 6.5 milestone.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


5 months ago

#25 @audrasjb
5 months ago

  • Milestone changed from 6.5 to Future Release

From today's bug scrub:
As this is an enhancement and since we’re still waiting for a patch, let’s move it to Future release milestone.
Happy to review and move it back to milestone 6.5 if a complete patch is proposed during the alpha cycle.

Note: See TracTickets for help on using tickets.