Skip to content

Stats: give the Traffic lists a third row so they show their ten entries - #54603

Open
dognose24 wants to merge 5 commits into
trunkfrom
update/stats-484-dashboard-row-height
Open

dognose24 wants to merge 5 commits into
trunkfrom
update/stats-484-dashboard-row-height

Conversation

@dognose24

@dognose24 dognose24 commented Nov 6, 2026 •

Copy link
Copy Markdown
Contributor

Fixes STATS-484

Proposed changes

Customers compared the Stats v2 widgets with classic Stats and found them short: Top posts showed six entries where classic showed ten. Every default tile was two rows tall whatever it held. This PR gives each kind of tile a named default height, in src/dashboard-layout.php:

  • DASHBOARD_TILE_STRIP (1 row): the highlights strips.
  • DASHBOARD_TILE_CARD (2 rows, the height every tile had): charts and figures.
  • DASHBOARD_TILE_LIST (3 rows, 632px): a leaderboard with room for the ten rows the stats endpoints return. Measured on the live tiles: a 72px header, a 46px footer, a 24px column header and 44px rows.

Traffic, Insights and Subscribers use them in default-dashboard-sections.php; the Ads, WooCommerce and VideoPress registrants use the same constants. On Traffic every tile below the chart is a list, Devices and Top platforms included: a shorter tile beside taller ones leaves a hole and pushes the next column out of step, and since the column count follows the page width no ordering keeps short tiles together, so one height per row is what lines the rows up. Devices gains some whitespace under its donut.

The row unit stays 200px. An earlier revision of this PR moved it to 40px so a resize could land closer to a list's height; review on Slack (p1793949879884499-slack-C06FSDTSN82) pointed out that the lists can show their entries by taking one more row at the current unit, and that smaller steps and widget min/max sizes belong upstream (gutenberg#85239), so that half was dropped along with the saved-layout rescale it needed. Layouts readers already customized are untouched.

Related product discussion/links

  • STATS-484
  • p1793949879884499-slack-C06FSDTSN82

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

No.

Testing instructions

Run against a site with Stats v2 enabled (Jetpack or the standalone Stats plugin), as a user who has not customized the dashboard:

  • Open Stats v2 → Traffic. Every tile below the Traffic summary is three rows tall (632px); the lists show ten entries when the period has that many, and the rows line up at every window width.
  • Insights: Year in review stays one row; the two most-commented lists are three rows, the rest two. Subscribers: the two lists are three rows. WooCommerce: top products, visitors by location, the three UTM lists and sales by coupon are three rows. Ads: unchanged.
  • A user who customized a tab before this PR sees their own layout, unchanged.

Before / After

Same site, same Last 12 months window, 1440px wide.

Before (trunk): every tile two rows; Top pages shows six entries.

stats-484-before-trunk

After: every Traffic tile below the chart three rows, rows line up; the lists have room for ten entries.

stats-484-after

On a site with little data the taller lists show whitespace (Top UTM, Top links clicked, Top videos above): that is the cost of one height per row, which keeps the rows aligned at every column count.

Tests: jp test php packages/premium-analytics (825 pass), packages/videopress, packages/ads, packages/woocommerce-stats; PHPCS on the touched files.

🤖 Generated with Claude Code

…ries

Customers found the Stats v2 widgets short next to classic Stats: Top
posts showed six entries where classic showed ten. widget-dashboard
0.11.0 stopped snapping the row height to its presets, so the dashboard
moves from 200px to 40px rows and each default tile takes the height
its content needs: strips 4 rows, charts and figures 8 (the height every
tile had), leaderboards 11 (600px, exactly ten rows). The Ads, Woo and
VideoPress registrants use the same constants.

Layouts saved on the old rows are rescaled once on read, keeping their
pixels; the once-per-reader mechanics move from Stored_Layout_Move into
a shared base that runs every rewrite on one raw read, rescale first.
On commit a tile the package inserted at two rows, or resized below the
strip, is settled to a usable height.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@dognose24
dognose24 requested review from a team as code owners November 6, 2026 03:57
@dognose24 dognose24 added Enhancement Changes to an existing feature — removing, adding, or changing parts of it [Status] Needs Review This PR is ready for review. labels Nov 6, 2026
@dognose24 dognose24 self-assigned this Nov 6, 2026
@github-actions

github-actions Bot commented Nov 6, 2026 •

Copy link
Copy Markdown
Contributor

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), and enable the update/stats-484-dashboard-row-height branch.
  • To test on Simple, run the following command on your sandbox:
