[wp-trac] [WordPress Trac] #49161: Disabling big_image_size_threshold via filters does NOT work

[WordPress Trac]

#49161: Disabling big_image_size_threshold via filters does NOT work
--------------------------+------------------------------
 Reporter:  bbtodd        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Media         |     Version:
 Severity:  major         |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by kitchin):

 @bbtodd The bug as reported is invalid, `big_image_size_threshold` false
 means do not save a reduced image at the threshold size.

 @sjnbham The `wp_smush` plugin overrides `big_image_size_threshold` with a
 filter.

 The filter is working as designed on my tested site, but note the intent
 of `big_image_size_threshold` is to save ''bandwidth'' not ''disk space.''
 The original image **is still saved** when `big_image_size_threshold` is
 nonzero (the default), and its short filename is put into the metadata as
 "original_image." The "-scaled" version of the image though is the one
 used by WP when you ask for the image while editing pages, etc. There's a
 link to the original file in the Dashboard / Media view of the image, in
 the metabox.

 For whatever reason it was designed this way, adding another layer of meta
 complexity to the already somewhat complex situation, such as very old
 legacy images having different metadata than those even before this
 feature was added. But that's just a meta issue, the design question is
 whether the original image should be saved at all. The decision was made,
 and any further work will add onto, not replace, this feature and filter,
 I'd wager.

 Also to consider when debugging:

 1. There are three possible image editor engines in WP Core. My tested
 site used `WP_Image_Editor_Imagick`, for jpeg.

 2. When `big_image_size_threshold` is on, error checks are incomplete in
 the code, marked `// TODO: Log errors.`

 3. This feature copies a big image to fairly big image, so creates
 probably the weakest point in the code for memory usage and processing
 timeouts, if they occur.

 I tested on the latest release, 5.8.1. The most relevant file, `wp-
 admin/includes/image.php` is the same in trunk.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/49161#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform