Make WordPress Core

Opened 5 years ago

Last modified 3 years ago

#49161 new defect (bug)

Disabling big_image_size_threshold via filters does NOT work

Reported by: bbtodd's profile bbtodd Owned by:
Milestone: Awaiting Review Priority: normal
Severity: major Version:
Component: Media Keywords:
Focuses: Cc:

Description

Trying to disable the new image sizes in WordPress but this has no effect! I'm still seeing the new large sizes being saved on my server even after using this code.

add_filter( 'big_image_size_threshold', '__return_false' );

This is a very serious issue for me. My site accepts user uploads but I've been overwriting the full size images with the thumbnail not just to save space on server but also so that I don't have large images stored on my server in case of possible copyright abuse.

This should have been a feature you need to turn on, not something that automatically happened after a site is auto upgraded. I absolutely need this disabled but the ability to disable this is NOT working.

Change History (6)

#1 @SergeyBiryukov
5 years ago

  • Component changed from General to Media

#2 @bbtodd
5 years ago

I don't see a place where suggestions can be put forth but I very much dislike this 'big_image_size_threshold' function and how it was put out. But if adding these very large image sizes is something that is decided really is necessary, the ability to turn these sizes on and off and or edit the exact dimensions should be an option available in settings > media - just like the other default image sizes.

#3 @bbtodd
5 years ago

March 2020 - WP is still creating large size images on server 😠
I have to manually scan via FTP on a regular basis to find and delete any offending images.

#4 follow-up: @sjnbham
5 years ago

We use Smush for our image optimization. It provides a method to reduce the image size already. The documented method to disable this feature isn't working for us either.

add_filter( 'big_image_size_threshold', '__return_false' );
Last edited 5 years ago by peterwilsoncc (previous) (diff)

#5 in reply to: ↑ 4 @bbtodd
5 years ago

Replying to sjnbham:

We use Smush for our image optimization. It provides a method to reduce the image size already. The documented method to disable this feature isn't working for us either.

Thank you, I was starting to consider writing my own code to detect/delete oversized images, so I'll check this out.

#6 @kitchin
3 years ago

@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.
  1. When big_image_size_threshold is on, error checks are incomplete in the code, marked // TODO: Log errors.
  1. On failures of the image editor engine, big threshold and exif rotations (handled in the same function) fail silently, leaving the image sizing and naming data unchanged, if the visit hasn't timed out or crashed.
  1. 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.

Version 2, edited 3 years ago by kitchin (previous) (next) (diff)
Note: See TracTickets for help on using tickets.