Make WordPress Core

Opened 3 years ago

Last modified 19 months ago

#52840 accepted enhancement

Include filesize information in REST API response for all media types

Reported by: tfrommen's profile tfrommen Owned by: rachelbaker's profile rachelbaker
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: REST API Keywords: has-patch needs-unit-tests needs-refresh 2nd-opinion
Focuses: rest-api Cc:


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.

Attachments (2)

52840.diff (827 bytes) - added by tfrommen 3 years ago.
52840.1.diff (819 bytes) - added by tfrommen 3 years ago.

Download all attachments as: .zip

Change History (14)

3 years ago

3 years ago


#1 @rachelbaker
3 years ago

  • Keywords needs-unit-tests added
  • Milestone changed from Awaiting Review to 5.8
  • Owner set to rachelbaker
  • Status changed from new to accepted

This ticket was mentioned in Slack in #core-media by spacedmonkey. View the logs.

3 years ago

#3 @desrosj
3 years ago

  • Milestone changed from 5.8 to 5.9

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

Punting to 5.9 as there has been good recent momentum.

This ticket was mentioned in Slack in #core-restapi by spacedmonkey. View the logs.

3 years ago

#6 @spacedmonkey
3 years ago

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.

#7 @TimothyBlynJacobs
3 years ago

  • Milestone changed from 5.9 to Future Release

Moving to Future Release based off comment:6.

#8 @johnbillion
2 years ago

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

#9 @spacedmonkey
2 years ago

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.

#10 @johnbillion
19 months ago

  • Keywords needs-refresh added

#11 @azaozz
19 months ago

  • Keywords 2nd-opinion added

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 use cases. Frankly I don't see any use cases, adding something with no use cases is generally a no-go.

Version 0, edited 19 months ago by azaozz (next)

#12 @azaozz
19 months ago

Related: #57459.

Note: See TracTickets for help on using tickets.