DataViews: Make grid and table item preview aspect ratio configurable

[vianasw]

What?

See #60891

The DataViews grid layout renders item previews (the media field) at a hard-coded 1/1 (square) aspect ratio, and the table layout does the same for the primary column's media preview. This adds an aspectRatio option to the grid and table layout configs so consumers can choose the shape, defaulting to 1/1 so nothing changes for existing consumers.

Why?

#60891 asks for the grid preview aspect ratio to be consumer configurable — a square crop isn't ideal for every dataset (tall templates, wide media, video thumbnails, etc.). For example, a video library wants 16/9 previews so the thumbnail matches how the video actually appears.

A previous attempt (#63487) stalled on the UX of a user-facing toggle between 1/1 and auto (variable per-item ratios), which raised "visual rivers" / masonry concerns. This PR deliberately sidesteps that debate: it exposes a single consumer-set, uniform aspect ratio, applied identically to every item — the form even the prior reviewers were comfortable with ("it should change the aspect ratio of all previews"). The user-facing toggle and auto/variable per-item ratios are intentionally left as a follow-up.

Scope is limited to the grid and table layouts; pickerGrid/pickerTable parity is a straightforward follow-up.

How?

• Adds aspectRatio?: MediaAspectRatio to ViewGrid['layout'] and ViewTable['layout'], where MediaAspectRatio is a union of preset ratios ('1/1' | '4/3' | '3/4' | '3/2' | '2/3' | '16/9' | '9/16', mirroring Core's default aspect-ratio presets) — the same constrained-union pattern as density. Starting with presets keeps the API easy to widen later without a breaking change, and avoids consumers setting degenerate ratios.
• The value is surfaced as a --wp-dataviews-media-aspect-ratio CSS custom property (matching the existing --wp-dataviews-color-background naming) on the layout root (the grid container — both the standard and infinite-scroll roots — and the table element). The property is always set, defaulting to 1/1, so a same-named variable set by a consumer on an ancestor can't leak into the previews.
• Grid: the existing .dataviews-view-grid__media rule reads it with a 1/1 fallback: aspect-ratio: var(--wp-dataviews-media-aspect-ratio, 1/1).
• Table: gated behind a has-media-aspect-ratio modifier (same pattern as has-*-density) that the table only carries when the view sets layout.aspectRatio. Under the modifier, the .dataviews-column-primary__media wrapper takes height + aspect-ratio, with the img filling it — sizing the wrapper rather than the img keeps custom media field renders (nested elements instead of a bare img) covered too. Row heights are unchanged; the preview widens instead, and a 16/9 preview at the default height still fits the wrapper's existing max-width. Without aspectRatio, the base rules are exactly what trunk ships today.
• Net effect: every existing consumer is unaffected — the grid keeps its 1/1 default and the table keeps its current sizing until a view opts in.

Testing Instructions

1. In a grid DataView, set the layout's aspectRatio, e.g. view = { type: 'grid', layout: { aspectRatio: '16/9' }, … }.
2. Confirm the item previews render at the configured ratio (16:9 rectangles) instead of squares, with rows staying aligned (uniform heights).
3. Try other fixed ratios (e.g. '4/3', '1/1') and confirm they apply uniformly to every item.
4. In a table DataView with a media field, set layout.aspectRatio: '16/9' and confirm the primary column's thumbnail renders 16:9 at the same height — row heights don't change.
5. Remove aspectRatio (or use an existing grid/table consumer such as the Pages/Templates views) and confirm previews stay square (1/1) — no regression.
6. Confirm previewSize and density still work alongside it.

Testing Instructions for Keyboard

No interaction changes — the option only affects preview dimensions, so existing keyboard navigation of the grid and table is unaffected.

Screenshots or screencast

Before (1/1)	After (aspectRatio: '16/9')
Square previews	16:9 previews

Use of AI Tools

This PR was authored with the assistance of AI tooling (Claude Code). The implementation, scope decisions, and this description were AI-assisted and reviewed by me before submission; I take responsibility for the contents.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @vianasw! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[github-actions]

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 props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @vianasw.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: vianasw.

Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ntsekouras]

Thanks for the PR! Let's also get some design feedback (@WordPress/gutenberg-design) and maybe @oandregal has thoughts too.

[jasmussen]

At a glance, this seems valid enough to me, assuming it looks good with image-less placeholders too. It also addresses a point raised by Jay, who has worked with DataViews long enough that I trust his previously asserted instincts. 👍

[ntsekouras]

We'd need to update view-config schema to include this new prop.

I think it's fine to handle as a follow-up, as there's no functional impact in the meantime. It also involves a couple of extra small changes, because the PHP layout schemas are shared between table/pickerTable and grid/pickerGrid while the new prop doesn't apply to the picker layouts, so there's a small decision about whether to split them. I can pick this up. @oandregal are you fine with a follow up for the schema changes?

[ntsekouras]

This LGTM. Thanks for effort and the iterations! Great work!

[oandregal]

👍 to prepare a follow-up with the schema changes. Heads up that I'm working on generating the docs and the PHP schema from the JSON schema at #81168 so, depending on timing, one of them will need rebase.

[ntsekouras]

👍 to prepare a follow-up with the schema changes. Heads up that I'm working on generating the docs and the PHP schema from the JSON schema at #81168 so, depending on timing, one of them will need rebase.

Sounds good. I can open the follow up after your changes have landed.

[github-actions]

Congratulations on your first merged pull request, @vianasw! We'd like to credit you for your contribution in the post announcing the next WordPress release, but we can't find a WordPress.org profile associated with your GitHub account. When you have a moment, visit the following URL and click "link your GitHub account" under "GitHub Username" to link your accounts:

https://profiles.wordpress.org/me/profile/edit/

And if you don't have a WordPress.org account, you can create one on this page:

https://login.wordpress.org/register

Kudos!