Return filesize from Image_Editor_Imagick::_save()

[karlisb]

Fixes #750.

Image_Editor_Imagick::_save() rebuilds its response array after copying the temp file to S3, but omits the filesize key that WP_Image_Editor::_save() has returned since WP 6.0 (core ticket #49412).

As a result:

• saves from the media library image editor (wp_save_image()) trigger an "Undefined array key" PHP warning and persist attachment meta without a usable filesize;
• sizes[*]['filesize'] is missing from attachment meta for all sub-sizes on every upload;
• code paths that read the value fall back to remote filesize() stats against S3 — the slow HEAD requests Idea: store filesize attachment meta value on upload. #492 / Save filesize with attachment metadata on upload #493 aimed to eliminate (the Save filesize with attachment metadata on upload #493 backfill hooks wp_generate_attachment_metadata, which never fires on the image-editor save path).

This change returns the filesize that parent::_save() already computed for the local temp file — byte-identical to the object copied to S3, so no extra remote request is made. The wp_filesize() fallback only applies if a future WP version stops returning the key. Docblocks updated to match.

[joehoyle]

Would it not be better to get the filesize before it's uploaded to s3? That would reduce / remove a network call.

[karlisb]

It already does, as $save is a reference the return value of parent::save().
You're right that wp_filesize is a fallback that will make an extra HEAD request but only so this wouldn't break if by any reason Wordpress would revert the introduced filesize in 6.0. In practice this shouldn't be executed ever.
Would you rather me implement a fallback that stats the temp file (a few lines up) before discarding it rather that risking an extra HEAD request if Wordpress goes berserk? 😄