Multi-file Uploader Triggers AVIF Upload Error Despite GD Support – WP_Image_Editor_Imagick Interference

[CyberCr33p]

Environment:

• WordPress Version: [e.g., 6.7.2]
• PHP Version: [e.g., 8.3.19]
• Operating System: [FreeBSD]
• GD extension: Compiled with AVIF support (IMG_AVIF defined and supported)
• Imagick extension: Not built/installed

Description:

When uploading AVIF images via the multi-file uploader (plupload), WordPress rejects them with the error message:

“This image cannot be processed by the web server. Convert it to JPEG or PNG before uploading.”

Despite testing and confirming that GD fully supports AVIF (using a standalone PHP script, which shows that both imageavif() exists and imagetypes() includes the IMG_AVIF flag), the multi-file uploader still triggers the error. The underlying check in wp-includes/media.php is:

// Check if AVIF images can be edited.
if ( ! wp_image_editor_supports( array( 'mime_type' => 'image/avif' ) ) ) {
    $defaults['avif_upload_error'] = true;
}

It appears that WordPress is selecting the WP_Image_Editor_Imagick class from the default array:

$implementations = apply_filters( 'wp_image_editors', array( 'WP_Image_Editor_Imagick', 'WP_Image_Editor_GD' ) );

Even though Imagick isn’t actually built with PHP, its class is still present and is chosen over GD. This causes the AVIF support check to fail and the upload error to be triggered.

Steps to Reproduce:

1. Set up a WordPress environment where the PHP GD extension is compiled with AVIF support.
2. Ensure that the Imagick extension is not installed.
3. Attempt to upload an AVIF image using the multi-file uploader via the Media Library.
4. Observe that the upload fails with the message: “This image cannot be processed by the web server. Convert it to JPEG or PNG before uploading.”

Expected Behavior:

WordPress should detect that GD supports AVIF images and select WP_Image_Editor_GD for image processing. The AVIF support check (using wp_image_editor_supports( array( 'mime_type' => 'image/avif' ) )) should return true, allowing AVIF images to be processed without error.

Actual Behavior:

The AVIF support check returns false because WordPress selects WP_Image_Editor_Imagick, which is not supported in my environment. Removing WP_Image_Editor_Imagick from the available editors (via the wp_image_editors filter) resolves the issue, indicating that the root cause is the editor selection process:

add_filter( 'wp_image_editors', function( $editors ) {
    return array( 'WP_Image_Editor_GD' );
});

Conclusion:

It appears that WordPress incorrectly prioritizes WP_Image_Editor_Imagick for AVIF processing during multi-file uploads, even though GD is correctly reported as the active image editor in "Site Health." This leads to a false negative in the AVIF support check and prevents AVIF images from being processed.

[CyberCr33p]

In the end, the problem was due to Redis caching the result of the image editor selection. The call:

wp_cache_set( 'wp_image_editor_choose', $editors, 'image_editor', DAY_IN_SECONDS );

had stored WP_Image_Editor_Imagick in the cache. Once I flushed the Redis cache, WordPress re-evaluated the selection and cached WP_Image_Editor_GD instead.