My Jetpack: port the dashboard to wp-build behind a default-off flag (pilot) by dhasilva · Pull Request #52204 · Automattic/jetpack

dhasilva · 2026-09-10T18:02:18Z

Proposed changes

Ports the My Jetpack dashboard onto the wp-build pipeline, behind a feature flag that defaults to off. This is the pilot for JETPACK-2566; the traps it hit are written up for the porting checklist in JETPACK-2575.

The rule for this port is move the frame, keep the UI. The UI is unchanged apart from the frame itself.

One wp-build route at path: "/" whose stage.tsx renders the existing React tree with its HashRouter intact. Boot's router reads its path from a ?p= query parameter and never the hash, so every #/… deep link keeps working — ~56 references inside this monorepo, plus links from WordPress.com, support docs and upgrade emails. No URL changes.
Both menu registrations still resolve. Admin_Menu::add_menu in class-initializer.php and class-jetpack-manage.php are untouched; admin_page() became a dispatcher instead.
The screen ID is aliased only while wp-build's generated enqueue check runs, hooked on either side of that check, so other admin_enqueue_scripts callbacks and JITMs keep the real jetpack_page_my-jetpack ID.
?step=onboarding deliberately stays on the legacy path. It is a full-viewport takeover that hides all wp-admin chrome, so it has no frame to standardize. Verified that the flag does not change its behaviour.
Gated on the my-jetpack-wp-build feature flag, default off. Every user still gets today's dashboard. Enable it with wp companion feature-flag enable my-jetpack-wp-build, or locally with add_filter( 'jetpack_feature_flag_enabled_my-jetpack-wp-build', '__return_true' );.

Changes outside `packages/my-jetpack`

esbuild has no image loader and no config surface, and that follows the route's whole import graph — not just the ported package.

