Introduce filter to use custom logic to find additional mime types images

[mitogh]

The main objective of this filter is to allow third-party plugins or developers to change the current logic used for this plugin (the performance plugin) to locate additional mime images, for example, if a plugin stores the images in a different location and the file names are created out of a custom hash functions rather than in a predictable way, this filter would allow developers to provide the location and logic to replace images in the content of the site.

This is a sub-issue of #160 and related to #307.

Filter

webp_uploads_pre_replace_additional_image_source

Parameters

• image: The value of the replaced image, if the image is the same as the value returned from the filter the replacement logic is used, meaning that the image was not modified.The HTML code of the image being modified.
• attachment_id: The ID of the attachment being processed.
• image_size: The name of the image size we are looking for. When creating the additional mime types for the original image this value would be full, in the same way it occurs in WordPress core.
• mime_type: The targeted mime type of the file we are looking for.
• context: Context is under where the image is being used.

Integration

The suggestion location to add this filter are the following places:

• https://.com/WordPress/performance/blob/trunk/modules/images/webp-uploads/load.php#L474
• https://.com/WordPress/performance/blob/trunk/modules/images/webp-uploads/load.php#L496

Suggested approach

$filtered_image = apply_filters( 'webp_uploads_pre_replace_additional_image_source', $image, $attachment_id, $image_size, $mime_type, $context );
// Only plugin logic to replace the image if the `filtered_image` is the same as the image, meaning it was not modified.
if ( $filtered_image === $image ) {
      $filtered_image = str_replace( ... );
}

Note

We need to make sure the filter runs regardless of whether our own replacement mechanism finds a file.

In other words, some of the conditions in our code need to be checked only after the new filter is run, since those conditions are only relevant for our own way to replace the URLs, but potentially not for how a plugin that stores image files elsewhere would need to replace them.

[felixarntz]

@mitogh The issue description mostly looks good, a few comments on the proposed implementation:

Parameters

• image: The value of the replaced image, if the image is the same as the value returned from the filter the replacement logic is used, meaning that the image was not modified.
• attachment_id: The ID of the attachment being processed.
• image_size: The name of the image size we are looking for. When creating the additional mime types for the original image this value would be null.
• mime_type: The targeted mime type of the file we are looking for.
• image: The HTML code of the image being modified.
• context: Context is under where the image is being used.

1. You have image in here twice, so that part wouldn't work. I think the first parameter needs to be the image HTML tag, and then we don't need to provide it again. This also makes the parameters better aligned with the one from the filter in Introduce filter to use a custom mechanism to create additional mime images #307, only this one has context as additional parameter.
2. Similar to Introduce filter to use a custom mechanism to create additional mime images #307, I think it would make more sense to use full for the full image size.

The suggestion location to add this filter are the following places:

• https://.com/WordPress/performance/blob/trunk/modules/images/webp-uploads/load.php#L474
• https://.com/WordPress/performance/blob/trunk/modules/images/webp-uploads/load.php#L496

This may already be clear, but I just want to clarify: In both cases, we need to make sure the filter runs regardless of whether our own replacement mechanism finds a file. In other words, some of the conditions in our code need to be checked only after the new filter is run, since those conditions are only relevant for our own way to replace the URLs, but potentially not for how a plugin that stores image files elsewhere would need to replace them.

[mitogh]

Thanks @felixarntz I just updated the issue description to reflect your feedback.

This may already be clear, but I just want to clarify: In both cases, we need to make sure the filter runs regardless of whether our own replacement mechanism finds a file. In other words, some of the conditions in our code need to be checked only after the new filter is run, since those conditions are only relevant for our own way to replace the URLs, but potentially not for how a plugin that stores image files elsewhere would need to replace them.

That's a great point, I will add it to the issue description as well in order to make sure is clear.