WordPress Trac: Ticket #44801: `image_constrain_size_for_editor()` forcing the `$content_width` messes up dimensions http://core.trac.wordpress.org/ticket/44801 <p> The <code>image_constrain_size_for_editor()</code> currently looks at the <code>$content_width</code> global that themes may define. For <code>medium_large</code>, <code>large</code> and any custom image sizes, the actual image size's width will be evaluated against the <code>$content_width</code>, and the minimum will be used. </p> <p> This results in the following (example): </p> <ul><li>Let's say <code>$content_width</code> is 640. </li><li>Let's say your <code>large</code> image size constraints are 1280x1280. </li><li>Let's say your image in <code>large</code> size is 1280x960. </li><li>Instead of using the image size width (1280), it will use the <code>$content_width</code> since it's smaller (640), resulting in 640x480 being used for the dimension of the image in <code>large</code> size. </li></ul><p> This makes sense for the default behavior, but that computed size is used in many different areas, including <code>wp_prepare_attachment_for_js()</code>, where the <code>sizes</code> property then would show something like this for the <code>large</code> size (continuing the above example): </p> <p> <code></code>`js { width: 640, height: 480, url: '.../my-image-1280x960.jpg', orientation: 'landscape' } <code></code>` </p> <p> 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 <code>@media (max-width: 1280px) ...</code> for the image, but it would generate <code>@media (max-width: 640px) ...</code> due to the changed size. </p> <p> As I already said, the <code>$content_width</code> 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 <code>editor_max_image_size</code> which is perfect for that), so that someone could temporarily unhook that behavior for custom use-cases. </p> en-us WordPress Trac http://core.trac.wordpress.org/chrome/site/your_project_logo.png http://core.trac.wordpress.org/ticket/44801 Trac 1.2.2 flixos90 Wed, 15 Aug 2018 09:49:04 GMT attachment set http://core.trac.wordpress.org/ticket/44801 http://core.trac.wordpress.org/ticket/44801 <ul> <li><strong>attachment</strong> set to <em>44801.diff</em> </li> </ul> Ticket flixos90 Wed, 15 Aug 2018 09:53:47 GMT keywords changed http://core.trac.wordpress.org/ticket/44801#comment:1 http://core.trac.wordpress.org/ticket/44801#comment:1 <ul> <li><strong>keywords</strong> <em>has-patch</em> added; <em>needs-patch</em> removed </li> </ul> <p> <a class="attachment" href="http://core.trac.wordpress.org/attachment/ticket/44801/44801.diff" title="Attachment '44801.diff' in Ticket #44801">44801.diff</a><a class="trac-rawlink" href="http://core.trac.wordpress.org/raw-attachment/ticket/44801/44801.diff" title="Download">​</a> addresses the problem as follows: </p> <ul><li>Introduce a filter function <code>wp_constrain_editor_max_image_size_to_content_width()</code> for <code>editor_max_image_size</code>. </li><li>Outsource all <code>$content_width</code>-related bits from <code>image_constrain_size_for_editor()</code> to that filter function. </li><li>Hook the filter in with priority 0 in <code>default-filters.php</code>. </li><li>Clean up the <code>image_constrain_size_for_editor()</code> function's tons of if-clauses a bit to use strict comparisons and less repetitive code for the same thing. </li></ul><p> Functionality-wise, this doesn't change anything, I preserved the exact same behavior as is in place currently. However, by having that part being a filter, it can be unhooked to skip it. As a nice side-effect, the very specific <code>$content_width</code> global is no longer used as part of <code>image_constrain_size_for_editor()</code>. </p> Ticket joemcgill Mon, 15 Apr 2019 21:58:52 GMT milestone changed http://core.trac.wordpress.org/ticket/44801#comment:2 http://core.trac.wordpress.org/ticket/44801#comment:2 <ul> <li><strong>milestone</strong> changed from <em>Awaiting Review</em> to <em>Future Release</em> </li> </ul> <p> Hi @flixos90, this seems related to and possibly a duplicate of <a class="accepted ticket" href="http://core.trac.wordpress.org/ticket/35390" title="#35390: defect (bug): image_constrain_size_for_editor() should not affect images generated ... (accepted)">#35390</a>. Moving this functionality to a filter could help people work around problems with <code>$content_width</code> but I'm unsure if we need to maintain that behavior now that we've moved to the new block editor, which includes the possibility of image widths that extend outside the traditional content area (i.e. align-wide and align-full). </p> Ticket