#28077 - Use exif_imagetype() in file_is_displayable_image() - #14856

Summary

file_is_displayable_image() only needs the image type, but it obtains it from wp_getimagesize(), which parses the image header far enough to determine the width and height before returning the type at index 2. Reading the type from the file signature is sufficient for this check and avoids that parsing.

The function is a gate rather than a measurement: its only caller, wp_generate_attachment_metadata(), uses it to decide whether the attachment is a displayable image at all, and wp_create_image_subsizes() measures the image afterwards.

What this changes

exif_imagetype() reads the same header bytes as getimagesize() but stops after matching the signature, and it returns the same IMAGETYPE_* constant that getimagesize() returns at index 2. It is used when available:

if ( is_callable( 'exif_imagetype' ) ) {
	// Don't silence errors when in debug mode, unless running unit tests.
	if ( defined( 'WP_DEBUG' ) && WP_DEBUG && ! defined( 'WP_RUN_CORE_TESTS' ) ) {
		$image_type = exif_imagetype( $path );
	} else {
		$image_type = @exif_imagetype( $path );
	}
} else {
	$info       = wp_getimagesize( $path );
	$image_type = ! empty( $info ) ? $info[2] : false;
}

Three details:

The exif extension is optional, so the existing wp_getimagesize() behaviour is retained as a fallback, as comment #1 asks. The fallback goes through the wrapper rather than bare getimagesize(), so the WebP, AVIF and HEIC handling added to that wrapper still applies when exif is unavailable.

Error suppression is still needed. Comment #2 suggests exif_imagetype() only emits a notice, so the @ could be dropped. On current PHP it raises E_WARNING for a path that does not exist, and E_NOTICE for an empty file or for a directory, so dropping the suppression would introduce new warnings. The conditional pattern above is copied from wp_get_image_mime(), which already wraps exif_imagetype() this way.

The result stays a strict boolean, because the filter documents $result as a bool.

Behaviour change

The check is now based on the signature rather than on a successfully parsed header. A file whose signature is valid but whose remaining header data cannot be parsed is treated as displayable, where previously it was rejected here.

In practice the file still fails later: wp_create_image_subsizes() calls wp_get_image_editor(), which returns WP_Error: File is not an image. for such a file. Nothing is generated either way, but the rejection now happens downstream. A test covers this so the trade-off is explicit.

The two approaches were compared across all 56 image fixtures plus synthetic non-image, empty, nonexistent and truncated-file cases, and the results are identical apart from that one case. Type constants agree on every format, including AVIF, WebP, ICO, HEIC and TIFF.

Tests

tests/phpunit/tests/image/functions.php adds coverage for the result matching the previous answer on regular images and non-images, a strict boolean reaching the filter, a nonexistent path, the filter's return value being passed through, and a valid signature being accepted when the rest of the header cannot be parsed.

The signature test fails when the source change is reverted, which is the expected red state; the parity tests pass in both states by design, since they assert that existing behaviour is preserved.

Trac ticket: https://core.trac.wordpress.org/ticket/28077

Use of AI Tools

AI assistance: Yes
Tool(s): Claude
Model(s): Sonnet
Used for: test cases, code review

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.