[wp-trac] [WordPress Trac] #52840: Include filesize information in REST API response for all media types

[WordPress Trac]

#52840: Include filesize information in REST API response for all media types
-------------------------------------------------+-------------------------
 Reporter:  tfrommen                             |       Owner:
                                                 |  rachelbaker
     Type:  enhancement                          |      Status:  accepted
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  REST API                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-unit-tests needs-    |     Focuses:  rest-api
  refresh 2nd-opinion                            |
-------------------------------------------------+-------------------------
Changes (by azaozz):

 * keywords:  has-patch needs-unit-tests needs-refresh => has-patch needs-
     unit-tests needs-refresh 2nd-opinion


Comment:

 > 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52840#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform