Add mime-type for Webp

[markoheijnen]

Would be great that at least WP_Image_Editor (if supported) could be used to transform images to the .webp format. Tickets #24718 and #27789 focus on upload which is something which could be done later.

[wonderboymusic]

​http://caniuse.com/webp

[blobfolio]

PHP support for WebP is starting to catch up. I'd like to investigate whether or not it is feasible to expand this enhancement to include thumbnail generation support as well.

I'll dive deeper in the next week or so and update the patch accordingly, but in the meantime, here are a few references:

GD and EXIF support:

• ​https://php.net/manual/en/function.imagecreatefromwebp.php (PHP 5.5)
• ​https://php.net/manual/en/function.imagewebp.php (PHP 5.5)
• ​https://secure.php.net/manual/en/function.exif-imagetype.php (PHP 7.1)

The output from gd_info() should include ['WebP Support']=>true under environments that support WebP.

Imagick can be compiled with WebP support (e.g. with libwebp-dev, etc.). This does not seem to be very common yet, but we could conditionally check the response of Imagick::queryFormats('WEBP'); a non-empty array() being Yay!, an empty one being Boo!

• ​http://www.imagemagick.org/script/formats.php
• ​https://www.imagemagick.org/script/webp.php

[blobfolio]

Patch with upload_mimes and image editor integration.

[blobfolio]

Files for unit testing.

[blobfolio]

The 35725.diff patch adds full WebP support to WordPress:

• Whitelists webp files for upload;
• Adds webp to the list of image formats for admin display, thumbnail generation, etc.;
• Provides numerous workarounds for environments where WebP support exists in a partial state;
• Supports VP8, VP8L, and VP8X container formats;
• GD handling (PHP5.6+ for VP8, PHP7.0+ for the rest);
• ImageMagick handling (works as long as the system's binary was compiled with WebP support);

This patch introduces one new function:

/**
 * Wrapper for getimagesize()
 *
 * The native PHP function might not support newer formats.
 *
 * @since 5.0
 *
 * @see {https://core.trac.wordpress.org/ticket/35725}
 *
 * @param string $file Full path to the file.
 * @param array $info Additional metadata to pull.
 * @return array|false An array containing width, height, type constant, attributes, and media type.
 */
function wp_get_image_size( $file, &$info = array() ) { ... }

All calls to the native getimagesize() function have been redirected to this wrapper to ensure that WebP dimensions are properly reported. This also fixes the inconsistent use of error suppression that existed previously.

This wrapper can later be expanded to account for other new formats, such as #42775.

A few other things to note:

• Hosts that do not support WebP through GD or ImageMagick will still allow files to be uploaded, they just won't get intermediate sizes.
• There was once a bug in GD that confused ARGB with RGBA, causing colors to shift. This has been fixed upstream, but some unsupported distributions (like Debian Squeeze) might still be using it.
• ImageMagick on Arch Linux is currently causing a segfault when dumping a WebP via the getImageBlob() method. As a workaround, stream previews (when e.g. editing an image) output png instead. This doesn't affect the saved results, so seems safe to keep.

One final note:

WebP browser support (​https://caniuse.com/#search=webp) is not universal.

This patch restricts its focus to backend handling, but there is opportunity for a future frontend-focused patch to provide jpg/png fallbacks. The use of the HTML5 <picture> element seems like the best approach for such work. As it happens, @desrosj is currently working on general <picture> support for WP, so if/when that lands, a frontend WebP enhancement should be easy. :)

[blobfolio]

Just a refresh :)

[micasuh]

With Firefox 65's WebP support and Edge adopting Chromium and Blink, the end of 2019 could be close to 80% WebP support unless Webkit surprises us. Browsers that don't support WebP will be outliers.

@blobfolio's patches (which I assume can easily be updated again) and @desrosj's work on <picture> would give WP devs an excellent avenue to use WebP in production today and help reduce load times in non-trivial ways.

I think 2019 is the right time for this to move to core.

[desrosj]

