Related to #372, not all sizes should for sure have WebP / additional MIME type versions available. In addition to the checks from #372, developers should have control over which image sizes to generate additional MIME type versions for.
As outlined in https://make.wordpress.org/core/2022/06/30/plan-for-adding-webp-multiple-mime-support-for-images/, this should behave as follows eventually:
- There should be a filter like
wp_image_sizes_with_additional_mime_type_support, that filters the array/list of image sizes that should receive additional MIME types.
- WP core's
add_image_size() function should receive an additional optional parameter e.g. $provide_additional_mime_types which will be false by default.
- The above filter will rely on that new image size registration value for its default / filter input.
- The WP core sizes will have this value set to
true so that they are enabled by default. Custom sizes will have to opt in if they are used in the frontend, or opt out if there are used in special scenarios where additional MIME types are irrelevant or not supported (e.g. Open Graph tags).
For the plugin, we shouldn't bother updating the add_image_size() function since we can't modify it from there. So the plugin implementation should be mostly focused on the filter:
- Implement a function like
webp_uploads_get_image_sizes_with_additional_mime_type_support().
- Hard-code an array of the default core sizes
thumbnail, medium, medium_large, large, post-thumbnail.
- Call
wp_get_additional_image_sizes() add check for each image size in there whether it has a key provide_additional_mime_types set, with a truthy value. If so, include the size in the array.
- Run the array through a new
webp_uploads_image_sizes_with_additional_mime_type_support filter and then return it.
- In the code where additional MIME types are generated for the different image sizes, call the new function. Then ensure that only the sizes which are also in this list are covered with generating additional MIME type versions.
Related to #372, not all sizes should for sure have WebP / additional MIME type versions available. In addition to the checks from #372, developers should have control over which image sizes to generate additional MIME type versions for.
As outlined in https://make.wordpress.org/core/2022/06/30/plan-for-adding-webp-multiple-mime-support-for-images/, this should behave as follows eventually:
wp_image_sizes_with_additional_mime_type_support, that filters the array/list of image sizes that should receive additional MIME types.add_image_size()function should receive an additional optional parameter e.g.$provide_additional_mime_typeswhich will befalseby default.trueso that they are enabled by default. Custom sizes will have to opt in if they are used in the frontend, or opt out if there are used in special scenarios where additional MIME types are irrelevant or not supported (e.g. Open Graph tags).For the plugin, we shouldn't bother updating the
add_image_size()function since we can't modify it from there. So the plugin implementation should be mostly focused on the filter:webp_uploads_get_image_sizes_with_additional_mime_type_support().thumbnail,medium,medium_large,large,post-thumbnail.wp_get_additional_image_sizes()add check for each image size in there whether it has a keyprovide_additional_mime_typesset, with a truthy value. If so, include the size in the array.webp_uploads_image_sizes_with_additional_mime_type_supportfilter and then return it.