WordPress.org

Make WordPress Core

Opened 10 months ago

Closed 7 weeks ago

Last modified 7 weeks ago

#47459 closed feature request (invalid)

Introduce new a function to retrieve size of files

Reported by: justinahinon Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Media Keywords: close
Focuses: Cc:

Description

While working on a plugin, I realized that there was not a dedicated WordPress function to retrieve the size of the media library files. The question does not seem to have been asked on the trac previously (after a brief search).

So I think it would be good to introduce such a function. It would not take long to write since PHP already provides filesize(). It could be a new function or it could be added to an existing one (I'm thinking of wp_get_attachment_metadata() ).

Change History (9)

#1 @SergeyBiryukov
10 months ago

  • Component changed from General to Media

Hi @justinahinon, welcome to WordPress Trac! Thanks for the ticket.

There is a filesize() PHP function that WordPress itself uses to display the size of files in Media Library.

You can use it to get the file size in bytes, e.g. 7358:

$file = get_attached_file( $attachment_id );
echo filesize( $file );

Or combine it with size_format() to get a human-readable string, e.g. 7 KB:

$file = get_attached_file( $attachment_id );
echo size_format( filesize( $file ) );
Last edited 7 weeks ago by SergeyBiryukov (previous) (diff)

#2 @SergeyBiryukov
10 months ago

Sorry, now I see that you've already mentioned filesize() in the ticket description.

#3 @justinahinon
10 months ago

Thanks @SergeyBiryukov for looking at the ticket. I know filesize() and how to use it for media gallery files size. I was just wondering if if would not be better to have a dedicated function.

But it'll probably take almost the same number of line if it was a dedicated function.

#4 @justinahinon
7 months ago

  • Keywords close added
  • Resolution set to wontfix
  • Status changed from new to closed

I'm closing this ticket since writing a dedicated function will require almost the same number of lines of codes than using filesize().

#5 @desrosj
7 months ago

  • Keywords close removed
  • Milestone Awaiting Review deleted

#6 follow-up: @Cybr
5 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I want to contribute my thoughts on this subject.

For performance reasons, I think it's best not to touch the files more than necessary. Instead, we should rely on the stored image metadata, and let WordPress deal with filling it.

Moreover, image processors (Smush, WP Offload, EWWW, etc.) can do their thing via filters, without other developers having to guess where the processed image is.

With all that, adding the file size to the metadata would be most welcome.

I found that WordPress internally already tries to read this index (even though it doesn't exist):
https://core.trac.wordpress.org/browser/tags/5.2/src/wp-includes/media.php#L3271

After this is implemented, a needs-dev-note would be helpful, so the aforementioned plugins can start recognizing and (p)refilling the metadata.

Last edited 5 months ago by Cybr (previous) (diff)

#7 @justinahinon
7 weeks ago

  • Keywords close added
  • Resolution set to invalid
  • Status changed from reopened to closed

#8 in reply to: ↑ 6 @SergeyBiryukov
7 weeks ago

Replying to Cybr:

With all that, adding the file size to the metadata would be most welcome.

I found that WordPress internally already tries to read this index (even though it doesn't exist):
https://core.trac.wordpress.org/browser/tags/5.2/src/wp-includes/media.php#L3271

Good catch, looks like that was originally added for audio and video files, which should have that information extracted with getID3() library. Then it propagated to a few other areas. Related: comment:4:ticket:33214.

Some history:

Feel free to create a new ticket to explore the idea of adding the file size to the metadata for any attachment.

#9 @Cybr
7 weeks ago

Follow up: #49412

Note: See TracTickets for help on using tickets.