Looks like 35725.2.diff​ is no longer applying cleanly to trunk.

[desrosj]

This ticket was discussed briefly in the weekly media office hours this morning.

Because Safari ​still does not support WebP, this seems like plugin territory until there is a way to specify multiple sources for an image in core.

[pmsanz]

Replying to desrosj:

This ticket was discussed briefly in the weekly media office hours this morning.

Because Safari ​still does not support WebP, this seems like plugin territory until there is a way to specify multiple sources for an image in core.

I'm sorry, but 13 browsers does support it, and only 4 does not (Apple is always late). Anyway, there is a solution for displaying WebP in any browser with a piece of Js: ​https://webpjs.appspot.com/

It would be interesting to offer a config option in WordPress to convert uploaded files to .jpg or .webp, so user can decide. In my case, media is 80% of the site, so .webp would be great to trim disk storage.

[themefour]

After more than 8 months, this format is still not supported! I don't know, is this a difficult task? Or politics behind the scenes!

​https://wordpress.org/support/topic/add-support-webp-format-imge/

[spacedmonkey]

As of safari 14.0, safari on iOS, iPadOS, and MacOS will support WEBP natively. See the ​dev notes of first beta.

These new versions of the OS will not ship until September, but we can start working on patch that could land as soon as WordPress 5.6.

[spacedmonkey]

Related: #35726 #24718

[atjn]

Because Safari still does not support WebP, this seems like plugin territory until there is a way to specify multiple sources for an image in core.

@desrosj WebP is now supported in ​all browsers, including Safari. Time to reconsider?

[audrasjb]

#51766 was marked as a duplicate.

[anonymized_18391075]

I found a code to add a plugin which enables webp. Think that is the base, but there is much more needed to handle webp. Especially in Gutenberg there need to be block settings for it. The question for me is if it will be handled within an image block or as an own block. An own block would offer more possibilities.

<?php
/**
* Plugin Name: WEBP Enabling
* Plugin URI: 
* Description: WEBP Enabling
* Version: 1.0
* Author: Sven Esser
* Author URI: 
* Functions Included: webp_upload_mimes, webp_is_displayable
**/

//** *Enable upload for webp image files.*/
function webp_upload_mimes($existing_mimes) {
$existing_mimes['webp'] = 'image/webp';
return $existing_mimes;
}
add_filter('mime_types', 'webp_upload_mimes');

//** * Enable preview for webp image files.*/
function webp_is_displayable($result, $path) {
if ($result === false) {
$displayable_image_types = array( IMAGETYPE_WEBP );
$info = @getimagesize( $path );

if (empty($info)) {
$result = false;
} elseif (!in_array($info[2], $displayable_image_types)) {
$result = false;
} else {
$result = true;
}
}
return $result;

}
add_filter('file_is_displayable_image', 'webp_is_displayable', 10, 2);
?>

[anonymized_18391075]

Just wondering why this didn't made it into WP 5.6. Now it's a must for WP 5.7 I think.

[anonymized_18391075]

How can we make sure webp is making it into WP 5.7?

[anonymized_18391075]

We discussed in slack the way to go. It comes to the point of image sizes and what is supported:

GD vs imagick vs JS library

• GD is supporting webp since PHP 4.3
• Imageick isn't 100% sure since when it supports webp, but looks like since 4 years minimum
• There is also a possibility to use a JS library

So it looks like GD should be prefered use with JS as fallback
1st GD, 2nd JS

Or is it better o go for this?
1st GD, 2nd Imagick, 3rd JS

[anonymized_18391075]

Also it is iimportant that someone takes over ownership and push it into 5.7. I can't do so.

[Clorith]

Some more research should also be put into the underlying dependencies here, as both the GD and Imagick library can be compiled without WebP support (at least in the case of GD, it needs to be explicitly told to compile with the support).

An indication of availability of such features would go a long way as an initial step before looking at possible implementations.

