[wp-trac] [WordPress Trac] #23102: Thumbnails and medium-sized images always show unconstrained dimensions in the Media panel size drop-down

[WordPress Trac]

#23102: Thumbnails and medium-sized images always show unconstrained dimensions in
the Media panel size drop-down
-----------------------------+--------------------------
 Reporter:  jond3r           |       Type:  defect (bug)
   Status:  new              |   Priority:  normal
Milestone:  Awaiting Review  |  Component:  Media
  Version:  3.5              |   Severity:  normal
 Keywords:  has-patch        |
-----------------------------+--------------------------
 ... though they can actually be constrained! This will not happen
 frequently, and might be resolved as a won't fix.

 However, as I was partly responsible for the code fix in #22738, which led
 to this defect, and it is a regression compared to 3.4, I thought I should
 report it. So here goes ... (For more context, you may have a look at the
 longer article I wrote about this on jond3r.org.)

 In [23096], the fix to #22738, thumbnails and medium-sized images were
 bypassed {{{image_constrain_size_for_editor()}}}, since it was thought
 that they were never constrained. However this can happen if the image
 size settings in the Media Settings administration panel have been
 decreased between upload and use of the images. If this is the case,
 {{{image_constrain_size_for_editor()}}} will constrain all the standard
 image sizes to those values that currently are in effect (through the
 Media Settings panel), which thus also will affect thumbnails and medium-
 sized images.

 To reproduce:
 Upload an image large enough for medium size to be created using the
 default medium size settings in the Media Settings panel (300px). Decrease
 the setting to 200px. Mark the previously uploaded image for insertion in
 the Insert Media panel. Choose medium size and look at the displayed
 dimension (300px). Insert the image and observe how the dimension has been
 decreased to 200px (through the width and/or height attributes). Thus the
 inserted image is constrained, even though it is not shown in the size
 drop-down.

 The fix is simply to pass all image sizes (except Full) through
 {{{image_constrain_size_for_editor()}}} as the provided patch shows.

 Performance worries have been put forward (#22598) calling
 {{{image_downsize()}}} repeatedly for many images. #22738 showed that it
 was enough to call {{{image_constrain_size_for_editor()}}}, which
 apparently is faster. The proposed fix implies that all processed
 thumbnails and medium-sized images will have to go through
 {{{image_constrain_size_for_editor()}}}, which leads to some increased
 execution time.

 To quantify this I did some timing tests. The code used for the tests are
 shown in the file {{{timing_code.diff}}}, and the test results are shown
 in {{{timing_dump.txt}}}. The absolute execution times obtained are not
 that interesting, as they depend on the execution environment, which in
 this case is a few years old Windows desktop. In a production environment,
 considerably faster execution time is probable.

 The results show an average execution time of 0.439 ms per image calling
 {{{image_constrain_size_for_editor()}}}, which multiplied by 80 for a full
 page of images, yields ca 35 ms in increased execution time, compared to
 the code in 3.5.0. This would hardly be noticeable, and is probably
 acceptable.

 Out of curiosity I also tested to call {{{image_downsize()}}}, which was
 used in 3.4. A call to {{{image_downsize()}}} took on average 9.78 ms per
 image, which yields 782 ms for a full page, which is not that easy to
 ignore. Note that {{{image_downsize()}}} fetches the attachment meta data,
 which can be costly if the data is not cached, but as far as I can see
 that is the case, since the meta data is fetched earlier in the function
 {{{wp_prepare_attachment_for_js()}}}. Nevertheless a call to
 {{{image_downsize()}}} is 22 times more costly than a call to
 {{{image_constrain_size_for_editor()}}}, which gives some credit to the
 worry put forward in #22598, and to the solution proposed in #22738.

 Criticism is welcome, especially of the performance tests.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/23102>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software