-
Notifications
You must be signed in to change notification settings - Fork 392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Save filesize with attachment metadata on upload #493
Conversation
Sets the "filesize" property in the attachment metadata when initially uploading images, so that it doesn't have to be queried for in wp_prepare_attachment_for_js() ajax response.
Nice, I had assumed core already did this -- do you know why it doesn't? |
inc/class-plugin.php
Outdated
* @param array $metadata Attachment metadata. | ||
* @return array Attachment metadata array, with "filesize" value added. | ||
*/ | ||
function set_filesize_in_attachment_meta( $metadata ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
function set_filesize_in_attachment_meta( $metadata ) { | |
function set_filesize_in_attachment_meta( array $metadata ) : array { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This project is using Psalm too, so once the unit tests are fixed, I'd imagine we'll need to add the array shape decelerating like elsewhere in the file.
The unit tests are failing here, because |
I don't think there was a reason it wasn't added. The logic to check for "filesize" in attachment meta was added in 4.4 (ticket) to support external image libraries and I guess the assumption was that those plugins had to implement attachment metadata themselves. Looks like there's a ticket open to set filesize in this metadata array in core - https://core.trac.wordpress.org/ticket/49412 - and if that gets merged this workaround can be removed. |
The attachment metadata array doesn't always have a "file" attribute. This uses the core API for getting the attached file rather than building it from the file path and the upload dir.
This annotation is too damn long. Cutting out the keys which aren't relevant so that we don't have to define types for all of them.
inc/class-plugin.php
Outdated
function set_filesize_in_attachment_meta( array $metadata, int $attachment_id ) : array { | ||
$file = get_attached_file( $attachment_id ); | ||
|
||
if ( file_exists( $file ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should return early if filesize is already set too, that will mean it's future compatible when images add it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was thinking that too. Adding it now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 4c50bf1
inc/class-plugin.php
Outdated
* | ||
* @param array{file?: string} $metadata Attachment metadata. | ||
* @param int $attachment_id Attachment ID. | ||
* @return array{file?: string, filesize: int} Attachment metadata array, with "filesize" value added. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should also be filesize?
as it's possible the array won't contain it (if the file doesn't exist). I'd have thought Psalm would have caught that 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, but that didn't seem to fix the build either 🤔
@joehoyle Could you help me understand why the build isn't passing here? The error is
but I'm not familiar with what that means, and I think I'm following the style from the documentation and elsewhere in the file. |
Forward compatability check in case WP included this property in the future, see https://core.trac.wordpress.org/ticket/49412.
Ahh doh it seemed I inadvertently switched to a different version of Psalm ( |
*/ | ||
function set_filesize_in_attachment_meta( array $metadata, int $attachment_id ) : array { | ||
$file = get_attached_file( $attachment_id ); | ||
if ( ! $file ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@goldenapples get_attached_file
can return false, so I added the check here -- Psalm was complaining about that. Yey for type safety!
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub.
git fetch
# Create new working tree.
git worktree add .worktrees/backport v2-branch
# Navigate to the new directory.
cd .worktrees/backport
# Cherry-pick all the commits of this pull request and resolve the likely conflicts.
git cherry-pick e1222c65f467fc88189aa4a79283f47fe75cb7f3 fe01c24c1c5ff6f2f48dc1574bf28b7e67baa303 ce82bc4e1667f9dd06237c2343683237955bc170 4ff03c148127ea23d08dfe70c39973f9b0752935 018a780c4af7c4af14dcc4c0bfccb8e15ce35199 7564fbc3afb30dfe7861efaf4fe581675c812655 4c50bf1117ef12dbefb9b504d7279820b3ced085 069cab852955a1e09a57bc65d31a48cada650d6b ec01ea6a517f4aaa2fdea501a843494728a9b803 20d54076437f1cb7724acd60caae323b825afd41
# Create a new branch with these backported commits.
git checkout -b backport-493-to-v2-branch
# Push it to GitHub.
git push --set-upstream origin backport-493-to-v2-branch
# Go back to the original working tree.
cd ../..
# Delete the working tree.
git worktree remove .worktrees/backport Then, create a pull request where the |
Sets the "filesize" property in the attachment metadata when initially uploading images, so that it doesn't have to be queried for in the ajax response on
wp_prepare_attachment_for_js()
.Fixes #492.