Follow-up to #307: As identified by @mitogh in #318 (review) and then further discussed in #160 (comment), we should allow developers to optionally return the file size of a custom generated additional image source when using the webp_uploads_pre_generate_additional_image_source. This is crucial for implementations where e.g. the image is hosted in a CDN, which would mean that calling filesize() on a path would not be feasible.
It is probably best to make the filesize field optional, for two reasons:
- To not break any existing filter usage, because the current version of the filter will already be released as part of plugin version 1.1.0.
- To keep things simpler for plugins that do generate files within the WordPress environment, in which case WordPress can just call
filesize() on the path returned.
Since the path returned is only relevant for calling filesize(), I suggest we implement the change as follows:
- Continue to require the
file key to be included in the array.
- In addition to that, require either
path or filesize to be included in the array.
- In case of
path, keep calling filesize() on it like today.
- In case of
filesize, use that value as is to return it within the result array.
Follow-up to #307: As identified by @mitogh in #318 (review) and then further discussed in #160 (comment), we should allow developers to optionally return the file size of a custom generated additional image source when using the
webp_uploads_pre_generate_additional_image_source. This is crucial for implementations where e.g. the image is hosted in a CDN, which would mean that callingfilesize()on a path would not be feasible.It is probably best to make the
filesizefield optional, for two reasons:filesize()on thepathreturned.Since the
pathreturned is only relevant for callingfilesize(), I suggest we implement the change as follows:filekey to be included in the array.pathorfilesizeto be included in the array.path, keep callingfilesize()on it like today.filesize, use that value as is to return it within the result array.