bin/jetpack-downloader test jetpack update/stats-484-dashboard-row-height

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

@github-actions

github-actions Bot commented Nov 6, 2026 •

Copy link
Copy Markdown
Contributor

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!


Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

  • WordPress.com Simple releases happen as soon as you deploy your changes after merging this PR (PCYsg-Jjm-p2).
  • WoA releases happen weekly.
  • Releases to self-hosted sites happen monthly:
    • Scheduled release: December 8, 2026
    • Code freeze: December 7, 2026

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.


Premium Analytics plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.


Stats Data plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

@jp-launch-control

jp-launch-control Bot commented Nov 6, 2026 •

Copy link
Copy Markdown

Code Coverage Summary

This PR did not change code coverage!

That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷

Full summary · PHP report · JS report

@dognose24
dognose24 requested a review from adamwoodnz November 6, 2026 04:26
Phan flagged the static call through a class name as possibly abstract.
Each subclass now registers a closure bound to itself, and the base
carries a no-op rewrite so the call is concrete.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@dognose24
dognose24 requested a review from retrofox November 6, 2026 05:11
dognose24 and others added 2 commits November 6, 2026 14:41
A 432px tile beside 600px ones left a hole under Devices and pushed
the third column 168px out of step for the rest of the page. Every
Traffic tile below the chart is now 600px, so rows line up at any
column count; Top platforms is a list anyway, Devices gains whitespace.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Review on the row change: shrinking the row unit belongs upstream, where
min/max widget sizes are in progress, and the lists can show their ten
entries by adding a row at the current height. So the dashboard keeps
its rows, and with them go the saved-layout rescale and the on-commit
height settling. What stays is one named height per kind of tile:
strips one row, cards two (as before), lists three.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@dognose24 dognose24 changed the title Stats: lay the dashboard out on 40px rows so lists show their ten entries Stats: give the Traffic lists a third row so they show their ten entries Nov 6, 2026
const DASHBOARD_TILE_STRIP = 1;

/**
* A chart, a figure or a short list: the height every tile had before lists got taller.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need to document past state

Suggested change
* A chart, a figure or a short list: the height every tile had before lists got taller.
* A chart, a figure or a short list

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Taken in 0114a7a.

@adamwoodnz adamwoodnz left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more thought on the stored-layout side, inline.

![A section declares its default layout; get_default_layout() runs it through the default-layout filter, where a plugin adds instances at priority 10 and the package removes unsupported widget types at priority 100, before it reaches the client as the fallback for the stored layout.](diagrams/sections-default-layout.svg)

A section owns its default layout. The registration passes the instances, built with `get_dashboard_default_widget_instance( $uuid, $type, $order, $width, $height, $attributes )`, as an array or as a callable returning one.
A section owns its default layout. The registration passes the instances, built with `get_dashboard_default_widget_instance( $uuid, $type, $order, $width, $height, $attributes )`, as an array or as a callable returning one. `$height` counts dashboard rows: pass `DASHBOARD_TILE_LIST` for a leaderboard, `DASHBOARD_TILE_CARD` for a chart or a figure, `DASHBOARD_TILE_STRIP` for a one-line strip.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should fix: the default layout is only the fallback for a stored layout, so anyone who has rearranged their dashboard keeps 2-row lists and still sees a truncated ten. I think leaving saved arrangements alone is the right call, since rewriting someone's own layout is worse. But it decides who the fix reaches, so it is worth a sentence here: the DASHBOARD_TILE_* heights apply to the default layout, and a stored layout keeps the heights it was saved with.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, and that is the better trade: a first revision rescaled stored layouts and it was more machinery than the change deserved. Added the sentence in 0114a7a, in the $height paragraph of the sections guide.

adamwoodnz
adamwoodnz previously approved these changes Nov 9, 2026

@adamwoodnz adamwoodnz left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @dognose24, I have mixed feelings about the extra whitespace this leaves, especially for small shops or early sites, but layout customization allows admins to expand or contract lists if they need to, so it goes both ways. It's a shame there is a little extra space below the 10 items:

Image

Code-wise it LGTM

The card docblock stops describing past state, and the sections guide
says the heights apply to the default layout only: a stored layout
keeps the heights it was saved with.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Docs Enhancement Changes to an existing feature — removing, adding, or changing parts of it [Package] Ads [Package] Premium Analytics [Package] VideoPress [Package] Woocommerce Stats [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/ [Plugin] Premium Analytics [Plugin] Stats Data [Status] Needs Review This PR is ready for review. [Tests] Includes Tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants