Store file size (and other) media metadata

[adamsilverstein]

At the moment, WordPress does not store the file (storage) sizes for uploaded files, or the sizes of media generated, in the database. At the moment, whenever WordPress needs to find out this information, it needs to read from the filesystem, or make remote requests in the case of a CDN. This keeps WordPress from using this information to make more informed decisions about responsive images or resizing in a performant fashion.

We should store file sizes as attachments are uploaded, and use this information in appropriate existing locations in core where file size is queried.

Trac ticket: https://core.trac.wordpress.org/ticket/49412

[jonoalderson]

Worth noting that there's often a read cost ($) associated with these types of remote lookups, depending on where/how the images are hosted.

[adamsilverstein]

I updated the trac ticket with a refresh against trunk.

From the last comment from Andrew Ozz:

• It will only be added for the "full" image size. This may not be the uploaded/original image file if the image was resized on uploading.
• It may be missing or unreliable (if the image was optimized by a plugin after uploading), and will be used primarily as cache when displaying image info in wp_admin.
• May be good to have some sort of a "backfill" functionality when filesize is missing. However that should happen "very sensibly". DB writes should be optimized (single write per page load) and happen only from wp-admin.

Leaving off the "backfill" for existing images could also be left for a second phase, it could probably happen naturally as a part of image regeneration.

[eclarke1]

@mitogh @felixarntz can this issue also be closed as my understanding was that #147 also covered this issue? Please could you confirm?

[mitogh]

That's correct @eclarke1 I wonder if we should create a new one to move the efforts from emerging the original PR into core at some point or if we should do it once the whole feature is merged there.

• https://core.trac.wordpress.org/ticket/49412

[eclarke1]

That's correct @eclarke1 I wonder if we should create a new one to move the efforts from emerging the original PR into core at some point or if we should do it once the whole feature is merged there.

Good question, this is something we may need to defer to @felixarntz on as there are a few other issues in a similar position I believe.