Custom image size not generated if identical to original size

[brampeerlings]

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' );

[afercia]

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

[antpb]

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.

[antpb]

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

[oglekler]

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

[azaozz]

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.

[joedolson]

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.

[brampeerlings]

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.

[joedolson]

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.

[joedolson]

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.

[oglekler]

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.

[joedolson]

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.

[oglekler]

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.

[audrasjb]

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.