REST API: expose size-aware encode quality on attachment responses

[adamsilverstein]

Client-side media processing (introduced for the editor) encodes image sub-sizes in the browser. To produce output consistent with server-side processing it needs to know the encode quality the site has configured, but that value is currently not exposed anywhere in the REST API. As a result, browser-side encoding falls back to a hardcoded default and the ​wp_editor_set_quality filter is silently ignored for these images.

wp_editor_set_quality has been size-aware since 6.8 — its signature is ( int $quality, string $mime_type, array $size ) — so a site can return a different quality per dimension (for example, a lower quality for thumbnails). A single flat value cannot represent that.

Proposed change

Add an image_quality field to the media attachment REST response (WP_REST_Attachments_Controller), in the edit context, alongside the existing exif_orientation field:

"image_quality": {
  "default": 82,
  "sizes": { "thumbnail": 60 }
}

• The filter is resolved against the output MIME type (after image_editor_output_format), the same way WP_Image_Editor::set_quality() does.
• default is the filtered quality for the full-size image.
• Each registered sub-size is re-filtered with that size's dimensions; a size is reported under sizes only when its value diverges from default, keeping the response payload small.
• The field is readonly and limited to the edit context, matching exif_orientation.

This mirrors the pattern already used for exif_orientation, keeping per-file image-processing decisions in the attachment response where the real filename, MIME type and dimensions are available.

Patch / PRs

• Core PR: ​https://github.com/WordPress/wordpress-develop/pull/11856
• Gutenberg consumer PR: ​https://github.com/WordPress/gutenberg/pull/78420
• Related Gutenberg issue: ​https://github.com/WordPress/gutenberg/issues/78419
• Follows the same approach as the earlier image_editor_output_format work (Gutenberg ​#75784 / ​#75793).

Tests

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

• test_image_quality_schema — field is present, typed, readonly, edit-context.
• test_image_quality_default_in_response — JPEG default is 82, empty sizes with no filter.
• test_image_quality_with_size_aware_filter — a size-aware wp_editor_set_quality filter is reflected per size, and only divergent sizes are reported.
• test_get_item_schema — property count updated 32 → 33.

All pass locally (phpunit --filter test_image_quality,
phpunit --filter test_get_item_schema). phpcs clean.

## Summary

Adds an image_quality field to the media attachment REST response. It reports the value of the ​`wp_editor_set_quality` filter, resolved against the output MIME type (after image_editor_output_format):

• default — the filtered quality (1-100) for the full-size image
• sizes — per-registered-size overrides, included only where the filtered value diverges from default (keeps the payload small)

wp_editor_set_quality has 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_orientation field on the same controller.

## Trac ticket

Trac ticket: https://core.trac.wordpress.org/ticket/65274

## Backports from Gutenberg

• ​https://github.com/WordPress/gutenberg/pull/78420

## Testing

• phpunit --filter test_image_quality — schema, default, and size-aware-filter cases
• phpunit --filter test_get_item_schema — property count updated 32 → 33

---

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.

[audrasjb]

Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.

[desrosj]

Since this is an enhancement, there's no first version of WordPress this can be reproduced in. Removing trunk version.

Pushed updates addressing the review:

• @TimothyBJacobs extracted the shared logic into wp_get_image_encode_quality( $mime_type, $size, $default_quality ) in wp-includes/media.php. It resolves the quality the same way WP_Image_Editor::set_quality() does (per-format default → wp_editor_set_quality → jpeg_quality for JPEG → clamp to 1-100), so the REST field no longer re-derives that logic for the full size and each sub-size.
  • I left WP_Image_Editor::set_quality() itself untouched here: the canonical docblocks for wp_editor_set_quality/jpeg_quality live in that method and are referenced across core via "documented in wp-includes/class-wp-image-editor.php", so having set_quality() adopt the helper is cleaner as a follow-up. Happy to do it in this PR if you'd prefer.
• @westonruter the reported value now includes jpeg_quality for JPEG output, the schema integers are bounded 1-100, and sizes enumerates the registered sub-sizes.
• Added unit tests for the helper (defaults, both filters, out-of-range clamping) and a jpeg_quality case on the REST response.

[adamsilverstein]

Duplicate of #65262.