Open felixarntz opened 2 years ago
@maheshwaghmare @mukeshpanchal27 @jjgrainger Paging you here for awareness, we can discuss further here. #517 has a potential implementation for this, if we decide to move forward with the idea.
Thanks @felixarntz
I think this is something worth exploring as it could potentially solve other issues raised (#513 and #509). These are cases where users were expecting WebP to be updated across other parts of the site, such as archive pages and other templates, which do not as they fall outside of the content.
We already update the featured image HTML, so I think updating images created on the frontend with wp_get_attachment_image
should be explored. I also agree with only targeting functions that output the img
HTML and not those that return a URL.
PR #517 looks like a great place to start and is the simplest approach that could be disabled by removing the filter.
If we move forward with this we would need to test this to make sure this doesn't impact areas that do not support WebP such as RSS feeds and Open Graph meta.
+1 on this! Since so many folks use page builders these days, I think we'll continue to get frustration/questions about this moving forward, so it would be great to address.
+1 It would be fantastic if we could incorporate these changes into a plugin so that other page builders or custom template users could benefit from them.
I quickly test checked the Elementor Website Builder source code and they mainly used wp_get_attachment_image
for image related blocks, so if we implement it, then it is a big win. Here we just need to think. We need to implement it as default like we do for the featured image.
For the unit test we cac remove_filter( 'wp_get_attachment_image', 'webp_uploads_update_attachment_image', 10, 2 );
filter so it will be pass.
If we move forward with this we would need to test this to make sure this doesn't impact areas that do not support WebP such as RSS feeds and Open Graph meta.
RSS feeds and OG meta does not use <img>
tag related functions so i don't think there will be any impact on those. 🤔
Feature Description
Related to #155 (and raised again by PR #517): While it probably makes sense to add a MIME type parameter to the relevant image core functions as described in #155, this doesn't mean that we should rely solely on the plugin and theme developers to use WebP.
Since the current behavior is to replace JPEG images with WebP images in post content
img
tags, potentially we could also do the same in otherimg
tags which would be used in the frontend. I think that this would fall under the same considerations, e.g. as long as it's purely withinimg
tags, we should be fine since those are definitely user-facing HTML in the frontend, within thebody
. In other words, we could by default adjust the output ofwp_get_attachment_image()
(which outputs animg
tag) but not the one of e.g.wp_get_attachment_image_src()
orwp_get_attachment_image_url()
(which only return URL etc., but not necessarily for use in animg
tag).Special cases where this is not desired already right now would have to unhook the content replacement filter, so if we added one more filter somewhere else, they would simply need to remove that too, so not a notable overhead.
Let's think about this.