When uploading, generate both WebP and jpeg format images by default

[adamsilverstein]

Feature Description

Based on the decision in #96 (comment) we need to work on enabling generating both formats by default.

Specifically we need to address:

1. When the user uploads a JPEG image, we generate the smaller image sizes in both JPEG and WebP by default.
2. When inserting an image into a post or including an image in the frontend through any other means, we use the WebP version whenever it is available.
3. Developers can opt out of generating JPEG or WebP, e.g. if they are certain they won't need one of these versions.

---

1. Generate both formats

• We can hook on wp_generate_attachment_metadata to generate the additional mime type images (some example code from @erikyo).
• If the user uploads a jpeg and generates jpeg sub sizes, we would hook in and also generate WebP sizes. If the user uploads a WebP core will generate WebP sub sizes, we would hook in and generate jpeg sub sizes
• The behavior should be filterable, I propose a new filter named image_editor_output_formats which would return an array of mime types. By default this would return ['image/webp', 'image/jpeg'].
  • The first/default mime type would be used for the default sub-sizes generated by default and stored in the sizes array (If only one mime type is given, only that type is generated).
  • When more than one mime type is returned, the second and subsequent types are used to generate additional sub sizes and their data stored in the additional_sizes array...

1b. In addition to generating the new images, we also need to store meta data for new mime type sizes

• for backwards compatibility reasons, I suggest we store a single mime type in the sizes array
• additional mime type sizes we generate should be stored separately, in a key I propose naming additional_sizes
• mime type data will go into a sources array inside each size
• additional handling will be required for these additional sizes:
  • when the original image is deleted, these sub sizes should also be deleted
  • when missing sub sizes are regenerated, this should include all mime types
  • when the image is cropped/rotated/flipped in the media library, the action should apply to these images as well
  • eventually, functions should be extended or added that leverage these new sizes to generate a picture element

2. Use WebP on front end

• This can be achieved by having the default sizes sub sizes be WebP by default, which will be the case with ['image/webp', 'image/jpeg'] as the default value for image_editor_output_formats
• We should also consider adding a mime type argument or a filter for functions like get_image_tag or wp_get_attachment_image_src as a more direct way for developers to specify the mime type they want to use.

3. Developers can opt out

• Adding add_filter( 'image_editor_output_formats', '__return_false' ); would ensure only the uploaded mime type would be use for sub sizes (current WordPress behavior).
• Adding add_filter( 'image_editor_output_formats', function() { return array( 'image/jpeg', 'image/webp' ); } ); would ensure jpeg and WebP were generated, with jpeg stored in sizes and used as the default output format
• Adding add_filter( 'image_editor_output_formats', function() { return array( 'image/webp' ); } ); would ensure only WebP sub sizes were generated (current behavior of the webp-uploads module).
• The filter will reference the original image for context, so output formats could be dynamic

Feedback welcome as well as contributions, please let us know what you plan to work on by leaving a comment.

[adamsilverstein]

One important note here: based on #75 (comment) we need to ensure that both the image src and srcset use the mime type we want to display to ensure that mime type is actually loaded (in some cases, the browser might load the src image). this suggests the possibility of a filter on the output side as well.

[adamsilverstein]

I'm going to work on a PR for the generating images part.

[adamsilverstein]

Good suggestion from @nosilver4u on slack:
we should generate a full sized image in the output mime type (if it doesn't match the original image mime type).

For example, if you uploaded 'file.jpeg', for images below big_image_size_threshold we would store a 'file-webp.webp' version of the full sized image; for larger than big_image_size_threshold files where WordPress is creating a '-scaled' version, we should also create a -webp version of the scaled image. These full sized images could then be used in place of the original or -scaled images for the img src tag.

[nosilver4u]

With #143 in mind, if folks use this: add_filter( 'image_editor_output_formats', function() { return array( 'image/webp' ); } );
Then it seems the full-size should be stored in the WebP format whether it's above big_image_size_threshold or not.
Does that potentially cause issues where images over 2560 have -scaled, and those under 2560 have -webp in the filename? Or is it irrelevant so long as the proper path/filename is stored in the attachment metadata?

[adamsilverstein]

Then it seems the full-size should be stored in the WebP format whether it's above big_image_size_threshold or not.
we would probably store both versions in this case, using the WebP version for the src attribute of the image tag (matching the srcset).

in spots like the media library or certain functions, we may still want to treat the file matching the uploaded mime type as the "original" file. so even though there is a full size WebP image, if you go to the media editor, it will use the full size jpeg image (assuming you start with a jpeg upload... that would be the original or a file with -scaled appended).