v1.4.9 — attachment size from metadata

Faster attachment rendering

AttachmentHelper::getAttachmentObject() fired a blocking cURL HEAD request for every attachment, so a single page render made dozens of round trips over the network to Azure. WordPress 6.0+ already stores the size in wp_get_attachment_metadata()['filesize'], so it is now read from there, and the HEAD request remains only as a fallback for attachments that still lack it.

human_size is unchanged — still a string from size_format().

Hardened HEAD fallback (FileHelper::getRemoteFileSize())

• Accept-Encoding: identity — on a compressed response Content-Length describes the gzipped body, not the file (measured 25 994 B against a 126 558 B file).
• HTTP 200 only — a 404 error page carries a Content-Length of its own and was being reported as the file size.
• Timeouts (5s connect / 10s total) — the default was unbounded, so an unresponsive origin could hold a PHP worker until max_execution_time.
• Content-Length of the final hop — FOLLOWLOCATION leaves the headers of every redirect in the buffer, so a 302's own Content-Length could win over the real one.
• URL rebuilt from its parsed parts — the previous string-replace dropped the port and percent-encoded the query string, which corrupted any URL carrying an Azure SAS token.

Upgrading

composer update radeno/wordpress-base-helpers

Full changelog: v1.4.8...v1.4.9