[wp-trac] [WordPress Trac] #56442: Ensure `wp_editor_set_quality` filter consistently passes output mime type

[WordPress Trac]

#56442: Ensure `wp_editor_set_quality` filter consistently passes output mime type
-----------------------------+------------------------------------------
 Reporter:  adamsilverstein  |      Owner:  adamsilverstein
     Type:  defect (bug)     |     Status:  assigned
 Priority:  normal           |  Milestone:  6.1
Component:  Media            |    Version:  5.8
 Severity:  normal           |   Keywords:  needs-patch needs-unit-tests
  Focuses:                   |
-----------------------------+------------------------------------------
 In https://core.trac.wordpress.org/ticket/53667 we extended the capability
 of the `wp_editor_set_quality` filter so that the passed `mime_type`
 parameter could be used to set the default image quality ''per mime
 type''.

 Unfortunately, in my testing this filter doesn't quite work correctly: the
 output mime type (if set with the `image_editor_output_formats` filter) is
 not passed consistently to the filter.

 I used this
 [https://gist.github.com/adamsilverstein/262ec44a5cebe7ff8601b1e73301d07f
 code] in an mu plugin to test the adjusting just WebP output quality
 filter (and log the passed mime type) with a "real world" test: setting
 output quality either very high (100) or very low (1) for webp only and
 comparing the output file size. The filter worked for the `-scaled.webp`
 but not the rest of the sub-sizes.

 In addition to the filter not passing the correct mimes, we need to expand
 our testing in `test_set_quality_with_image_conversion` which continues to
 pass even though the filter isn't working correctly, possibly because it
 is only testing a single image generation call, or only testing the
 results of calling `get_quality` not the actual quality used.

 One test we could add would mimic what I am doing to test this manually:
 generate all subsizes with the filter in place - applying only to
 `image/webp` mime type images - returning first low quality, then high
 quality, -  calling `wp_create_image_subsizes` with no filter, then each
 option, then verifying the file sizes are all smaller with the lower
 quality applied and bigger (than default) with high quality applied.

 Note: I assume this is a bug that affected 5.8+ and have marked the ticket
 as such. I also verified this is still a bug in trunk.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56442>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform