[wp-trac] [WordPress Trac] #42480: Consistent suppression of `getimagesize()` errors
WordPress Trac
noreply at wordpress.org
Thu Nov 9 00:13:52 UTC 2017
#42480: Consistent suppression of `getimagesize()` errors
-------------------------+--------------------------------------
Reporter: jeremyfelt | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Media | Version:
Severity: normal | Keywords: needs-patch dev-feedback
Focuses: |
-------------------------+--------------------------------------
In general, it seems common in the PHP world to suppress `getimagesize()`
errors because images and the software creating them can be flaky. The
function has a tendency to generate errors like `getimagesize(): corrupt
JPEG data: 7191 extraneous bytes before marker` even when it's able to
provide information that you're looking for.
We use `getimagesize()` 15 times in WP core. In 7 of these cases, we
suppress errors with `@getimagesize()`. By proxy, we usually suppress two
more of these cases by suppressing `@wp_read_image_metadata()` 3 out of 4
times.
Most uses of `getimagesize()` are to retrieve basic file information like
size. We do also use it in the ID3 library and in
`wp_read_image_metadata()` to retrieve IPTC data. It's strange enough
(IMO) that `getimagesize()` is the only PHP function that handles this,
but that's what we have.
I think there are probably two options:
* Suppress errors from `wp_read_image_metadata()` when used in
`wp_generate_attachment_metadata()`. This would align with the other uses
in core.
* Remove error suppression when calling `wp_read_image_metadata()` and
instead suppress errors on problematic internal PHP functions directly.
This *could* be safer as it would unmask other possible errors generated
in WordPress core code.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/42480>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list