REST API: Normalize non-integer attachment filesize metadata by apermo · Pull Request #12611 · WordPress/wordpress-develop

apermo · 2026-07-20T11:34:21Z

Trac ticket

https://core.trac.wordpress.org/ticket/65670

Problem

WP_REST_Attachments_Controller::get_attachment_filesize() (new in 7.0.0) returns the filesize value from attachment metadata verbatim against a strict ?int return type. Attachment metadata is untyped postmeta, so a non-numeric string value throws a fatal TypeError when the media endpoint is requested:

TypeError: WP_REST_Attachments_Controller::get_attachment_filesize():
Return value must be of type ?int, string returned

A numeric string only survives because the file has no strict_types declaration (coercion). A non-numeric one fatals.

Plugins populate filesize from remote storage API responses — e.g. the Google Drive fileSize field (returned as a string) via WP Media Folder, and the equivalent Dropbox/OneDrive addons — so this occurs on real sites.

Fix

Only return the stored value when it is numeric, cast to int; otherwise fall through to recompute the size from the file via wp_filesize() (which always casts to int), returning null if unavailable. This matches the 'type' => 'integer' REST schema.

Testing

Two regression tests added to tests/phpunit/tests/rest-api/rest-attachments-controller.php:

numeric-string filesize meta → normalized to int in the response;
non-numeric filesize meta → no fatal, falls back to the real file size.

The non-numeric test reproduces the reported TypeError against unpatched trunk (red), and passes with the fix (green).

Disclosure

Claude (Anthropic) assisted in diagnosing the root cause and drafting the patch and tests. I reviewed the change, verified the red/green test behavior locally, and take responsibility for it.

Attachment metadata is untyped, so `filesize` can be stored as a string (for example, plugins that populate it from a remote storage API response such as the Google Drive `fileSize` field, which the API returns as a string). Returning it verbatim violated the `?int` return type of `WP_REST_Attachments_Controller::get_attachment_filesize()` and caused a fatal TypeError for non-numeric values. Only return the stored value when numeric, casting to int; otherwise fall through to recompute the size from the file via wp_filesize(). Fixes https://core.trac.wordpress.org/ticket/65670 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

github-actions · 2026-07-20T11:34:32Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props apermo, westonruter, xate, mukesh27.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

apermo · 2026-07-20T11:34:46Z

@westonruter would you be able to review this? It fixes a fatal TypeError in get_attachment_filesize() (new in 7.0.0) when filesize attachment metadata is stored as a non-numeric string — which happens on sites using plugins that populate it from remote storage APIs (e.g. the Google Drive fileSize string via WP Media Folder). Trac: https://core.trac.wordpress.org/ticket/65670

apermo · 2026-07-20T11:36:37Z

@westonruter Would you be so kind to have a look at it? Thanks :)

xateman

Looks good 👍

github-actions · 2026-07-20T11:39:27Z

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

All changes will be lost when closing a tab with a Playground instance.
All changes will be lost when refreshing the page.
A fresh instance is created each time the link below is clicked.
Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

Shorten the inline comment in get_attachment_filesize() to the essential rationale, per PR review feedback. See https://core.trac.wordpress.org/ticket/65670 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…HPStan issues in tests

Copilot

Pull request overview

This PR fixes a REST API fatal error in WP_REST_Attachments_Controller::get_attachment_filesize() by ensuring attachment filesize metadata (which is untyped postmeta) is normalized to an integer (or recomputed) before being returned under a strict ?int return type.

Changes:

Normalize numeric filesize metadata to an int, and fall back to recomputing the file size when metadata is not usable.
Add REST API regression tests covering numeric-string and non-numeric filesize metadata cases.
Add an extra sanity assertion in an existing attachment REST test to ensure the factory returns an integer attachment ID.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
tests/phpunit/tests/rest-api/rest-attachments-controller.php	Adds regression tests validating `filesize` normalization and non-numeric recovery behavior.
src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php	Hardens `get_attachment_filesize()` by validating/casting stored metadata before returning it.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Refine the filesize metadata guard per PR review: accept only a positive integer (an int or a digit-only string), rather than any numeric value. This avoids silently truncating float strings such as '123.4' via the int cast, and rejects zero and negative values, falling through to recompute the size from the file in those cases. Also document the method's positive-integer return with a @phpstan-return non-negative-int|null annotation. See https://core.trac.wordpress.org/ticket/65670 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

