WordPress.org

Make WordPress Core

Opened 10 days ago

Last modified 3 days ago

#49412 new feature request

Store filesize media metadata

Reported by: Cybr Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Media Keywords: has-patch
Focuses: performance Cc:

Description

Previous: #33214, comment:6:ticket:47459

When storing media files, I think it'd be helpful that the result of filesize( $file ) is stored with the media's metadata. Whereafter we can retrieve it via wp_get_attachment_metadata().

This way, we no longer have to touch the file and can work from the database-provided metadata instead. There's performance overhead involved when media is stored on slow/shared storage or even on another server.

Attachments (2)

49412.diff (12.2 KB) - added by johnwatkins0 4 days ago.
49412.2.diff (12.2 KB) - added by johnwatkins0 4 days ago.
Removed a line of debug code

Download all attachments as: .zip

Change History (7)

#1 @SergeyBiryukov
10 days ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

#2 @SergeyBiryukov
10 days ago

For some context, WordPress does read the size from the filesize meta value in a few places, but it's only set for audio and video files from the data extracted by getID3() library. Related: comment:4:ticket:33214.

Some history:

It would indeed be beneficial to store the file size in metadata for any attachment.

#3 @johnwatkins0
4 days ago

I've been working on this. I agree it's a useful idea. I've seen and created plenty of workarounds for the fact that filesize data isn't already saved with images. It's especially tricky where files are stored remotely.

The only question I have is whether we think it would be useful to have the file size for all intermediate image sizes as well as the full-sized image, or just for the full-sized image?

I think it makes sense to store all of them, since the main reasons I can think of for having this data involve comparing filesizes -- e.g., when looping through images to find the largest one under a limit.

The drawbacks to storing all are (1) more filesize calls at the time an image is uploaded, and (2) inflated metadata.

I'm going ahead with the assumption that we want all sizes.

Last edited 4 days ago by johnwatkins0 (previous) (diff)

#4 @johnwatkins0
4 days ago

Attaching a diff that adds "filesize" to the metadata for all attachments. For images, the field is at the top level as well as in all of the sizes in the sizes array -- e.g.:

Array
(
    [width] => 426
    [height] => 640
    [file] => 2020/02/2004-07-22-DSC_0007.jpg
    [filesize] => 87348
    [sizes] => Array
        (
            [medium] => Array
                (
                    [file] => 2004-07-22-DSC_0007-200x300.jpg
                    [filesize] => 26505
                    [width] => 200
                    [height] => 300
                    [mime-type] => image/jpeg
                )

            [thumbnail] => Array
                (
                    [file] => 2004-07-22-DSC_0007-150x150.jpg
                    [filesize] => 19138
                    [width] => 150
                    [height] => 150
                    [mime-type] => image/jpeg
                )

        )

    [image_meta] => Array
        (
            ... etc.
        )

)

_wp_attachment_metadata will be created as needed -- e.g.:

Array
(
    [_wp_attached_file] => Array
        (
            [0] => 2020/02/2019-my-file.pptx
        )

    [_wp_attachment_metadata] => Array
        (
            [0] => a:1:{s:8:"filesize";i:8419858;}
        )

    [_edit_lock] => Array
        (
            [0] => 1582035593:1
        )

)

Video and audio files will still have their filesize read by getID3() if possible, but there is a fallback if for whatever reason getID3() doesn't provide the filesize.

Question

The key in the meta array should be carefully considered. I'm using filesize because it matches the PHP function and the convention I've seen in plugins and themes that store file size in meta. There's no reason it has to be this, though. If there's a more semantic key -- or perhaps one that is sure to be unique and not conflict with plugins that may hook into attachment metadata -- then it could easily be changed. Any thoughts?

Last edited 3 days ago by johnwatkins0 (previous) (diff)

@johnwatkins0
4 days ago

@johnwatkins0
4 days ago

Removed a line of debug code

#5 @johnwatkins0
4 days ago

  • Keywords has-patch added; needs-patch removed
Note: See TracTickets for help on using tickets.