REST API: Expose size-aware encode quality on attachment responses#11856
REST API: Expose size-aware encode quality on attachment responses#11856adamsilverstein wants to merge 1 commit into
Conversation
Add an image_quality field to the media attachment REST response reporting the wp_editor_set_quality value resolved against the output MIME type. The default value applies to the full-size image; per-registered-size overrides are listed under sizes only where the filtered value diverges from the default. This lets client-side media processing encode images at the quality the site has configured, instead of a hardcoded default, mirroring the existing exif_orientation field. Props adamsilverstein.
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. |
|
Should there be a helper function extracted? Looks like quite a bit of logic that will need to stay in sync. |
My understanding is that the code will only live in Gutenberg only to support older WordPress versions where the helper wouldn't be available. I believe they only support back a few versions (2?) though, so it can get removed from Gutenberg after some time. Although a helper still might be useful to contain the logic, will consider. |
| /** This filter is documented in wp-includes/class-wp-image-editor.php */ | ||
| $full_quality = (int) apply_filters( | ||
| 'wp_editor_set_quality', | ||
| $default_quality, | ||
| $output_mime, | ||
| array( | ||
| 'width' => $full_width, | ||
| 'height' => $full_height, | ||
| ) | ||
| ); |
There was a problem hiding this comment.
Shouldn't this also afterward apply the jpeg_quality filter for image/jpeg? This is what WP_Image_Editor::set_quality() does. Same goes for below.
| 'readonly' => true, | ||
| 'properties' => array( | ||
| 'default' => array( | ||
| 'type' => 'integer', |
There was a problem hiding this comment.
| 'type' => 'integer', | |
| 'type' => 'integer', | |
| 'minimum' => 1, | |
| 'maximum' => 100, |
| 'sizes' => array( | ||
| 'type' => 'object', | ||
| 'additionalProperties' => array( | ||
| 'type' => 'integer', |
There was a problem hiding this comment.
| 'type' => 'integer', | |
| 'type' => 'integer', | |
| 'minimum' => 1, | |
| 'maximum' => 100, |
| ), | ||
| 'sizes' => array( | ||
| 'type' => 'object', | ||
| 'additionalProperties' => array( |
There was a problem hiding this comment.
Alternatively, this could use patternProperties if we wanted to encode all of the image sizes in a regex. But since the image sizes are all known beforehand via wp_get_registered_image_subsizes(), could this not actually explicitly provide all of the sizes?
3 participants
Summary
Adds an
image_qualityfield to the media attachment REST response. It reports the value of thewp_editor_set_qualityfilter, resolved against the output MIME type (afterimage_editor_output_format):default— the filtered quality (1-100) for the full-size imagesizes— per-registered-size overrides, included only where the filtered value diverges fromdefault(keeps the payload small)wp_editor_set_qualityhas been size-aware since 6.8 (( int $quality, string $mime_type, array $size )), so the filter is re-applied per registered sub-size using that size's dimensions.This lets client-side media processing (which encodes sub-sizes in the browser) honor a site's configured encode quality instead of a hardcoded default, mirroring the existing
exif_orientationfield on the same controller.Trac ticket
Trac ticket: https://core.trac.wordpress.org/ticket/65274
Backports from Gutenberg
wp_editor_set_qualityvalue in the upload response gutenberg#78420Testing
phpunit --filter test_image_quality— schema, default, and size-aware-filter casesphpunit --filter test_get_item_schema— property count updated 32 → 33Trac ticket: https://core.trac.wordpress.org/ticket/65262