Other considerations brought up is availability from a user perspective, the support for WebP in the image libraries is for either converting other formats towards WebP, but also to manipulate WebP images to generate image sizes for example. But we should also consider the formats availability to end users, can they make the image format them selves?

And finally, compatibility, as noted, the latest OSX just launched (Big Sur) which brings support for WebP to the Safari browser, but other clients are still lagging behind. the ever present IE 11 is still out there in the wild, and Microsoft Edge (pre-chromium update) is also the latest Edge version available to many users due to the staggered rollout from Microsoft, both of which do not support the WebP format and a fallback would need to be implemented for sites trying to use WebP images that their visitors may not be able to access, this introduces wrapper classes which may not be compatible with existing styling of sites, and is likely going to need a theme support entry for WebP, much like there is for HTML5-variations of some components.

[anonymized_18391075]

Thanks @Clorith

Regarding "other clients are still lagging behind"...

​https://caniuse.com/webp

So it was just Safari which hasn't supported it. IE is replaced by Edge and I don't think we should skip webp because of IE. IE isn't supporting many many things right now and is outdated... a bit like Netscape :-)

[joemcgill]

I would love to see this happen, but there are a few distinct challenges that we'd need to solve to move this forward.

First, we need to be clear by what we meant when we say "add WebP support". Allowing people to upload WebP images to their media library is insufficient, in my opinion, as long as there are are a number of devices/browsers that still don't support rendering WebP images. As of today (Nov 13, 2020) WebP support is sitting at ~86% based on ​https://caniuse.com/webp. This has gotten much better, but not enough to add it as a default format yet.

In order to truly support WebP images (and other next-generation formats, like AVIF) we need to be able to convert uploaded files to these alternate formats and create sub-sizes. We also will need to decide on a way of serving users the best available image format to people based on the capabilities of their browsers. There are a number of strategies we could pursue, including markup based solutions (i.e. <picture>) or server-side solutions that serves alternative file formats based on the accept header from a request. The latter is admittedly more difficult since WP currently serves files directly from the filesystem, rather than hitting any code where this logic could run before serving an image, so it may be a nonstarter to pursue something like this for core.

[anonymized_18391075]

AVIF is no option based on this
​https://caniuse.com/avif

webp is working in Safari since yesterday. The updates will take fast and the WP 5.7 takes some month to take place.
So with this, the current stats on ​https://caniuse.com/webp is not relevant asny longer. We need to add webp support now! Please don't switch back the discussion to this. With in the slack chat we all agreed that we need to implement webp support now (WP 5.7)

Just enabling upload and visibility in the media library is by far not enough. As explained in #30 it is about generating different image sizes and also transform other image formats into webp.

[anonymized_18391075]

Sorry if I got it wrong. Think the difference is between this 2 points:

1. Support of webp
2. Using webp as default image format

Support should be a clear yes!
Default format should be a no or better there should be a switch in settings if yes or no.

On a settings page it is easy to check if the hosting provider support everything which is needed(like GD / Imagick or other thigs) and display a red / green icon. If it is green the option to switch to webp as the default format should be available. If the icon is red it means that the server doesn't support everything which is needed and therefore this option is grayed out.

[anonymized_18391075]

Short Reminder:

1) Googles Web Vitals are measuring performance and will be part of the ranking factor starting May 2021
2) webp is bosting website performance
3) WP 5.7 is sheduled for March 2021

So the timing for webp is perfect! :-)

[jorbin]

Please don't switch back the discussion to "if or not".

It's not switching it back, no decision has been made. In fact, before an if this should happen decision is made, a decision on what we want to do is needed.

There are a number of strategies we could pursue, including markup based solutions (i.e. <picture>) or server-side solutions that serves alternative file formats based on the accept header from a request. The latter is admittedly more difficult since WP currently serves files directly from the filesystem, rather than hitting any code where this logic could run before serving an image, so it may be a nonstarter to pursue something like this for core.

I think the picture based solution is much better, but sadly it still means IE is left out, so it doesn't give us much more adoption. To me, running WP on every image request is a non-starter. That's going to beat up a lot of servers.