Attachment metadata is untyped, so `filesize` may be a float, bool or other non-string scalar. Passing such a value to ctype_digit() is fragile (deprecated in PHP 8.1+), so guard the call with is_string(); non-string scalars now fall through to recompute the size from the file. Extend the invalid-value data provider with float and boolean cases. See https://core.trac.wordpress.org/ticket/65670 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

westonruter · 2026-07-21T07:25:19Z

I fixed the typing of this function as otherwise get_attachment_filesize() would not be guaranteed to return a non-negative-int. This would warrant additional tests to ensure negative values get increased to zero.

Could there be any reason any plugin would filter pre_wp_filesize or wp_filesize to be negative?

Besides the obvious "Developer did a bad job, or had some quirky idea"?

I don't think so, but that alone is already bad enough.

No technically legitimate reason, but definitely a reason.

Copilot

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Copilot

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (2)

src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php:2369

is_numeric( $meta['filesize'] ) allows non-integer numeric strings (e.g. '123.4', '1e3') and floats; casting those to (int) can silently change the stored value. Since filesize is a byte count (integer per REST schema), it’s safer to only accept a positive int or a digit-only string and otherwise fall back to wp_filesize().

		if ( isset( $meta['filesize'] ) && is_numeric( $meta['filesize'] ) && $meta['filesize'] > 0 ) {
			return (int) $meta['filesize'];
		}

tests/phpunit/tests/rest-api/rest-attachments-controller.php:1108

