Image mime type is not set correctly when a webp image is generated.

[mitogh]

Note

Make sure the Performance plugin is enabled and activated, as well with the webp modules for images at: Settings > Performance

Related with issue:

• Improve core image handling to support modern images #16

Steps to recreate:

1. Open the WordPress dashboard.
2. Go to Media > Add New
3. Upload the image
4. Go to Media > Library and open the image, observe the image has an extension image/jpeg instead of image/webp

Original image to replicate the issue.

[felixarntz]

@mitogh Similar to #69, this may be because the source image is still JPEG if it was originally JPEG. Try uploading a WebP image directly, in that case it should say image/webp. cc @adamsilverstein

[adamsilverstein]

The mime type in the media library should show the mime type of the image you uploaded - the original image, not the mime type of the sub sizes (of which there could be potentially more than one) which is what the webp-uploads module changes. So if your original image is a jpeg, this should show image/jpeg (even if your sub-sized images are WebP). Similarly, if you upload a WebP image, this should show image/webp

[mitogh]

@mitogh Similar to #69, this may be because the source image is still JPEG if it was originally JPEG. Try uploading a WebP image directly, in that case it should say image/webp. cc @adamsilverstein

Uploading a WebP image correctly sets the correct mime type @felixarntz

The mime type in the media library should show the mime type of the image you uploaded - the original image, not the mime type of the sub sizes (of which there could be potentially more than one) which is what the webp-uploads module changes. So if your original image is a jpeg, this should show image/jpeg (even if your sub-sized images are WebP). Similarly, if you upload a WebP image, this should show image/webp

Agree with this behavior, however, the behavior is not consistent when a scaled version is created which would be created as a WebP if the module is enabled. I'm adding more details below, so we can make a decision. @adamsilverstein in how to move forward when this scenario is presented.

---

Questions / Needs decision

• Full image should be converted to WebP (including scaled version)?
• Should scaled version be converted to WebP?
• If full image is converted to WebP should the original JPEG be stored in original_image similar to WordPress behavior?
• Should the mime type on the post ( post_mime_type property ) match the full image or the uploaded image?

This is closely related to #96 (comment)

Description

Scenario 1 - Very large image

When a large (in dimensions) image is uploaded to WordPress (see Image 1 at the bottom), WordPress would create a subsize with the suffix scaled, this image would be converted to WebP giving inconsistent behavior in the UI when this is the case.

Discrepancy between URL from full image size and mime type in the admin

The Full URL from the editor would be https://galaxy.lndo.site/wp-content/uploads/2022/01/zhan-zhang-lfAW14Oxh14-unsplash-scaled.webp while the modal displays an image/jpeg mime type.

This behavior is correctly displayed on the single view of the media, where both displays the correct mime type WebP for the URL and the UI.

The original image (very large image in JPEG format) is uploaded as well and stored in the same directory as the scaled version, the current behavior from WordPress is this and the path to this image is stored in original_image key of the image meta. See the next section with the sample data of the image.

This is the current behavior in WordPress with the difference when the module is enabled t

Meta information of the image

=> array(6) {
  ["width"]=>
  int(2560)
  ["height"]=>
  int(1707)
  ["file"]=>
  string(51) "2022/01/zhan-zhang-lfAW14Oxh14-unsplash-scaled.webp"
  ["sizes"]=>
  array(9) {
    ["medium"]=>
    array(4) {
      ["file"]=>
      string(44) "zhan-zhang-lfAW14Oxh14-unsplash-300x200.webp"
      ["width"]=>
      int(300)
      ["height"]=>
      int(200)
      ["mime-type"]=>
      string(10) "image/webp"
    }
    ["large"]=>
    array(4) {
      ["file"]=>
      string(45) "zhan-zhang-lfAW14Oxh14-unsplash-1024x683.webp"
      ["width"]=>
      int(1024)
      ["height"]=>
      int(683)
      ["mime-type"]=>
      string(10) "image/webp"
    }
    ...
  }
  ["image_meta"]=> ...
  }
  ["original_image"]=>
  string(35) "zhan-zhang-lfAW14Oxh14-unsplash.jpg"
}

See:

• Image is partially converted to WebP #69
• Image mime type is not set correctly when a webp image is generated. #67
• Ensure post meta reflects image mime type #75

Scenario 2 - Small image

When a smaller image is uploaded the scaled version is not created and the UI does not present inconsistencies (Use Image 2 to replicate this scenario) however the mime type is always JPEG.

URL of the image https://galaxy.lndo.site/wp-content/uploads/2022/01/leon-s-y4TzCAsLego-unsplash-1.jpg from the modal UI.

Metadata of the image

=> array(5) {
  ["width"]=>
  int(640)
  ["height"]=>
  int(427)
  ["file"]=>
  string(41) "2022/01/leon-s-y4TzCAsLego-unsplash-1.jpg"
  ["sizes"]=>
  array(4) {
    ["medium"]=>
    array(4) {
      ["file"]=>
      string(42) "leon-s-y4TzCAsLego-unsplash-1-300x200.webp"
      ["width"]=>
      int(300)
      ["height"]=>
      int(200)
      ["mime-type"]=>
      string(10) "image/webp"
    }
   ....
  }
  ["image_meta"]=> ...
  }
}

Inconsistencies

As described above the module for WebP works as expected but I'm not 100% if the current behavior is intended due to this behavior being inconsistent when different image sizes are uploaded, the main idea/question is to define the path we want to implement for the full image size based on that decision most of the initial questions would be answered.

Resources

Image 1

Image 2

[adamsilverstein]

@mitogh I have created a PR that skips the scaled image transformation - #143 can you give that a test, it should fix this issue at least for the single mime output use case.

[mitogh]

Just tested this fix and works as expected @adamsilverstein 👍