Social: build the Overview tab on the modernization chassis (PR 2 / #48824)

[keoshi]

Summary

Phase 2 of the Social modernization umbrella (#48824). Stacks on top of PR 1 (#48826) and fills the Overview tab with the connected-accounts surface.

• "Add account" page-header action — lifts openConnectionsModal into the SocialPage actions slot when the Overview tab is selected; the existing ManageConnectionsModal handles the rest.
• Connected accounts card — wraps the existing ConnectionManagement list in a WPDS Card.Root (legacy admin page is unchanged; the wrap adds opt-in hideConnectButton + hideHeading props so the legacy bottom CTA + <h3> stay where they are when re-used elsewhere).
• Empty state — when the site has zero connections, the card body becomes a @wordpress/ui EmptyState with the share icon + a primary "Add account" CTA that mirrors the page-header button.
• Connection-error notice + JITM mount-point preserved above the card.

ConnectionScreen (site not connected) and PricingPage (free Jetpack, pricing nudge not dismissed) keep pre-empting the tabs the way they pre-empt the legacy dashboard — but the check moved to PHP: a new should_preempt_to_legacy() on Social_Admin_Page routes the menu callback back to the legacy SocialAdminPage shell when either condition holds, so those flows render exactly as they do today and the wp-build esbuild bundle stays free of the @automattic/jetpack-connection disconnect-dialog asset graph.

Drive-by chassis infrastructure

The chassis re-uses ConnectionManagement and the rest of the existing services/ chain unchanged. wp-build's esbuild pipeline doesn't configure file loaders for .webp / .svg / .jpg, so a handful of asset imports along that chain would otherwise break the build. Three drive-by fixes resolve that without touching the legacy webpack pipeline:

• Inline the previously-imported default-avatar.svg as JSX inside ConnectionIcon. Same fallback, one less binary asset to bundle.
• Switch the six service-walkthrough .webp imports in services/utils.tsx to runtime URLs built from JetpackScriptData.social.assets_url. Webpack copies _inc/assets/ verbatim into build/assets/ via a new CopyWebpackPlugin step so both bundlers resolve the same URL.
• Expose a ./use-connection-error-notice sub-path from @automattic/jetpack-connection and import via that path from the chassis, so esbuild stops pulling the disconnect-dialog/*.jpg illustrations through the package barrel.
• Expose social-logo-colors.css from the social-logos package via a ./colors.css sub-path (and define the missing --color-bluesky brand variable). The chassis pulls it from SocialPage so the per-service brand colours resolve in the modal — the legacy admin bundle inlines these via postcss-custom-properties { preserve: false }, which the chassis esbuild pipeline doesn't run.

Screenshots

Overview tab — empty state

Overview tab — with one connected account

Add account modal

Settings tab (still empty — fills in PR 3)

Testing instructions:

1. Pull this branch and rebuild: jetpack build packages/publicize --deps (or rsync the Jetpack plugin to a Jurassic Ninja site).
2. Activate the Publicize module: wp jetpack module activate publicize.
3. On a Jetpack-connected site without paid Social features, dismiss the pricing-page nudge (or set wp option update jetpack-social_show_pricing_page 0). Without this step, should_preempt_to_legacy() correctly routes the request back to the legacy SocialAdminPage so the PricingPage stays visible.
4. With the filter off (no add_filter( 'rsm_jetpack_ui_modernization_social', '__return_true' );), wp-admin → Jetpack → Social renders the legacy admin page unchanged.
5. Enable the filter and reload. Expected: the chassis renders an Overview tab with the connected-accounts card. With zero connections, the card body shows the centred empty state ("No accounts connected yet" + share icon + primary "Add account" button). The Page header carries a secondary "Add account" button on the right.
6. Click either "Add account" button. Expected: ManageConnectionsModal opens with the services list. Service icons render in brand colours (Facebook blue, Bluesky blue, Threads black, etc.).
7. Connect any one service via the OAuth flow. Expected: the card body switches from empty state to the existing ConnectionManagement list. The card header now reads "Connected accounts". The page-header "Add account" button continues to open the modal.
8. Verify the Settings tab is still empty (intentional — PR 3 fills it).
9. Pre-empt verification (filter on):
   • Disconnect Jetpack. Expected: chassis routes back to the legacy SocialAdminPage which renders ConnectionScreen.
   • Reconnect, but flip jetpack-social_show_pricing_page back to 1. Expected: chassis routes back to the legacy SocialAdminPage which renders PricingPage.

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

No. PR 2 wires existing components into a new tab body — it does not add Tracks events, new REST endpoints, new option reads/writes, or new external requests beyond what the legacy admin page already performs (/wpcom/v2/publicize/services, /wpcom/v2/publicize/connections). The jetpack_social_tab_view Tracks event mentioned in the umbrella lands in PR 5, not here.

🤖 Generated with Claude Code

[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 update/social-modernization-overview branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack update/social-modernization-overview

bin/jetpack-downloader test jetpack-mu-wpcom-plugin update/social-modernization-overview

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]

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: June 2, 2026
  • Code freeze: June 1, 2026

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

---

Social 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]

Code Coverage Summary

Coverage changed in 3 files.

File	Coverage	Δ%	Δ Uncovered
projects/packages/publicize/src/class-social-admin-page.php	7/79 (8.86%)	-1.28%	10 💔
projects/packages/publicize/_inc/components/connection-icon/index.tsx	7/7 (100.00%)	0.00%	0 💚
projects/packages/publicize/_inc/components/services/utils.tsx	15/42 (35.71%)	15.13%	0 💚

1 file is newly checked for coverage.

File	Coverage
projects/packages/publicize/_inc/components/overview-tab/index.tsx	0/7 (0.00%) 💔

Full summary · PHP report · JS report

_{If appropriate, add one of these labels to override the failing coverage check: Covered by non-unit tests Use to ignore the Code coverage requirement check when E2Es or other non-unit tests cover the code Coverage tests to be added later Use to ignore the Code coverage requirement check when tests will be added in a follow-up PR I don't care about code coverage for this PR Use this label to ignore the check for insufficient code coveage.}

[anomiex]

Please don't allow your AI to do this. It clutters the PR, it'll break the PR description when removed, and at some point you're going to forget to remove them before merging.

[anomiex]

Another thing to look at when you're adding routes/ and such is to set the production-exclude attribute in projects/packages/foo/.gitattributes so these unused-at-runtime source files don't wind up in the package and plugin zips. See #47365.

[anomiex]

Seems like there's a lot going on in this PR to hack around shortcomings in the "chassis" build. But I'll leave reviewing that to people who work on the code; structurally, my concerns appear to be addressed.

Screenshot was removed

[manzoorwanijk]

This could simply be this

Suggested change

	const hasConnections = useSelect(
	select => ( select( socialStore ).getConnections() ?? [] ).length > 0,
	[]
	);
	const hasConnections = useSelect( select => select( socialStore ).hasConnections(), [] );