We recently normalized generated thumbnail sizes so that requested widths coalesce to the configured $wgThumbnailSteps values. Thumbnail download links already follow that normalization, but some media API responses still derive their image variants from user image-limit preferences rather than the approved thumbnail steps.
That mismatch is now a conceptual problem as well as a behavioral one. For images, we need to distinguish between two different kinds of size:
- Display size: the visual size an image should be rendered at for a client or user preference.
- Generated thumbnail size: the backend thumbnail size we actually produce, which must be normalized to $wgThumbnailSteps.
Historically, those concepts were effectively the same because the backend could generate arbitrary thumbnail widths. With normalized thumbnail generation, they can no longer be treated as interchangeable.
This task tracks the work to introduce an explicit way to obtain normalized thumbnail limits from MediaFileTrait, and to update API handlers that expose thumbnail-oriented links so they return preferred/generated thumbnail URLs based on normalized thumbnail sizes rather than raw user image-limit values.
Initial scope:
- Add a MediaFileTrait helper for normalized thumbnail limits based on $wgThumbnailSteps.
- Update REST handlers to use thumbnail sizes:
- /v1/file/{title} -- Fix thumbnail output to adhere to the thumbnail limits.
- /v1/page/{title}/links/media Fix preferred output to adhere to the thumbnail limits
- Preserve the distinction between display-oriented sizing and thumbnail-generation sizing so call sites can choose the correct behavior explicitly.
Follow-up:
- Audit additional endpoints and trait consumers that still assume one “image size” concept.
Expected outcome
Media API responses that advertise thumbnail/preferred image links should consistently return both correct URLs as well as correct width/height dimensions for approved normalized thumbnail sizes, while still allowing endpoints to expose display-oriented dimensions where that is the correct semantic.