Premium Analytics: fit Highlights at the minimum tile height

[chihsuan]

Proposed changes

Update Highlights widget to match design:

• Remove the Annual Highlights year selector.
• Hide the See report footer in wide cells when the widget body is under 140px tall.
• Use tighter spacing for wide metric tiles in one-row cells.

These changes let all four values fit at the minimum widget height. Taller widgets keep the See report footer and the roomier tile spacing.

The footer has to go in those cells rather than shrink: the body is 86px, the footer takes 31px of it, and the metric tile still needs 82px after the tighter spacing. Nothing fits both. The design prototype's height-1 Highlights carries no report link either.

Year selection moves to the per-section control in #50930 — the prototype has no in-widget year control at any size. Pointing these numbers at that selection is a follow-up once #50930 lands; until then the widget shows the most recent year. Narrow cells keep the report link and stay scrollable: four compact rows cannot fit in the available height whether or not the link is there, so dropping it would buy nothing. The default Insights layout uses height 2, so neither limitation affects the default experience.

Related product discussion/links

• WOOA7S-1846

Does this pull request change what data or activity we track or use?

No.

Testing instructions

• Run Storybook: cd projects/js-packages/storybook && pnpm run storybook:dev.
• Wide and short — all four values fit, no See report: http://localhost:50240/iframe.html?id=packages-premium-analytics-widgets-annualhighlights--widget-dashboard-with-widget&viewMode=story&args=widgetWidth%3A4%3BwidgetHeight%3A1%3BrowHeight%3A200
• Narrow and short — See report stays, rows scroll: same URL with args=widgetWidth%3A1%3BwidgetHeight%3A1%3BrowHeight%3A200

Before:

After:

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack or WordPress.com Site Helper), and enable the wooa7s-1846-highlights-h1-chrome branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack wooa7s-1846-highlights-h1-chrome

bin/jetpack-downloader test jetpack-mu-wpcom-plugin wooa7s-1846-highlights-h1-chrome

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[jp-launch-control]

Code Coverage Summary

No summary data is available for parent commit ad243da, so cannot calculate coverage changes. 😴

If that commit is a feature branch rather than a trunk commit, this is expected. Otherwise, this should be updated once coverage for ad243da is available.

Full summary · PHP report · JS report

[dognose24]

LGTM — reviewed and verified on a local docker site (dashboard + both detail pages).

Verified locally:

• Height-2 default: unchanged apart from the removed year selector; See report and roomy spacing intact.
• Wide × height-1: all four values fit on one row, footer hidden, tighter tiles — matches the PR screenshots.
• Narrow × height-1: See report stays, rows scroll — identical to trunk, as intended.
• Post/video detail highlights (the other MetricTileGrid consumers in wide height-1 cells, which the shared $widget-short-max-block-size threshold now also covers): the tightened tiles render fine there too.
• Nice touch converting the container queries to logical properties while extracting the shared thresholds.

3x1

Before	After

3x2

Before	After

Pre-existing bug this PR is well placed to fix (one line, not blocking): with the default Insights layout, the Highlights widget renders "Select at least one metric to display." while the Metrics dropdown shows every metric checked. The default layout instance is created without attributes (get_dashboard_default_widget_instance( 'default-annual-highlights-widget-instance', 'jpa/annual-highlights', 0, 2, 2 ) in src/dashboard-layout.php — no $attributes), and render.tsx passes attributes.metrics straight through with no fallback, so a missing attribute becomes an empty Set and zero tiles — while the inline control renders the unset state as all-checked, so the UI contradicts itself. Suggest metrics={ attributes.metrics ?? DEFAULT_HIGHLIGHT_METRICS } at the AnnualHighlightsReport call site (the constant already exists in widget.ts), either here since this PR reworks the widget anyway, or as a quick follow-up — happy to open it if you prefer. Repro note: toggling any metric off/on writes the attribute and masks the bug on that site afterwards, which is probably why it went unnoticed.

[chihsuan]

Thanks for the review! @dognose24

Good catch — folded it in.

• Root cause is an asymmetry in @wordpress/widget-dashboard: the settings controls fall back to example.attributes, but WidgetRender doesn't — and the PHP default instance omits the key entirely, so the control shows all four checked while render gets undefined.
• Matched site-overview's default-parameter approach rather than defaulting at the call site.
• Made the prop optional — it was typed required all along, only compiled because strict is off.