[anonymized_18391075]

We also left Netscape out, so no problem to left out the outdated IE 11

[anonymized_18391075]

So here are the key things to do at the moment:

1. Image Manipulation

Details in #30 and ​https://github.com/WordPress/phpunit-test-runner/issues/131

2. Detection enviorenment and switch

Details in #36

[atjn]

Replying to jorbin:

There are a number of strategies we could pursue, including markup based solutions (i.e. <picture>) or [...]

I think the picture based solution is much better, but sadly it still means IE is left out, so it doesn't give us much more adoption. To me, running WP on every image request is a non-starter. That's going to beat up a lot of servers.

@jorbin the <picture> element is specifically designed with older browsers in mind. It lets you define a fallback image that older browsers can read and understand, while newer browsers will recognize the newer markup around the fallback, and use that instead.
This allows you to support the latest fancy image types like AVIF, while falling back to still-performant WEBP for other browsers, and then falling back again to JPEG for legacy browsers, all in a few lines of simple markup. I highly recommend going with the <picture> solution, and apart from triage considerations, I see no reason that it can't be implemented and shipped immediately.

[anonymized_18391075]

@atjn thanks for describing the <picture> element... now it is clear for me. 100% with you to use it as a fallback solution, even if it's just afew lines of simple markup.

Also 100% with you, there is no reason it can't be implementd and shipped immediately. We don't need a triage.

[blobfolio]

Replying to svenwordpress:

Also 100% with you, there is no reason it can't be implementd and shipped immediately. We don't need a triage.

I mean, there are a quarter of a billion reasons not to alter the HTML structure generated by existing WordPress image functions. Themes styling images based on e.g. p > img will break if images are suddenly shoved into <picture> elements. There will also be untold consequences for all the sites using plugins or custom workarounds to produce their own <picture>-type solutions currently. (Lots of tools, and even the Core itself, rely on dirty regex parsing, for example.)

Performance-wise, many servers already struggle to generate all the different JPG and PNG thumbnails needed for display. Auto-generating WebP conversions would double that burden on upload, and require a runtime performance hit to check for file_exists() on older media to either create the missing WebPs or avoid suggesting dead links. (Retroactive generation would be a disaster even on speedy servers; a typical archive page calls a dozen or more images, and when you factor in the srcset variants, that could easily reach triple digits.)

But that said, there's no reason WordPress can't support the WebP format in its own right, the same way it supports JPG and PNG formats. I did all the hard work for that years ago. Someone just needs to go through those patches to update them for a Gutenberg world. ;)

[anonymized_18391075]

There are billions of reasons to close the web today! Let's stop seeing issues and start seeing possibilities!!!

If there are more to come with problems asking for stoping webp support I switch of and change from WordPress to another system!!!!

Sorry, but meanwhile I get angry!!!!!!

[anonymized_18391075]

So, here's the attended to-do list

1. Support of webp

1.1. Upload of webp
1.2. Display in media gallery
1.3. Image Manipulation for resizing webp and transforming other image formats into webp
1.3.1. GD vs Imagick vs JS library
1.3.2. …
1.4. …

2. Using webp as default image format

2.1. Add a new settings page which
2.1.1. Adds a check of the server environment and displays a red or green signal
2.1.2. Add a switch to decide if webp should be the default format or not. Fixed to not if the check in 3.1.1 failed

3. Decision if handled within Gutenberg through an image block or an own block

3.1. Do we need additional block settings for webp?
3.2. ...

[atjn]

@blobfolio I see, I don't know too much about the implementation in WordPress.

[anonymized_18391075]

@atjn Implementation isn't the issue at the moment. It is more about the what to do exactly. I also don't know how to implement it.... I'm not a programmer. WHat I can do is defining the tasks and sum things up. The pure coding is the last step where I'm out... I step back in if it goes to testing.

@all Please see my list in comment # 46. Anything to add?

[blobfolio]

