.webp files not properly handled

[pscolv]

As of today, .webp picture format tends to be widely used in order to accelerate page download speed.

There are plugins, like ShortPixel, which automatically process the media library and generate copies of the images there, in .webp format, such that they can be used on supported browsers.

This works fine with wordpress standard image url retrieve functions, which output the right version depending on whether the browser supports it.

However in the case of Buddypress, I noticed that .webp images are retrieved, even if they are not supported by the browser (ex : Firefox), which leads to broken images on the website.

The bp functions affected by this issue are (at least) :

• bp_attachments_get_attachment => chooses the first image in the folder which corresponds to the requested type (eg cover-image), and apparently doesn't take the format into account.
• bp_displayed_user_avatar => also presents the issue

One way of solving this would be to use the <picture> html tag, which proposes different image sources to the browser, for it to choose the most appropriate, or align with the wordpress approach which I didn't study in detail...

[pscolv]

Extract from bp_attachments_get_attachment() function

[DJPaul]

Thanks for letting us know about this kind of problem, @pscolv. We handle these images entirely differently from how WordPress handles items in its Media Library, mainly for legacy implementation reasons. It means changing how it works is a big task.

I don't think this task will attract sufficient contributors in the short-term. It won't make the March(-ish) release, so the earliest it would be sometime around June-July, and I think that's a bit optimistic, to be honest.

I had a quick chat with @hnla about the idea of wrapping the avatars in picture elements, and it seems doable at a glance, though by no means has it been properly looked into. e.g. how it might affect on backwards compatibility with customised BuddyPress themes; performance concerns around fetching the mime type for the nested source element; and whether this is the best solution for the problem or if a large rewrite should be embarked upon, as described in ​https://buddypress.trac.wordpress.org/ticket/5715#comment:18

[imath]

It has been implemented in 11.0 see #8643