HEIC upload conversion mappings may conflict with `image_editor_output_format` overrides

[ironprogrammer]

In testing #62359, I checked whether overriding the generated image type would be supported when the original upload is HEIC. Using the ​sample code from 6.5's AVIF support post, I felt it reasonable to expect a HEIC upload to result in AVIF files, but that was not the case.

This is due to the resulting output from the filter, which includes ​new default HEIC->JPEG mappings in 6.7. E.g. after applying the test filter, the output formats are:

{
 ["image/heic"]=> string(10) "image/jpeg"
 ["image/heif"]=> string(10) "image/jpeg"
 ["image/heic-sequence"]=> string(10) "image/jpeg"
 ["image/heif-sequence"]=> string(10) "image/jpeg"
 ["image/jpeg"]=> string(10) "image/avif"
}

Should WordPress reconcile the mappings for conversion before returning ​wp_get_image_editor_output_format()? Extenders (like in ​Modern Image Formats) could check this directly, but it seems WordPress should handle it for better consistency.

(I also want to note that a quick test of remapping each of the HEIC types to AVIF does result in alt-size generated files being .avif. However, the original HEIC converted file remains JPEG if under the big image size threshold, so this goes deeper than the filter to achieve consistency. In the case of oversized images, they result in -scaled.avif for the converted file, as expected.)

[peterwilsoncc]

@ironprogrammer I've moved this to an enhancement as I think it would be a nicety rather than essential.

My instinct is that it's best left for plugins to resolve to allow maximum flexibility and to avoid making assumptions. It's certainly worth discussing though as my instinct could be incorrect.

[azaozz]

Good catch, would be nice to add it. Setting for 6.8.

Perhaps there is a chance this may be needed earlier to account for existing conversion settings added from plugins. I.e. a plugin adding conversion from JPEG to WEBP would not just add a setting for the image/jpeg mime type, but for all supported formats (overriding the defaults in core):

array(
	'image/heic'          => 'image/webp',
	'image/heif'          => 'image/webp',
	'image/heic-sequence' => 'image/webp',
	'image/heif-sequence' => 'image/webp',
	'image/jpeg'          => 'image/webp',
);

May be a good idea to add this to the ​introductory post, or even publish a follow-up dev. note?

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

This PR addresses ticket #62365 by implementing proper support for chained image format conversions when handling HEIC uploads.

[audrasjb]

As per today's bug scrub: pinging @ironprogrammer for a quick review/testing on the proposed PR.

[adamsilverstein]

I checked whether overriding the generated image type would be supported when the original upload is HEIC. Using the sample code from 6.5's AVIF support post, I felt it reasonable to expect a HEIC upload to result in AVIF files, but that was not the case.

Thanks for the ticket.... however, I don't agree with the idea of chaining these transforms, I would rather update the documentation to make it clearer how to get the outputs you were expecting.

The original idea of the image_editor_output_format filter was to map upload mime type to output mime type. So while the default transform for HEIC images is now JPEG, it can readily be set to output AVIF instead. Adding a transform from JPEG to AVIF means "uploaded JPEGs will be output as AVIFs" - uploading a HEIC will still output as JPEG, unless you explicitly set the mapping to transform HEIC to AVIF.

My concerns with changing the filter behavior to "chain" output types include:

• Unexpected/breaking change - what if the user wants HEIC to output as JPEG and JPEG uploads to be output as WebP. Currently that is possible, after this change it would not be
• Circular chains - if the user somehow sets JPEG uploads to output as AVIF and AVIF uploads to output as JPEGs, what are the expected results?
• Unpredictable output - currently the mapping is predictable, with chaining developers would need to know what other transforms are present to know what the output would be for a given upload type.

Rather than altering the behavior of the filter, I suggest we update the original post introducing the filter (as well as the ​post about the HEIC conversion). to explicitly explain how to set AVIF as the output format for HEIC uploads. If that sounds good, I am happy to make those updates. What do you think @ironprogrammer?

[ironprogrammer]

Thanks for sharing your input, @adamsilverstein. You raise good points on being able to customize exactly which transforms occur. I agree that better documentation of what to expect with the filter would suffice in this case.

For instances where conversions differ from what might be expected (as in my example above), what are your thoughts on adding the final mappings to say the Media Handling accordion on the Site Health > Info page? Too much, or would this be helpful to know without needing to manually debug a site? (I'm thinking about users who may be seeing unexpected conversions here, not extenders who would know where/how to look.)

[adamsilverstein]

what are your thoughts on adding the final mappings to say the Media Handling accordion on the Site Health > Info page?

That seems reasonable, we already provide all kinds of technical details on that page and would certainly be helpful for users to understand/debug image upload/transforms.

Do you want to break out a separate ticket for that?

We can use this existing ticket to track the task of improving the documentation for the filter. I am changing the type to "bug" from enhancement so it clear we can keep working on it for 6.8. In addition to updating the blog posts, I'm going to try to improve the inline documentation (which winds up in the handbook) as well.

[ironprogrammer]

Sounds good. I've created #63047 for the proposed Site Health update. Thank you so much for taking on these docs updates!