Replying to svenwordpress:

Sorry, but meanwhile I get angry!!!!!!

Why are you angry? You can already do all of this with plugins. WordPress is used by hundreds of millions of people in hundreds of millions of different ways. Features like this are great if they can be implemented as *optional enhancements*, but there are very real consequences when decisions are made to abruptly force changes in behavior for everyone.

Replying to svenwordpress:

Using webp as default image format

It should be noted that WebP is primarily *lossy* in nature. It isn't a magic bullet that can be used to represent all images all the time. It is great sometimes, and terrible others. It should not serve as a default; the format the user actually uploaded should serve as its own default. :)

Under the hood, WebP supports only RGBA and greyscale color tables, leading to immediate distortion of images saved with different color profiles, gamma corrections, etc. Beyond that, it struggles to cleanly represent hard color breaks of the variety seen in web comics, designer logos, (artful) product photography, etc; it will add blocky artifacts around the edges of such images.

Don't get me wrong. I love WebP and use it on probably 90% of my projects. But it requires intention. The aesthetic losses aren't always worth the arbitrary pagespeed score boost. Haha.

[anonymized_18391075]

Happy to see things to add to the to-do list

[desrosj]

@svenwordpress I truly appreciate that you are so passionate about adding support for the WebP image format to WordPress Core.

However, I want to ask that everyone please step back and consider several things.

• Hopping into a ticket and commenting 17 times in just over 10 hours will not move anything forward, no matter how urgent the need for a fix is. In fact, it will most likely have the opposite affect, as many people will most likely just unsubscribe to updates because their email is being flooded.
• This project is largely maintained by volunteers. Very few people are fortunate enough to be paid full-time to work on WordPress. And even the ones who are have a limited amount of time and resources they are able to contribute.
• One of the most important elements to having a "successful" contribution experience is to have a constructive attitude. Yelling, getting angry, making passive aggressive comments, and attacking other contributors is not tolerated.
• Everyone here wants to make WordPress better. It's perfectly acceptable (and actually preferred) for people to disagree on how to reach the same finish line. It helps ensure every aspect and potential outcome of a change is considered.
• There many millions of WordPress sites, and many more people who use WordPress in some capacity. Before such wide-reaching changes can be made, due diligence needs to be performed to ensure the changes would not make WordPress considerably "worse" for any sets of users.
• Changes take time, especially ones that touch so many areas of WordPress, such as this one. See bullet point 2.
• Many of the people chiming in on this ticket have been responsible for shepherding in large changes like this in the past. Their questions come from past experiences, and no one is trying to prevent this ticket from moving forward.
• Likewise, everyone's thoughts, questions, and ideas should be considered, regardless of experience level. I have not seen anything here that makes me think this has happened, but if someone feels dismissed or ignored, they are welcome to DM me on Slack and we can discuss. Everyone is welcome, and should feel that way.

If anyone feels that they are unable to partake in respectful conversations to help move this initiative forward, it is well documented that full WebP support can be added to a site very easily using a plugin, or various filters, and you are free to leave this ticket and continue using those methods instead. You're also free to fork WordPress and add Webp support to your own fork. Such is the beauty of open source.

[anonymized_18391075]

@desrosj I hate it when people see allways the bad thing and are blocking things. Your lines now are the reason why I'm out. Don't want to waste my time with fighting. BYE

[atjn]

Replying to blobfolio:

It should be noted that WebP is primarily *lossy* in nature. It isn't a magic bullet that can be used to represent all images all the time. [...]

[...] it struggles to cleanly represent hard color breaks of the variety seen in web comics, designer logos, (artful) product photography, etc; it will add blocky artifacts around the edges of such images. [...]

WebP was specifically designed to be a magic bullet that can represent any image. It has two different modes: WebP Lossy (which you are describing) and WebP Lossless which solves most of the issues you are bringing up.

I'd guess that your editor has a section somewhere that lets you choose between the two modes.

WebP definitely has certain issues, but not the ones you are mentioning here.