Big image size threshold should take into account registered image sizes.

[johnbillion]

The "big image" upper size threshold is set to 2560. If an image size is registered that has a width or height larger than this, then the image will be unexpectedly cropped to 2560.

The value that gets passed through to the big_image_size_threshold filter should be set to the maximum value of either 2560 or the largest width or height from all registered image sizes.

[psrpinto]

I submitted a patch which implements the solution suggested in the ticket description:

The value that gets passed through to the big_image_size_threshold filter should be set to the maximum value of either 2560 or the largest width or height from all registered image sizes.

However, I noticed that many of the default themes (e.g. twentytwentyone, twentytwenty, twentynineteen) set the post_thumbnail_size's height to 9999, which results in the threshold now being 9999.

This means the majority of pictures will not be cropped, and I'm not sure that was the intention behind the proposed solution.

Do you think such a high threshold makes sense @johnbillion?

[adamsilverstein]

However, I noticed that many of the default themes (e.g. twentytwentyone, twentytwenty, twentynineteen) set the post_thumbnail_size's height to 9999, which results in the threshold now being 9999.

@psrpinto Do we know why these themes use that value? I assume the goal is to crop only the horizontal dimension? is there another way to achieve that?

or maybe we can separate out the width/height treatment, or treat 9999 as a special case?

[a4jp.com]

I never knew that all images had a maximum size of 2560 when getting cropped T-T. This should be explained in /wp-admin/options-media.php if it's a set limit we can't change.

Would it make sense to allow a blank field to work if we don't want the height cropped instead of having to type 9999? I'd rather leave the field empty with nothing in it if I didn't want anything cropped instead of typing in a weird number like 9999. 9999 should crop at 9999 if images that big exist though (codewise).

[f26d]

The 9999 height hack for the post-thumbnail size does complicate things… I think it makes sense to loop over just the widths of the image sizes to potentially bump up $threshold.

There doesn't seem to be a perfect solution to this, but in general (*waves hand*), it seems more common to resize images based on a width constraint than based on a height constraint. This makes me think that plenty of custom image sizes are likely to use identical width and height (or something like 9999 for the height, so that the height argument is essentially disregarded).

I've updated @psrpinto's diff with this suggested approach, as well as with some unit tests.

This is my first contribution to core, so please let me know if I'm missing something!