REST API: Add dimension validation to sideload endpoint#11100
REST API: Add dimension validation to sideload endpoint#11100adamsilverstein wants to merge 7 commits intoWordPress:trunkfrom
Conversation
When client-side media processing handles big image scaling, the client creates a -scaled version and sideloads it back. The sideload route's image_size enum was missing 'scaled', causing 400 validation errors. This adds 'scaled' to the enum, adds handling in sideload_item() to record the original file and update the attachment to point to the scaled version, and updates the unique filename filter regex to recognize the -scaled suffix.
Add 'scaled' to the image_size enum in wp-api-generated.js to match the PHP route registration change, fixing the git diff --exit-code CI check. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add tests for the new 'scaled' image_size enum value in the sideload endpoint: verifying metadata updates, authentication requirements, route schema, and unique filename handling for the -scaled suffix. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
get_attached_file() can return false when no file is attached. Add a guard to return a WP_Error before calling wp_basename() with a falsy value.
The sideload route uses edit_media_item_permissions_check which returns rest_cannot_edit_image, not rest_forbidden.
Validates uploaded image dimensions against expected size constraints in the wp/v2/media/<id>/sideload endpoint. This prevents users from uploading incorrectly-sized images for a specified image size. Validation rules: - 'original' size: must match original attachment dimensions exactly. - 'full' and 'scaled' sizes: requires positive dimensions only. - Regular sizes: dimensions must not exceed registered size maximums (with 1px tolerance for rounding differences). Also adds two new test cases for dimension validation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Trac Ticket MissingThis pull request is missing a link to a Trac ticket. For a contribution to be considered, there must be a corresponding ticket in Trac. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description. More information about contributing to WordPress on GitHub can be found in the Core Handbook. |
|
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 Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe 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
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
| /* translators: 1: Expected width, 2: expected height, 3: actual width, 4: actual height. */ | ||
| __( 'Uploaded image dimensions (%3$dx%4$d) do not match original image dimensions (%1$dx%2$d).' ), | ||
| $expected_width, | ||
| $expected_height, | ||
| $width, | ||
| $height | ||
| ), |
There was a problem hiding this comment.
Any deeper reasoning why you chose to switch order in the printf template over the order of how they are in the sprintf()here?
In my eyes it would be simpler to have them (by default) in the same order as they are displayed, as this would make things easier to read and reduce cognitive load.
| // 'full' size (PDF thumbnails) and 'scaled': dimensions must be positive. | ||
| if ( 'full' === $image_size || 'scaled' === $image_size ) { | ||
| if ( $width <= 0 || $height <= 0 ) { | ||
| return new WP_Error( | ||
| 'rest_upload_invalid_dimensions', | ||
| __( 'Uploaded image must have positive dimensions.' ), | ||
| array( 'status' => 400 ) | ||
| ); | ||
| } | ||
| return true; | ||
| } |
There was a problem hiding this comment.
Is there any valid case where negative dimensions are actually allowed?
I see that empty could be allowable for SVGs, but I can't see any case where a negative integer is a valid dimension.
| // Dimensions must be positive. | ||
| if ( $width <= 0 || $height <= 0 ) { | ||
| return new WP_Error( | ||
| 'rest_upload_invalid_dimensions', | ||
| __( 'Uploaded image must have positive dimensions.' ), | ||
| array( 'status' => 400 ) | ||
| ); |
There was a problem hiding this comment.
see above, you're checking this here, if it is a valid case for having 2 checks, maybe this could be refactored into a function that performs the check, so you don't repeat yourself?
2 participants
Summary
Builds on #11015. Adds dimension validation to the sideload endpoint.
validate_image_dimensions()private method toWP_REST_Attachments_Controllerwp/v2/media/<id>/sideloadendpointwp_getimagesize()call earlier insideload_item()to validate before metadata handlingValidation rules:
Test plan
test_sideload_item_rejects_oversized_dimensions— uploads 640x480 image as thumbnail (150x150), expects 400 withrest_upload_dimension_mismatchtest_sideload_item_accepts_valid_dimensions— uploads 50x50 image as thumbnail, expects 200Corresponding Gutenberg PR: WordPress/gutenberg#74903
🤖 Generated with Claude Code