packages/connection and packages/licensing now serve their own illustrations from a committed assets/images/ directory, with the base URL published in admin script data (following packages/blaze's precedent). js-packages/connection and js-packages/licensing resolve their own URLs; no consumer passes anything. Data URIs were rejected here on measurement: those four total ~337KB gzipped, versus the ~22KB accepted for My Jetpack's own SVGs.
js-packages/components inlines the pricing table's header gradient as a data URI, because runtime-injected CSS resolves url(./gradient.svg) against /wp-admin/.
js-packages/config falls back to globalThis.jetpackConfig when the webpack external is missing. My Jetpack's boot init module sets it, so consumer_slug survives esbuild.
js-packages/connection drops the manage-connection dialog's link colors. @wordpress/ui injects Link's CSS at runtime, after every <link>, so they never won under webpack; bundled, they turned the links black.
packages/jitm: when a JITM placeholder isn't rendered, as on wp-build pages whose CSS hides it, the card now waits for #jp-admin-notices to mount instead of taking the hidden placeholder's spot. Pages with a visible placeholder behave as before.
tools/performance: the My Jetpack CodeVitals scenario waits for .jp-admin-page under either container, so it keeps working once the flag is on.

Effects on the default (flag-off) path

The flag is off, so every user takes the legacy path. Four deliberate, measured trade-offs reach it:

Legacy bundle +21.9KB gzipped (+46KB raw, +1.57%) from inlining 14 SVGs as data URIs, against 14 fewer HTTP requests on first load. Accepted as roughly neutral; reversible with a webpack resolve.alias if it turns out not to be.
The 13 raster illustrations lose cache-busting. They are now served from build/images/ at unhashed paths with no ver query, so an image changed by a plugin update can be served stale.
connection.assetsUrl, licensing.assetsUrl and myJetpack.assetsUrl are now added to window.JetpackScriptData on every wp-admin page of every plugin bundling those packages — three short strings. myJetpack.assetsUrl is registered even where My Jetpack itself is turned off, because the Jetpack plugin still renders its connection screen there.
Every plugin bundling My Jetpack ships the unused wp-build output: build/routes is ~8.7 MB on disk (content.min.js ~3 MB, 777 KB gzipped). It loads only when the flag is on, the same as the other wp-build pilots.

Otherwise unchanged: same script handle, same arguments, same three state payloads. The design tokens import moved from _inc/style.module.scss into a legacy-only _inc/design-tokens.scss; the legacy bundle already carried two identical copies of those tokens, so only their order changed.

Related product discussion/links

JETPACK-2567 (this pilot) — parent JETPACK-2566, acceptance rule JETPACK-2573, checklist JETPACK-2575

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

No. No new tracking, no new data collection. The three script-data keys added are asset base URLs.

Testing instructions

The flag is off by default, so first confirm nothing changed, then enable it and compare.

Before (flag off — this is what ships):

Go to Jetpack → My Jetpack. Everything should look and behave exactly as on trunk.
Go to Jetpack (?page=jetpack) while disconnected — the "link your WordPress.com account" screen should show its hero illustration. (This screen imports a My Jetpack component; an earlier revision of this PR broke its image, so it is worth an explicit look.)
Open the Jetpack plugin's disconnect dialog and the license activation screen — their illustrations should render.
Open a product interstitial with a pricing table (e.g. #/add-backup) — the featured column keeps its header gradient.

After (flag on):

add_filter( 'jetpack_feature_flag_enabled_my-jetpack-wp-build', '__return_true' );

Jetpack → My Jetpack now renders inside wp-build's rounded frame. The header, tabs, cards, and footer should be otherwise identical.
Click through Overview / Products / Help. The Products tab uses DataViews and should be fully styled.
Open a product interstitial, then press Back, then Forward. Reload directly on admin.php?page=my-jetpack#/add-backup. All should work — this is the nested-router check.
On the interstitials: the pricing table's featured column keeps its gradient, and the CRM and Anti-Spam logos keep their size.
Open the connection card's Manage dialog — its links use the brand color, not black.
In the Network tab, JITM requests still carry wp:jetpack_page_my-jetpack… message paths, and there is no 404 for a design-tokens.css under /wp-admin/.
Visit admin.php?page=my-jetpack&step=onboarding. On a connected site it redirects to #/overview, exactly as with the flag off.
Narrow the window below 782px and confirm the layout still behaves.

Verification already done

Measured on one site, one viewport, changing only the flag — computed styles and geometry diffed numerically rather than eyeballed, because a 4px change is invisible in a screenshot:

	legacy	wp-build
`#wpbody-content`	x160 w1265 h515	identical
`.jp-admin-page`	w1265 h515	w1257 h507
header	w1265 h72 pad 16/24	w1257 h72 pad 16/24
`.jetpack-footer`	w1265 h61 y486	w1257 h61 y478
notice paragraph	w908 h48 f16 lh24	identical
first tab	86.1875px	86.1875px
`body` font-family	Jetpack stack	identical

The only difference is a uniform 8px inset — the boot stage's gutter, which is the frame this port exists to adopt. Body content, typography and spacing are unchanged.

That comparison, extended to every route and dialog, plus live checks found and fixed these defects in this PR: a CJS/ESM interop failure that blanked the dashboard, a body font-family drift, missing charts and DataViews stylesheets, the pricing table gradient 404, logo heights overridden by boot's image reset, black manage-dialog links, a lost consumer_slug, a JITM message path renamed by the screen alias, and a design-tokens @import that 404'd on every load. The last two change no pixels, so they were caught by comparing requests rather than styles.

A later review, also checked live with the flag both off and on, fixed two more:

A JITM could land hidden. The JITM fetch starts about 400 ms before the app mounts #jp-admin-notices, and a faster response went into a placeholder that wp-build's CSS hides. Verified with an injected JITM: it now waits and renders inside #jp-admin-notices, and flag-off placement is unchanged.
Text outside the admin-ui page region inherited boot's #1e1e1e instead of wp-admin's #3c434a (the Connection screen's footer wordmark). The stage now pins #3c434a, and the Connection screen matches flag-off row for row.

🤖 Generated with Claude Code

https://claude.ai/code/session_016F3z1Uq6h1JiuGiGzo9iSZ
https://claude.ai/code/session_011KmSAEMRaHggqug6jHrvY2

github-actions · 2026-09-10T18:03:45Z

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:

Ensure all required checks appearing at the bottom of this PR are passing.
Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
You can use GitHub's Reviewers functionality to request a review.
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: October 6, 2026