Include filesize information in REST API response for all media types

[tfrommen]

Requesting the /media REST API endpoint, only audio attachments include filesize information in the response data (in media_details->filesize).

I suggest to check for each item if filesize is present, or else fill it in using the actual file. This would be pretty much in line with what is done in ​wp_prepare_attachment_for_js.

Making the information available locally, when creating the response data, is much more performant than having to request the file in one or more follow-up requests.

[tfrommen]

Formatting

[desrosj]

Today is 5.8 feature freeze. Unfortunately this one ran out of time.

Punting to 5.9 as there has been good recent momentum.

[spacedmonkey]

Related: #49412

[spacedmonkey]

This ticket was discussed in this week's REST API meeting.

In short, making filesize calls in the rest api, will likely come with some overhead. For example those storing files on NFS or S3, will like need to ping an external resource to get file information, slowing down the response.

Until file sizes are "cached" somehow ( see #49412 ), this ticket should be marked as blocked.

[TimothyBlynJacobs]

Moving to Future Release based off comment:6.

[johnbillion]

This will need a refresh after #49412 as the filesize value can be read from the attachment metadata when it exists.

[spacedmonkey]

It is worth noting that #49412 merged. For all new attachments uploaded after WP 6.0, filesize will be stored ( cached ) in as part of metadata. To get this file size for all attachments, post thumbnails can be regenerated, say wp cli, like this wp media regenerate.

[azaozz]

I suggest to check for each item if filesize is present, or else fill it in using the actual file.

What would be achieved by doing this? How is the file size going to be used and why?

Keep in mind that the cached filesize in the image meta is missing for all previously uploaded images. It is also unreliable when present and should not be used for anything more than "guessing". This is because some (many?) hosting companies seem to optimize images directly on the disc, without running WP. So the filesize meta becomes wrong/outdated soon after images are uploaded.

Another reason is that even greater number of sites/hosting companies replace JPEGs with WebPs on-the-fly, so the filesize meta is totally unusable/has nothing to do with the actual image used.

I was with the impression that the above details about the filesize meta are available as docs (in a docblock) added with #49412, but seems that's not the case. This needs to be fixed. Making it available in the REST API should also come with a good explanation of how unreliable it is and what are the expected uses. Frankly I don't see any good use for it, adding something with no use cases is generally a no-go.

[azaozz]

Related: #57459.