My Jetpack: migrate product interstitial modal Buttons to @wordpress/ui

[CGastrell]

Fixes #48160

Proposed changes

Migrates the remaining two @automattic/jetpack-components Button consumers under projects/packages/my-jetpack/_inc/components/product-interstitial-modal/ to @wordpress/ui, completing the modal directory sweep started in #49109.

File	Line	Component	Before	After
product-interstitial-modal-cta.tsx	78	Upgrade CTA Button	@automattic/jetpack-components Button, variant="primary", isLoading, optional href+isExternalLink	@wordpress/ui Button, variant="solid", loading, anchor-rendered when href is present (render={<a />} + nativeButton={false})
product-interstitial-my-jetpack.tsx	152	Inline AI "Learn more" link	@automattic/jetpack-components Button, variant="link", weight="regular", size="small", target="_blank"	@wordpress/ui Link, openInNewTab

Prop mapping — Button → @wordpress/ui Button (anchor render)

Old prop (jetpack-components Button)	New prop (@wordpress/ui Button)	Notes
variant="primary"	variant="solid"
isLoading	loading
disabled	disabled
onClick	onClick	preserved on the Button itself
href (optional)	render={<a href={href} />} + nativeButton={false}	follows precedent in #48489
isExternalLink	spreads target="_blank" + rel="noopener noreferrer" onto the rendered <a>	only when isExternalLink is true
className={ styles['action-button'] }	dropped	the SCSS module has no .action-button rule — styles['action-button'] resolved to undefined, so the className was already a no-op

Because the CTA's href prop is optional (and the only in-tree caller — product-interstitial-my-jetpack.tsx's <ProductInterstitialModalCta slug={ slug } /> — never passes one), the new implementation renders a native button when href is absent and an anchor when it's provided. Runtime behaviour for the actual caller is unchanged: a native <button> driven by the useProductCheckoutWorkflow onClick handler.

Prop mapping — Button (variant=link) → @wordpress/ui Link

Old prop	New prop	Notes
href	href
target="_blank"	openInNewTab	@wordpress/ui Link omits target from its <a> prop surface and exposes openInNewTab instead, which sets target="_blank" and the visual external-link indicator
variant="link"	dropped	Link is link-styled by default
weight="regular"	dropped	Link has no weight prop
size="small"	dropped	Link has no size prop

Same recipe as the six call sites migrated by #49109.

Related product discussion/links

• Tracking issue: Jetpack UI Modernization #48160
• Precedent — anchor-rendered Button (render={<a/>} + nativeButton={false}): My Jetpack: migrate interstitial Buttons to @wordpress/ui #48489 (merged)
• Precedent — variant="link" → @wordpress/ui Link sweep across My Jetpack, including the secondary "Learn more" Button in this same modal directory: My Jetpack: migrate link-variant Buttons to @wordpress/ui Link #49109

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

No.

Testing instructions

1. Build: pnpm jetpack build packages/my-jetpack.
2. Boot My Jetpack on a Jetpack-connected site (/wp-admin/admin.php?page=my-jetpack).
3. Trigger the product interstitial modal by clicking a product card's upgrade entry point (e.g. Jetpack AI, Jetpack Backup, Jetpack Boost).
4. Verify:
   • The primary "Upgrade" CTA renders with WPDS solid styling, is keyboard-focusable, fires the checkout redirect on click, and shows the loading state while useProductCheckoutWorkflow runs.
   • The "Learn more" link in the modal footer (already migrated in My Jetpack: migrate link-variant Buttons to @wordpress/ui Link #49109) is unaffected.
   • For Jetpack AI specifically, the inline "Learn more about it here" link in the modal's additional content opens the AI fair-usage policy URL in a new tab, with the WPDS external-link indicator.
5. Confirm disabled state still cascades while the product detail is loading.

Automated gates run locally

• pnpm jetpack build packages/my-jetpack — pass
• pnpm jetpack test js packages/my-jetpack — pass
• ESLint (via lint-staged on commit) — pass after prettier-format

Visual verification note

I attempted to capture before/after screenshots on the local jetpack_dev docker, but the My Jetpack admin page rejected access (Sorry, you are not allowed to access this page) on a non-Jetpack-connected install, and the ProductInterstitialModalCta component is not exercised by the existing storybook story in product-interstitial-modal/stories/. I deliberately did not modify connection state on jetpack_dev. Reviewers with a connected install can verify directly; the migration follows two already-validated precedents (#48489, #49109) operating on the same modal directory.

Designer-review triggers from design.md

Surfaced for the reviewer (not blocking):

• "A primary CTA for a flow" — the Upgrade CTA completes the user's job.
• "Anything touching payments, checkout" — the CTA initiates checkout.

Mitigation: this is a like-for-like component migration to the canonical WPDS primitive. The visual treatment is the WPDS solid variant, the documented analogue of the legacy primary variant; no brand-color overrides or structural-only SCSS was introduced.

[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), and enable the change/my-jetpack-product-interstitial-modal-buttons branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack change/my-jetpack-product-interstitial-modal-buttons

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!

[jp-launch-control]

Code Coverage Summary

Coverage changed in 1 file.

File	Coverage	Δ%	Δ Uncovered
projects/packages/my-jetpack/_inc/components/product-interstitial-modal/product-interstitial-modal-cta.tsx	0/22 (0.00%)	0.00%	5 💔

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.}