Remove PHP capability-block from uploading webp and avif

[Cybr]

Currently, WordPress wants the server to support editing of the image file types .webp and .avif before allowing them to be uploaded.

This happens in media_upload_form().

// Check if WebP images can be edited.
if ( ! wp_image_editor_supports( array( 'mime_type' => 'image/webp' ) ) ) {
        $plupload_init['webp_upload_error'] = true;
}

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

Then, at handler.js, under a deprecated jQuery.ready() call, the errors are considered, and the entire upload is blocked.

} else if ( file.type === 'image/webp' && up.settings.webp_upload_error ) {
        // Disallow uploading of WebP images if the server cannot edit them.
        wpQueueError( pluploadL10n.noneditable_image );
        up.removeFile( file );
        return;
} else if ( file.type === 'image/avif' && up.settings.avif_upload_error ) {
        // Disallow uploading of AVIF images if the server cannot edit them.
        wpQueueError( pluploadL10n.noneditable_image );
        up.removeFile( file );
        return;
}

Since images can still be served without editing them, this block should only be considered when actually editing the image.

[dd32]

What about thumbnail generation? I assume that's why it's currently blocking on upload.

[Cybr]

For the thumbnails, we could either show the original file or ​show a placeholder.

We could even set a flag when the editor isn't present and clear that flag when support is found again during an upgrade cycle -- whereafter we could generate the thumbnails.

[swissspidy]

Just using full size images without any thumbnails is a bad idea performance wise.

[adamsilverstein]

Since images can still be served without editing them, this block should only be considered when actually editing the image.

While this is technically true, users won't benefit from the subsizes and srcset WordPress automatically generates and - as @swissspidy points out - will suffer from the performance implications of always serving the original image. For most users uploading and using the original image is probably not best practice.

That said, I can see a use case for it for some users, so it should be possible to bypass these checks as a developer or with a plugin. Looking at the code you referenced in media_upload_form, you should be able to use the 'plupload_init' filter.

Something like this (untested) code:

add_filter( 'plupload_init', function( $plupload_init ) {
    unset( $plupload_init[ 'avif_upload_error' ] );
    return $plupload_init;
} );

@Cybr can you test this code snippet and see if that resolves the issue for you?

[joemcgill]

For environments that intentionally offload thumbnail generation, we could potentially only included the edit check if there are intermediate sizes defined.

[Cybr]

It slipped my mind that WordPress creates subsizes of images for srcsets. Sorry about that!
With that, yes, it now makes sense to me that uploading is blocked when editing isn't possible.

Should we add a more descriptive error message to alleviate tickets/support questions like mine?

The filter @adamsilverstein provided in comment:4 could be used by plugins that offload thumbnail generation.

[adamsilverstein]

Should we add a more descriptive error message to alleviate tickets/support questions like mine?

Probably, although it would have to be simple enough that most users could make sense of it.

[adamsilverstein]

Note we have ​this ticket open to block uploading of non supported types in Gutenberg.

Also noting that I have discovered some cases where AVIF support is not properly detected. This ​PR aims to address that issue

Prevents a false positive for AVIF format support when IMG_AVIF is defined, but the imageavif function is not. See ​https://github.com/php/php-src/issues/12019

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

[adamsilverstein]

Should we add a more descriptive error message to alleviate tickets/support questions like mine?

Good idea. I think we can address this in ​https://github.com/WordPress/gutenberg/issues/25130 for Gutenberg uploads. For core, I don't think we have a ticket yet to improve upload error messages, do you want to create one @Cybr?

I'm gong to close out this ticket for now as 'worksforme' since I think the original reported behavior is expected.

Fixed in https://core.trac.wordpress.org/changeset/58305

[Cybr]

For core, I don't think we have a ticket yet to improve upload error messages, do you want to create one @Cybr?

Here it is: #61361.