#59684 closed defect (bug) (fixed)
'filesize' metadata not updated after resizing media
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.7 | Priority: | normal |
Severity: | minor | Version: | 6.3.3 |
Component: | Media | Keywords: | has-testing-info has-patch changes-requested |
Focuses: | Cc: |
Description (last modified by )
It seems like WordPress does not update the 'filesize' metadata after an image is modified through the media library. The details panel in the media library displays the original file size instead of the 'new' file size.
Environment
- WordPress: 6.3.3-alpha-56924
- PHP: 8.2.10
- Server: Apache
- Database: mysqli (Server: 5.7.31 / Client: mysqlnd 8.2.10)
- Browser: Chrome 118.0.0.0 (Windows 10/11)
- MU-Plugins: None activated
- Plugins:
- WordPress Beta Tester 3.5.4
The following optional modules are not currently installed on our server:
- exif
- fileinfo
- imagick
Steps to Reproduce
- Upload a new image in the media library
- Switch to the 'list' view in the media library to test the attachment page.
- Note the file size (ie. 22 KB)
- Resize the image by clicking on 'Edit Image', then 'Scale Image' (in my test case, I resized the image from 1920x1080 to 200x113)
- Click 'Update'
- The 'Dimensions' field is correctly updated, but 'File size' remains the same (22 KB)
Expected Results
The 'File size' should display the new file size (ie. 3.3 KB)
Actual Results
The 'File size' field displays the size of the original image, before it was resized.
Here is the value of the '_wp_attachment_metadata' field in the database after the media is resized:
a:6:{s:5:"width";i:200;s:6:"height";i:113;s:4:"file";s:31:"2023/10/Test-e1697729884174.png";s:8:"filesize";i:22990;s:5:"sizes";a:5:{s:6:"medium";a:5:{s:4:"file";s:16:"Test-300x169.png";s:5:"width";i:300;s:6:"height";i:169;s:9:"mime-type";s:9:"image/png";s:8:"filesize";i:4852;}s:5:"large";a:5:{s:4:"file";s:17:"Test-1024x576.png";s:5:"width";i:1024;s:6:"height";i:576;s:9:"mime-type";s:9:"image/png";s:8:"filesize";i:18748;}s:9:"thumbnail";a:5:{s:4:"file";s:16:"Test-150x150.png";s:5:"width";i:150;s:6:"height";i:150;s:9:"mime-type";s:9:"image/png";s:8:"filesize";i:3006;}s:12:"medium_large";a:5:{s:4:"file";s:16:"Test-768x432.png";s:5:"width";i:768;s:6:"height";i:432;s:9:"mime-type";s:9:"image/png";s:8:"filesize";i:13044;}s:9:"1536x1536";a:5:{s:4:"file";s:17:"Test-1536x864.png";s:5:"width";i:1536;s:6:"height";i:864;s:9:"mime-type";s:9:"image/png";s:8:"filesize";i:30857;}}s:10:"image_meta";a:12:{s:8:"aperture";s:1:"0";s:6:"credit";s:0:"";s:6:"camera";s:0:"";s:7:"caption";s:0:"";s:17:"created_timestamp";s:1:"0";s:9:"copyright";s:0:"";s:12:"focal_length";s:1:"0";s:3:"iso";s:1:"0";s:13:"shutter_speed";s:1:"0";s:5:"title";s:0:"";s:11:"orientation";s:1:"0";s:8:"keywords";a:0:{}}}
The "filesize" metadata has the value '22990' instead of '3033'.
Attachments (3)
Change History (25)
This ticket was mentioned in Slack in #core-test by ankit-k-gupta. View the logs.
16 months ago
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
10 months ago
#4
@
10 months ago
- Milestone changed from Awaiting Review to 6.6
this was mentioned in the recent Media component meeting and we agreed to move it to 6.6. Should be a simple write to update the metadata on resize. Keeping it top of mind. :)
This ticket was mentioned in PR #6406 on WordPress/wordpress-develop by @pls78.
10 months ago
#5
- Keywords has-patch added; needs-patch removed
### What
This PR fixes the wrong file size displayed in the medial library when a user resizes an image. At the same time, if the user decides to revert the changes made to the image, this PR makes possible to revert to the original file size.
### Why
This PR solves the issue described in the following Trac ticket: https://core.trac.wordpress.org/ticket/59684
### How
- In the
wp_save_image
function I collect the array returned bywp_save_image_file
and add it to the attachment metadata array as$meta['filesize']
- This allows to show the correct file size when the image is scaled
- Before doing this I save the original filesize in in the
$backup_sizes
array- This allows to retrieve the original file size in case the user reverts the changes made to the image size
- In the
wp_restore_image
function I then read back from$backup_sizes
the original file size and restore it when the user reverts back to the original size
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
8 months ago
#8
@
8 months ago
Test Report
This report validates that the indicated patch addresses the issue.
Patch tested: https://github.com/WordPress/wordpress-develop/pull/6406
### Environment
- WordPress: 6.6-beta2-58392-src
- PHP: 8.3.0
- Server: NGINX
- Browser: Chrome
Actual Results
- ✅ The file size is now showing smaller when resized to a smaller resolution.
Before Patch
After Patch
#9
@
8 months ago
Tested this patch. Seems to be working fine on my end.
The image size is getting updated after downscaling it.
#10
@
8 months ago
@antpb can you, please, take a look at this patch? We have RC1 later today )
Thank you!
This ticket was mentioned in Slack in #core by nhrrob. View the logs.
8 months ago
#12
@
8 months ago
- Milestone changed from 6.6 to 6.7
As per today's bugscrub, we're moving this to 6.7 as it wasn't committed in time for RC1.
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
6 months ago
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
5 months ago
#15
@
5 months ago
- Description modified (diff)
Updating the description's reproduction steps to specify that this test needs to be performed in the attachment details page, not in the media modal. Unfortunately, the tests by @rajinsharwar are not valid, because they were performed in the media modal.
#16
@
4 months ago
- Keywords changes-requested added
I've logged a change request on the associated pull request to avoid an PHP warning when the restored image does not have the backup filesize stored in the meta data.
This ticket was mentioned in Slack in #core by chaion07. View the logs.
4 months ago
#18
@
4 months ago
Thanks @vertisoft for reporting this. We reviewed this Ticket during a recent bug-scrub session. Here's a summary of the discussion:
- We need to Test the Ticket and share latest Test Results
- We also need to regenerate metadata after editing
Thank you.
Props to @sayedulsayem who will also share the latest Test Results that he informed during the bug-scrub.
Cheers!
#19
@
4 months ago
I tested this issue and found out the issue is valid. Let me demonstrate it in detail.
I uploaded a large image see the screenshot. The size after scale is 473 KB
Then, I edit the image and crop it. see the screenshot. The size is still showing 473 KB
When the actual image size in the server is 217 KB. See the screenshot.
From the bug-scrub, we think we have to recall or regenerate image metadata after editing. Anyone could submit a patch or PR. Thanks
@peterwilsoncc commented on PR #6406:
4 months ago
#20
@pls78 I took the liberty of pushing some code to your branch:
- a fix to potential error when restoring I noted a few days ago
- merged in trunk
- added a couple of unit tests to be sure the file size is modified & restored as expected
Test image