Including WebP versions in “wp_get_attachment_metadata”
-
I’m probably switching from EWWW to Imagify because EWWW’s bulk optimizer isn’t converting all sizes of my images to WebP, but Imagify seems to be doing a great job of that. One issue is that since I don’t like WordPress’ methods for creating image tags with srcset, I have my own method which uses the
wp_get_attachment_metadata()
function, but the WebP versions aren’t being included. To get around this (and with some code borrowed from the Imagify Tools library) I created a filter forwp_get_attachment_metadata
which modifies the metadata array by including the WebP images. I only filter the metadata on the front-end, not in the admin area, because I’m not sure if it could have unintended consequences in the admin area. Is there a reason not to do this, or can you see anything in the filter that could be problematic? We don’t support any browsers that don’t support WebP.Also, I have a recommendation. When you’re on the Bulk Optimization page and the optimizer is running, there should be something that lets you know if it’s safe to leave the page, or refresh the page, or what exactly you’re able to do without stopping the optimization process. Does it run in the background no matter if you’re on the Bulk Optimization page or not? It would be helpful if there was a notice or something letting you know what’s safe to do.
Here’s a Pastebin of the filter since the block editor seems to not be able to properly show a code block:
- The topic ‘Including WebP versions in “wp_get_attachment_metadata”’ is closed to new replies.