Jetpack Beta: modernize the admin UI with React, the WordPress design system, and the Abilities API

[enejb]

Fixes # N/A

Modernizes the Jetpack Beta Tester admin UI. The plugin was the last major Jetpack plugin with no JS build step: a set of server-rendered PHP templates, 268 lines of vanilla admin.js, and a hand-rolled 1299-line admin.css reimplementing old Calypso "dops-" styling. This replaces all of that with a React app built on the WordPress design system (@wordpress/ui + @automattic/jetpack-components AdminPage), backed by the WordPress Abilities API for all reads and actions.

Screenshots

	Before	After
Plugin overview
Manage a plugin
Updates available

Proposed changes

• Backend — WordPress Abilities API (src/abilities/class-beta-abilities.php): registers seven abilities — four reads (jetpack-beta/list-plugins, get-plugin, get-settings, list-updates) and three writes (activate-branch, update-settings, update-plugin). Adds the automattic/jetpack-wp-abilities dependency. All callbacks gate on update_plugins and preserve the multisite/network-admin access control from the old admin_page_load(). meta.mcp.public = false (installing PR code shouldn't be agent-callable). Registers without the global jetpack_wp_abilities_enabled rollout filter since the UI fully depends on these abilities.
• Frontend — React on @wordpress/ui (src/js/): a new webpack build (mirroring Protect) renders both screens — the plugin overview and the per-plugin branch picker. Uses AdminPage from @automattic/jetpack-components for the standard Jetpack header/footer + breadcrumb (the same chrome the Activity Log uses). The overview leads with a welcome/intro card and a compact, single-card plugin list (divider-separated link rows). Branch activation, search/filter, settings toggles, the pending-updates panel, and the "To Test"/"What changed" panels are all React.
• Compact lists: both the plugin list and the branch picker are one bordered @wordpress/ui Card with divider-separated rows (shared jetpack-beta-list styles) rather than a stack of separate cards — tighter and easier to scan.
• Running version: every plugin row (overview) and branch row (manage) shows the concrete active version — including the underlying build for dev channels like Bleeding Edge / Release Candidate, not just the channel label.
• Pending updates: when a managed plugin has a newer build available it surfaces as a non-dismissable info (info) @wordpress/ui Notice with an in-place Update action, on both the overview and the per-plugin screen.
• Feature-branch search: the Feature Branches box matches by branch name, PR number, or a pasted GitHub pull-request URL (surfacing each branch's PR number from the ability).
• Removed the legacy screen templates, admin.js, updates.js, and admin.css (kept the first-run banner + exception templates). The three Admin::show_toggle* helpers are kept as _deprecated_function() shims rather than deleted.
• UX: plugin list is preloaded from the server bootstrap (window.JetpackBeta.plugins) for an instant first paint, then revalidated against the cache-bypassing list-plugins ability (stale-while-revalidate, no client-side storage); compact-list skeleton loaders instead of a spinner; each list row is a real link (keyboard + middle/Cmd-click) with wordpress.org icons (generic fallback for unpublished plugins); pinned header/footer with the content scrolling; the footer reuses the shared JetpackFooter (new showDefaultLinks prop) without the Products/Help links; mobile horizontal-scroll fixed.
• Global Autoupdates / Email Notifications settings now appear only on the overview screen (they are site-wide, not per-plugin).

Hardening & review follow-ups

• Security: activate-branch validates source via a schema enum and catches InvalidArgumentException (clean WP_Error instead of a 500); update-plugin restricts the target to the Beta-managed update set so the ability can't drive arbitrary updates; server-rendered "To Test"/"What changed" HTML is run through wp_kses_post() before delivery (it is injected via dangerouslySetInnerHTML).
• Accessibility: section/panel/settings titles render as real <h2> headings under the breadcrumb <h1>; external links announce "(opens in a new tab)".
• i18n: the mu-plugin notice and the "Currently Running" title use createInterpolateElement / sprintf instead of concatenated fragments.
• Self-update reload: activating a branch of — or updating — Jetpack Beta Tester itself returns a reload flag, and the UI does a full page reload rather than a soft view refresh, since the running app's own PHP/JS was just swapped.
• Static analysis: dropped the @phan-file-suppress for the Abilities API symbols — they resolve at the minimum tested WordPress (6.9), so the suppression was unused.

Related product discussion/links

• N/A

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

This removes the legacy data-jptracks-* events that were attached to the old action links (Manage / Activate / toggle). It does not add any new analytics or collect new data. It does add a new REST surface under wp-abilities/v1 for the abilities listed above — all capability-gated (update_plugins) and not exposed to MCP agents (meta.mcp.public = false).

Testing instructions

A live Jurassic Ninja test site is running this branch (Jetpack connected):

• Autologin: https://really-personal-haddock.jurassic.ninja/?auto_login → Beta Tester in the admin menu.

Steps:

1. Go to Jetpack → Beta Tester. Note the welcome/intro card, the Settings panel, and the compact plugin list — it paints instantly (preloaded); each row shows the plugin's icon, current version/state, and a chevron, and the whole row is a link to the manage screen (try middle-click / Cmd-click).
2. Toggle Autoupdates / Email Notifications in the Settings panel — they persist and the email toggle only shows when autoupdates is on.
3. Click a plugin (e.g. Jetpack) to open the manage screen. Confirm the breadcrumb (Beta Tester / ), the Currently Running card, the compact branch list (Latest Stable / Release Candidate / Bleeding Edge — each showing its concrete version) with Activate, the Feature Branches / Released Versions search, and the "To Test" panel.
4. In Feature Branches, search by branch name — or paste a PR number / GitHub pull-request URL — then Activate a branch and confirm it installs/activates and the view refreshes.
5. If a managed plugin has a newer build, confirm the info "update available" Notice appears and its Update action updates the plugin in place.
6. Resize to a phone width — there should be no horizontal scrollbar; the footer stays pinned at the bottom.

Note: the Beta plugin has no PHPUnit harness today, so this PR adds no automated tests — a Beta_Abilities registration/permission test is a sensible follow-up. Build/typecheck/eslint/stylelint/phpcs/phan all pass.

[manzoorwanijk]

I created a JN site and set the beta tester to this branch but I see WSOD on the beta tester page, with https://*.jurassic.ninja/wp-content/plugins/jetpack-beta-dev/build/index.js?minify=false&ver=7.0 pointing to 404

[ilonagl]

This looks great, Enej!!

I liked and appreciated the time when things where last updated, as it helps to orient yourself. Would it possible to include it in the new version?

[keoshi]

Looks great, @enejb!

A couple of thoughts:

Plugin overview

• Love the addition of the icons!
• I liked how compact the previous structure was. Is there any way to have all the plugins inside a single card like we did in Social? Social: modernize Add-account modal + connected-accounts onto WPDS (#48824 PR 2.5) #48833
• Badge could be placed next to the chevron, vertically aligned.

Manage a plugin

• We're missing the settings on this page. Were they global, or respective to the selected plugin?
• CTAs could be using the accent color.
• How does it look like when a feature branch or a release version are selected?

Updates available

• Notice could be informational (info) instead of a warning.

[simison]

It would be pretty simple to just add a feature that doesn't include those links, so you wouldn't need to duplicate the component, which is just more effort to maintain consistency and sort of against the whole idea of having central components like that. ;-)

jetpack/projects/js-packages/components/components/jetpack-footer/index.tsx

Lines 27 to 46 in 8572d40

	const JetpackFooter: FC< JetpackFooterProps > = ( { className, menu, ...otherProps } ) => {
	let items: JetpackFooterMenuItem[] = [];
	if ( ! isWpcomPlatformSite() && ! window?.JetpackNetworkAdminData ) {
	items = [
	{
	label: __( 'Products', 'jetpack-components' ),
	href: getAdminUrl( 'admin.php?page=my-jetpack#/products' ),
	},
	{
	label: __( 'Help', 'jetpack-components' ),
	href: getAdminUrl( 'admin.php?page=my-jetpack#/help' ),
	},
	...items,
	];
	}
	if ( menu ) {
	items = [ ...items, ...menu ];
	}

[enejb]

Good call — done in 8bcfc7c. Added a showDefaultLinks prop (default true, so every existing consumer is unchanged) to the shared JetpackFooter and used <JetpackFooter showDefaultLinks={ false } /> here, dropping the duplicate footer.tsx and its now-redundant CSS.

[simison]

Worth adding issue link here:

• UI: Add Breadcrumb component (adapted from admin-ui) WordPress/gutenberg#77039

[enejb]

Done in 8bcfc7c — linked WordPress/gutenberg#77039 in the renderBreadcrumbs docblock.

[simison]

Note that Card.Title already sets styles so you don't need the <Text> here.

If you do need it, the variant should prolly be header-* instead since you're rendering it as h2?

[enejb]

Done in 8bcfc7c — collapsed to <Card.Title render={ <h2 /> }>…</Card.Title> so Card.Title does the styling and we keep the heading semantics; removed the redundant nested <Text>.

[simison]

Would one of these options work?

• onClick sets document.location.href?
• You'd use Link component instead of Button?

Noting that we'll need the Link button component:

• UI: Add LinkButton, IconLinkButton components WordPress/gutenberg#77098

[enejb]

This is intentionally a link styled as a button (it navigates to the bug-report URL), so a real <a> is the correct element — onClick+document.location would drop middle/Cmd-click and copy-link, and a plain Link reads as text rather than a button. Added a comment referencing WordPress/gutenberg#77098 in 8bcfc7c so we can switch to a first-class link-button when it lands.

[simison]

Might be a good point to add wp-build instead here. ;-)

[enejb]

Great suggestion. This turns out to be a sizeable refactor — the JS would need restructuring into a wp-build sub-package and class-admin.php rewired from Assets::register_script() + index.asset.php to the generated build/build.php handle, and beta would be the first projects/plugins/* to adopt @wordpress/build (all current adopters are packages). To keep this PR focused on the UI modernization, I am splitting the wp-build migration into a dedicated follow-up PR — it also makes a nice before/after of @automattic/jetpack-webpack-config vs @wordpress/build.

[anomiex]

The plugin was the last major Jetpack plugin with no JS build step

You say this like it's a bad thing.

268 lines of vanilla admin.js, and a hand-rolled 1299-line admin.css

I'm not sure that replacing it with 1331 lines of TypeScript and some heavyweight external dependencies, resulting in replacing the 8.2K admin.js with 125K of bundled JS, is really a win for a developer-facing tool.

This seems to add a lot more moving parts that could break when someone is trying to debug plugins on their site.

[tbradsha]

I haven't looked at the code, but have similar concerns to Brad on the amount of added code (and this is before implementing with wp-build). For a dev plugin, I much prefer simple.

I tried to spin up a JN site, but it gave a blank screen (404 on index.js). Some thoughts on the UI based on the screenshot:

• The main page is already long, and the new cards make it longer (more scrolling). What would a table view look like?
• It seems to no longer show which version the release candidate/bleeding edge is?
• The email notifications/auto-updates bar probably doesn't need a full card of space. Also, I notice before it showed on the manage page...is it only a global setting or is it also a per-plugin setting?
• The "Stable"/"Dev" badges are a nice indicator at a glance.
• Should the footer say "Jetpack"?
• For the "new" screenshot, the Jetpack Beta Tester shows "Stable", but presumably you're running branch version of it?
• Is this using the Core-themed components (see p1HpG7-xN8-p2)? It seems to be missing the blues that were added in a lot of the other plugins lately.

[anomiex]

The minimum version we test against is 6.9 since #49021, this suppression shouldn't be needed anymore.

[enejb]

Good catch — removed the suppression in 6901a1e. Phan passes without it now that the minimum tested WordPress is 6.9 (Abilities API symbols resolve).

[anomiex]

This doesn't do the right thing if Jetpack Beta Tester itself is the plugin that was activated. The fancy React UI doesn't reload.

[enejb]

Fixed in 6901a1e. The activate-branch (and update-plugin) abilities now return a reload flag — true when the affected plugin is Jetpack Beta Tester itself — and the React UI does a full window.location.reload() instead of a soft view refresh in that case, since the running app's own PHP/JS was just swapped.

[anomiex]

I created a JN site and set the beta tester to this branch but I see WSOD on the beta tester page, with https://*.jurassic.ninja/wp-content/plugins/jetpack-beta-dev/build/index.js?minify=false&ver=7.0 pointing to 404

The bug there is that the PR doesn't add a line in projects/plugins/beta/.gitattributes to apply production-include to build/**. It should probably also apply production-exclude to various TypeScript sources and CSS that get bundled for use at runtime.

We're missing the settings on [the manage plugin] page. Were they global, or respective to the selected plugin?

The settings are global, but IIRC were kept on the manage plugin page back in #20168 to make them more straightforward to access.