REST API: Add 'scaled' to sideload route image_size enum#11015
REST API: Add 'scaled' to sideload route image_size enum#11015adamsilverstein wants to merge 20 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.
|
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. |
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.
|
|
||
| $matches = array(); | ||
| if ( preg_match( '/(.*)(-\d+x\d+)-' . $number . '$/', $name, $matches ) ) { | ||
| if ( preg_match( '/(.*)(-\d+x\d+|-scaled)-' . $number . '$/', $name, $matches ) ) { |
There was a problem hiding this comment.
According to the PHPDoc, $number can be a string. When? What would it be in that case? Does it need to be escaped?
There was a problem hiding this comment.
maybe it can't be a string, let me check. escaping is rarely a bad idea.
There was a problem hiding this comment.
I decided to cast this as int for safety. According to Claude here is the logic (and why it can be a string):
Looking at wp_unique_filename() in src/wp-includes/functions.php:
- $number is initialized as '' (empty string) at line 2561
- Set to integer 1 at line 2588 when the filename matches a subsize pattern
- Incremented via (int) $number + 1 in while loops (lines 2624, 2697, 2758)
- Passed to the wp_unique_filename filter at line 2799
Possible values: empty string '' or positive integers (1, 2, 3, ...).
There was a problem hiding this comment.
There was a problem hiding this comment.
Ah, I see. It passes an empty string in case it is not used, per the phpdoc. In that case, what about:
--- a/src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php
+++ b/src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php
@@ -2135,7 +2135,7 @@ class WP_REST_Attachments_Controller extends WP_REST_Posts_Controller {
* @return string Filtered file name.
*/
private static function filter_wp_unique_filename( $filename, $dir, $number, $attachment_filename ) {
- if ( empty( $number ) || ! $attachment_filename ) {
+ if ( ! is_int( $number ) || ! $attachment_filename ) {
return $filename;
}
@@ -2148,7 +2148,7 @@ class WP_REST_Attachments_Controller extends WP_REST_Posts_Controller {
}
$matches = array();
- if ( preg_match( '/(.*)(-\d+x\d+|-scaled)-' . (int) $number . '$/', $name, $matches ) ) {
+ if ( preg_match( '/(.*)(-\d+x\d+|-scaled)-' . $number . '$/', $name, $matches ) ) {
$filename_without_suffix = $matches[1] . $matches[2] . ".$ext";
if ( $matches[1] === $orig_name && ! file_exists( "$dir/$filename_without_suffix" ) ) {
return $filename_without_suffix;Addresses review feedback to assert the value of metadata['file'], not just its existence.
Avoids repeating the string literal for the array key in the enum assertion test.
Verifies that sideloading a scaled image retains the numeric suffix when a file with the same name already exists from a different attachment.
The $number parameter in filter_wp_unique_filename is typed as int|string. Casting to (int) before interpolation into the preg_match pattern ensures regex safety regardless of any future changes to what $number might contain.
|
@westonruter I believe I have addressed all of your feedback. Thanks! |
src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php
Outdated
Show resolved
Hide resolved
|
|
||
| $metadata['width'] = $size ? $size[0] : 0; | ||
| $metadata['height'] = $size ? $size[1] : 0; | ||
| $metadata['filesize'] = wp_filesize( $path ); |
There was a problem hiding this comment.
Note that wp_filesize() is filterable and can return 0. Does it make sense to proceed with any of this if any of these are zero?
Should these checks be done first and then if all of them aren't zero, then proceed with update_attached_file( $attachment_id, $path )? Otherwise, if one is zero, short-circuit with an error?
There was a problem hiding this comment.
maybe, let me check the existing pattern in core since i'm just trying to store meta data for the image.
src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php
Show resolved
Hide resolved
|
|
||
| $matches = array(); | ||
| if ( preg_match( '/(.*)(-\d+x\d+)-' . $number . '$/', $name, $matches ) ) { | ||
| if ( preg_match( '/(.*)(-\d+x\d+|-scaled)-' . (int) $number . '$/', $name, $matches ) ) { |
There was a problem hiding this comment.
I'll move the changes there here, the change belongs here
src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php
Outdated
Show resolved
Hide resolved
Co-authored-by: Weston Ruter <westonruter@gmail.com>
Co-authored-by: Weston Ruter <westonruter@gmail.com>
Check whether _wp_attached_file already matches $path before calling update_attached_file(), since a false return could mean the value is unchanged. Return a WP_Error when the meta value differs but the update still fails.
Per review feedback, use ! is_int( $number ) as the guard since $number is either an int or an empty string. This is more precise than empty() and allows removing the (int) cast in the regex since $number is guaranteed to be an int.
Checks image dimensions and filesize before calling update_attached_file() to avoid leaving the attachment in a bad state if the scaled file is unreadable or empty.
Move the literal dash outside the capture group so the regex reads `/(.*)-(\d+x\d+|scaled)-/` instead of alternating `(-\d+x\d+|-scaled)`. This keeps the dash handling consistent and simplifies the filename reconstruction. Props westonruter. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
westonruter
left a comment
There was a problem hiding this comment.
One last suggestion, but otherwise pre-approving.
|
|
||
| // Update the attached file to point to the scaled version. | ||
| if ( | ||
| get_post_meta( $attachment_id, '_wp_attached_file', true ) !== $path && |
There was a problem hiding this comment.
Gemini wisely pointed out that the _wp_attached_file post meta is stored as a relative path, whereas $path is an absolute path. So this actually will never be equal. It suggests this instead, which also looks cleaner:
| get_post_meta( $attachment_id, '_wp_attached_file', true ) !== $path && | |
| get_attached_file( $attachment_id, true ) !== $path && |
The true prevents filters from applying.
Summary
When client-side media processing handles big image scaling, the client creates a
-scaledversion and sideloads it back via the REST API. The sideload route'simage_sizeenum was missingscaled, causing 400 validation errors.This PR:
'scaled'to theimage_sizeenum in the sideload route registrationsideload_item()to record the original file asoriginal_imageand update the attachment to point to the scaled versionfilter_wp_unique_filename()regex to recognize the-scaledsuffix, preventing unwanted numeric suffixesTest plan
original_imageand the scaled file dimensionsTrac ticket: https://core.trac.wordpress.org/ticket/64737