PHP 8.5: HEIF/HEIC support added to `getimagesize()`

[desrosj]

Parent ticket for all things PHP 8.5: #63061.

PHP 8.5 added support for the HEIF/HEIC image format (​relevant commit).

A version of Imagick was released with PHP 8.5 support, so it was ​recently added to the WPDev Docker images.

As a result, Tests_Functions::test_wp_getimagesize_heic() is now failing.

Trac ticket: Core-64322

The test update looks good here, thanks @desrosj! I didn't realize PHP was adding HEIC/F support, we probably need to update some of the ​core handling of these uploads as well.

Looks good with the changes to the constant name suggested above.

... need to update some of the ​core handling of these uploads as well.

Actually existing core handling works fine: when getimagesize works correctly with heic/f images, wp_getimagesize returns early with the correct information (as the test demonstrates).

I considered whether we should preserve the IMAGETYPE_HEIC constant, but a search of the (outdated) plugin directory showed 0 occurrences of that constant. So I don't think it's worth it.

[desrosj]

In 61328:

Media: Adjustments for official HEIF/HEIC support in added in PHP 8.5.

Now that a version of imagick with support for PHP 8.5 has been released and the containers maintained by the project for the local development environemnt have been updated to include it, there are some new PHP 8.5 compatibility issues that have surfaced related to HEIF/HEIC image format.

PHP 8.5 added support for the HEIF/HEIC image format in getimagesize(). To properly support this in a cross-version way, a few changes are necessary.

Since [58849], WordPress has supported this format and the IMAGETYPE_HEIC constant was introduced as a placeholder until proper support was added in PHP. Since that has now happened, this constant needs to be changed to contain a value of 20 instead of 99, and the name upstream was added as IMAGETYPE_HEIF. The constant in Core is being changed to match those included in PHP.

The implementation for this image format in getimagesize() also follows a similar pattern to that of AVIF where additional information such as the image bits and channels are also returned. This additional information is causing unit tests to fail. The tests have been updated to account for different versions of PHP returning a different level of detail.

Props westonruter, skithund, johnbillion, adamsilverstein.
Fixes #64322.

[desrosj]

Reopening for backport consideration of [61328].

[ellatrix]

How come this issue only popped up now? What happens if 6.9 doesn't include this change? Are there more things that could pop up? I read through the ticket/PR but I don't have a lot of context sorry.

[desrosj]

Replying to ellatrix:

How come this issue only popped up now?

This failure was caused by the change to the PHP Docker containers (that the PHPUnit tests run inside of and we we maintain) on November 29, that ​updated the 8.5 image to use PHP 8.5.0 instead of PHP 8.5.0RC5, and the Imagick extension was added.

This meant that any new PHPUnit Test workflow that ran from that point forward would run with the new containers. I am not sure why this surfaced in 8.5.0 GA and not in 8.5.0 RC5. But this change to the upstream containers caused it for some reason.

What happens if 6.9 doesn't include this change?

If this is not merged into 6.9, then the unit tests will continue to fail. But I don't think there will be any noticeable impact otherwise because getimagesize() will just return the image size data, just with more than expected. Though I think it's preferable to include because it ensures the image type constant is consistent with the one added to PHP core for the release.

Are there more things that could pop up?

It's possible, but I think the risk is very minimal. I searched the plugin directory, and while that site is a bit out of date, there ​was not one reference to the constant being changed in [61328].

The scenario where someone may encounter an issue is if code is explicitly checking for the previous value of 99. Something like this:

$image_size = wp_getimagesize( $filename );

if ( '99' == $image_size[2] ) {
// Do something HEIF/HEIC related.
}

I searched for usage of wp_getimagesize() and ​found 91 results. But none of those results are performing any logic checks using IMAGETYPE_HEIC or IMAGETYPE_HEIF.

[SergeyBiryukov]

In 61334:

Media: Adjustments for official HEIF/HEIC support in added in PHP 8.5.

Now that a version of imagick with support for PHP 8.5 has been released and the containers maintained by the project for the local development environemnt have been updated to include it, there are some new PHP 8.5 compatibility issues that have surfaced related to HEIF/HEIC image format.

PHP 8.5 added support for the HEIF/HEIC image format in getimagesize(). To properly support this in a cross-version way, a few changes are necessary.

Since [58849], WordPress has supported this format and the IMAGETYPE_HEIC constant was introduced as a placeholder until proper support was added in PHP. Since that has now happened, this constant needs to be changed to contain a value of 20 instead of 99, and the name upstream was added as IMAGETYPE_HEIF. The constant in Core is being changed to match those included in PHP.

The implementation for this image format in getimagesize() also follows a similar pattern to that of AVIF where additional information such as the image bits and channels are also returned. This additional information is causing unit tests to fail. The tests have been updated to account for different versions of PHP returning a different level of detail.

Follow-up to [58849].

Reviewed by desrosj, SergeyBiryukov.
Merges [61328] to the 6.9 branch.

Props westonruter, skithund, johnbillion, adamsilverstein.
Fixes #64322.

[ellatrix]

Thanks for the info @desrosj!