To prevent regressions where non-integer numeric values get truncated (or where non-string scalars would hit ctype_digit()), consider adding '123.4', '1e3', and 123.0 to the invalid filesize provider so the test asserts the response falls back to the actual on-disk file size.

		return array(
			'non-numeric string'      => array( 'corrupt' ),
			'boolean'                 => array( true ),
			'zero'                    => array( 0 ),
			'zero string'             => array( '0' ),
			'negative integer'        => array( -5 ),

…red value

State the zero-or-greater guarantee the same way in the function docblock as in the wp_filesize hook docblock, rather than phrasing it two different ways in one function. Describe the pre_wp_filesize short-circuit as accepting a non-negative number, since a non-negative numeric string bypasses the filesize call too. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Cover a negative int, a negative numeric string, and a negative float, since the filtered value is now normalized with is_numeric() rather than is_int() and each of those types reaches the sign check differently. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

westonruter · 2026-07-21T21:06:12Z

 		$schema['properties']['filesize'] = array(
 			'description' => __( 'Attachment file size in bytes.' ),
-			'type'        => 'integer',
+			'type'        => array( 'integer', 'null' ),


Claude pointed out that null could be returned by the endpoint.

Copilot

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php:2369

get_attachment_filesize() currently treats any positive is_numeric() metadata value as valid and then (int)-casts it. This accepts values like '123.4' and '1e3', which get silently truncated/normalized (123 and 1000) even though a byte size should be an integer. That can surface an incorrect filesize in the REST response rather than falling back to wp_filesize().

		if ( isset( $meta['filesize'] ) && is_numeric( $meta['filesize'] ) && $meta['filesize'] > 0 ) {
			return (int) $meta['filesize'];
		}

tests/phpunit/tests/rest-api/rest-attachments-controller.php:1062

This docblock says invalid filesize values should not cause a "silently truncated size", but the data_valid_filesize_meta() provider above explicitly asserts truncation/normalization for values like '123.4'. The documentation here should be updated to match the behavior under test.

	 * Ensures a `filesize` metadata value that is not a positive integer does
	 * not cause a fatal TypeError or a silently truncated size, falling back to
	 * the actual file size instead.

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (2)

src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php:2369

is_numeric( $meta['filesize'] ) will treat values like '123.4' and '1e3' as valid, and casting those to (int) silently changes the stored value (truncation / notation parsing). Since filesize represents a byte count, it should only accept integer values (int, integer-like float with no fractional part, or digit-only string) and otherwise fall back to wp_filesize().

		if ( isset( $meta['filesize'] ) && is_numeric( $meta['filesize'] ) && $meta['filesize'] > 0 ) {
			return (int) $meta['filesize'];
		}

tests/phpunit/tests/rest-api/rest-attachments-controller.php:1056

data_valid_filesize_meta() currently treats float/scientific-notation strings as “valid” and asserts truncation via (int) casting. If filesize is meant to be an integer byte-count, these should be treated as invalid metadata and the controller should fall back to the real file size instead (avoids silent truncation).

		return array(
			'integer string'      => array( '123456', 123456 ),
			'float string'        => array( '123.4', 123 ),
			'scientific notation' => array( '1e3', 1000 ),
			'float'               => array( 123.0, 123 ),
		);

…nt`. A negative file size is clearly impossible, and the return value of 0 is already documented as being the error case. * Values filtered by `pre_wp_filesize` and `wp_filesize` are cast to `int` if they are numeric. * Non-numeric values returned by the `wp_filesize` filter are discarded in favor of zero. * Negative values filtered by the `pre_wp_filesize` filter are treated the same as `null` (and do not short-circuit). * Negative values returned by the `wp_filesize` filter are clamped to be at least zero. Developed as part of #12611. Follow-up to r52837, r52932. Props westonruter, apermo. See #65670, #64898. git-svn-id: https://develop.svn.wordpress.org/trunk@62813 602fd350-edb4-49c9-b593-d223f7449a82

…nt`. A negative file size is clearly impossible, and the return value of 0 is already documented as being the error case. * Values filtered by `pre_wp_filesize` and `wp_filesize` are cast to `int` if they are numeric. * Non-numeric values returned by the `wp_filesize` filter are discarded in favor of zero. * Negative values filtered by the `pre_wp_filesize` filter are treated the same as `null` (and do not short-circuit). * Negative values returned by the `wp_filesize` filter are clamped to be at least zero. Developed as part of WordPress/wordpress-develop#12611. Follow-up to r52837, r52932. Props westonruter, apermo. See #65670, #64898. Built from https://develop.svn.wordpress.org/trunk@62813 git-svn-id: http://core.svn.wordpress.org/trunk@62093 1a063a9b-81f0-0310-95a4-ce76da25c4cd

* The return value of the `WP_REST_Attachments_Controller::get_attachment_filesize()` method is narrowed from `int|null` to `non-negative-int|null`. * The stored `filesize` attachment metadata is only returned if it is a numeric value and is greater than zero; it is cast to an `int`, preventing a `TypeError` if a non-numeric string was stored in metadata. * The `filesize` property of the attachments endpoint adds `null` as a possible value in addition to `integer`. Developed in #12611. Follow-up to r62813, r61703. Props apermo, westonruter, xate, mukesh27. Fixes #65670. git-svn-id: https://develop.svn.wordpress.org/trunk@62815 602fd350-edb4-49c9-b593-d223f7449a82

github-actions · 2026-07-21T23:18:15Z

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 62815
GitHub commit: 128db3c

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.

* The return value of the `WP_REST_Attachments_Controller::get_attachment_filesize()` method is narrowed from `int|null` to `non-negative-int|null`. * The stored `filesize` attachment metadata is only returned if it is a numeric value and is greater than zero; it is cast to an `int`, preventing a `TypeError` if a non-numeric string was stored in metadata. * The `filesize` property of the attachments endpoint adds `null` as a possible value in addition to `integer`. Developed in WordPress/wordpress-develop#12611. Follow-up to r62813, r61703. Props apermo, westonruter, xate, mukesh27. Fixes #65670. Built from https://develop.svn.wordpress.org/trunk@62815 git-svn-id: http://core.svn.wordpress.org/trunk@62095 1a063a9b-81f0-0310-95a4-ce76da25c4cd

xateman approved these changes Jul 20, 2026

View reviewed changes

xateman reviewed Jul 20, 2026

View reviewed changes

Comment thread src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php Outdated

apermo and others added 2 commits July 20, 2026 13:41

docs(rest): trim filesize guard comment per review

ba9bf73

Shorten the inline comment in get_attachment_filesize() to the essential rationale, per PR review feedback. See https://core.trac.wordpress.org/ticket/65670 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Eliminate legacy args for create_object() and add assertions to fix P…

dfb925e

…HPStan issues in tests

Copilot AI review requested due to automatic review settings July 21, 2026 02:58

Copilot started reviewing on behalf of westonruter July 21, 2026 02:58 View session

Copilot AI reviewed Jul 21, 2026

View reviewed changes

Comment thread src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php Outdated

mukeshpanchal27 reviewed Jul 21, 2026

View reviewed changes

Comment thread src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php Outdated

mukeshpanchal27 reviewed Jul 21, 2026

View reviewed changes

Comment thread tests/phpunit/tests/rest-api/rest-attachments-controller.php

Copilot AI review requested due to automatic review settings July 21, 2026 06:32

Copilot started reviewing on behalf of apermo July 21, 2026 06:33 View session

Copilot AI reviewed Jul 21, 2026

View reviewed changes

Comment thread src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php Outdated

Comment thread tests/phpunit/tests/rest-api/rest-attachments-controller.php

Copilot AI review requested due to automatic review settings July 21, 2026 06:39

Copilot started reviewing on behalf of apermo July 21, 2026 06:39 View session

Copilot AI reviewed Jul 21, 2026

View reviewed changes

westonruter added 5 commits July 21, 2026 00:09

Remove change to unrelated test

12a4efa

Add typing to data provider

6d2882e

Remove extra line break

be49854

Ensure wp_filesize() never returns a negative number

d27aa4b

Reformat multi-line conditional

a6810a9

Copilot AI review requested due to automatic review settings July 21, 2026 07:23

Copilot started reviewing on behalf of westonruter July 21, 2026 07:23 View session

westonruter reviewed Jul 21, 2026

View reviewed changes

Comment thread src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php Outdated

Copilot AI reviewed Jul 21, 2026

View reviewed changes

Relax attachment metadata filesize to include numeric values

c50756d

Copilot AI review requested due to automatic review settings July 21, 2026 20:14

Copilot started reviewing on behalf of westonruter July 21, 2026 20:14 View session

Copilot AI reviewed Jul 21, 2026

View reviewed changes

Comment thread tests/phpunit/tests/rest-api/rest-attachments-controller.php

westonruter and others added 9 commits July 21, 2026 13:28

Improve wording of since tag

7d71ec8

Improve name of test method

0808521

Indicate that filesize may be null in REST API response

ec081cb

Improve data provider name

bd24dfd

Add tests for numeric-string as wp_filesize and pre_wp_filesize filte…

3d7ddf4

…red value

Clarify numeric value vs numeric string

f556a44

Add negative value test for pre_wp_filesize

6122b77

Copilot AI review requested due to automatic review settings July 21, 2026 21:04

Copilot started reviewing on behalf of westonruter July 21, 2026 21:05 View session

westonruter reviewed Jul 21, 2026

View reviewed changes

Copilot AI reviewed Jul 21, 2026

View reviewed changes

Comment thread tests/phpunit/tests/rest-api/rest-attachments-controller.php Outdated

Comment thread src/wp-includes/functions.php

Improve param name

7d68239

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings July 21, 2026 21:12

Copilot started reviewing on behalf of westonruter July 21, 2026 21:13 View session

Copilot AI reviewed Jul 21, 2026

View reviewed changes

Comment thread tests/phpunit/tests/rest-api/rest-attachments-controller.php

westonruter approved these changes Jul 21, 2026

View reviewed changes

github-actions Bot closed this Jul 21, 2026

Uh oh!

Conversation

apermo commented Jul 20, 2026

Trac ticket

Problem

Fix

Testing

Disclosure

Uh oh!

github-actions Bot commented Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

apermo commented Jul 20, 2026

Uh oh!

apermo commented Jul 20, 2026

Uh oh!

xateman left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jul 20, 2026

Test using WordPress Playground

Some things to be aware of

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

westonruter Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

apermo Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

apermo Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

westonruter Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

github-actions Bot commented Jul 21, 2026

Uh oh!

Reviewers

Assignees

Labels

github-actions Bot commented Jul 20, 2026 •

edited

Loading