id summary reporter owner description type status priority milestone component version severity resolution keywords cc focuses 44801 `image_constrain_size_for_editor()` forcing the `$content_width` messes up dimensions flixos90 "The `image_constrain_size_for_editor()` currently looks at the `$content_width` global that themes may define. For `medium_large`, `large` and any custom image sizes, the actual image size's width will be evaluated against the `$content_width`, and the minimum will be used. This results in the following (example): * Let's say `$content_width` is 640. * Let's say your `large` image size constraints are 1280x1280. * Let's say your image in `large` size is 1280x960. * Instead of using the image size width (1280), it will use the `$content_width` since it's smaller (640), resulting in 640x480 being used for the dimension of the image in `large` size. This makes sense for the default behavior, but that computed size is used in many different areas, including `wp_prepare_attachment_for_js()`, where the `sizes` property then would show something like this for the `large` size (continuing the above example): ```js { width: 640, height: 480, url: '.../my-image-1280x960.jpg', orientation: 'landscape' } ``` Regarding what I want to accomplish with the custom image sizes, this results in unexpected behavior. For example in my case, I was looking into dynamically generating media queries for a background image, using the sizes. I was expecting for my code to generate `@media (max-width: 1280px) ...` for the image, but it would generate `@media (max-width: 640px) ...` due to the changed size. As I already said, the `$content_width` global makes sense to take into account by default. However, it is currently hardcoded into the function. I think it should be moved into a filter (we already have `editor_max_image_size` which is perfect for that), so that someone could temporarily unhook that behavior for custom use-cases." defect (bug) new normal Future Release Media normal needs-unit-tests has-patch