Notices: switch to core Snackbar notices everywhere

[simison]

Follow-up to #52015

Proposed changes

• Switch to directly using core Notices fully across the repo instead of using a custom component in between.

Related product discussion/links

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

Testing instructions

• Test notices on every screen

[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/move-jetpack-notices-to-bottom-left branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack update/move-jetpack-notices-to-bottom-left

bin/jetpack-downloader test jetpack-mu-wpcom-plugin update/move-jetpack-notices-to-bottom-left

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: October 6, 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.

---

Videopress 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 5 files.

File	Coverage	Δ%	Δ Uncovered
projects/packages/videopress/src/client/hooks/use-resumable-uploader/index.ts	7/43 (16.28%)	-11.63%	5 💔
projects/packages/videopress/src/dashboard/components/onboarding-modal/intro-video.tsx	9/15 (60.00%)	-13.33%	2 ❤️‍🩹
projects/packages/publicize/_inc/components/services/use-request-access.ts	0/33 (0.00%)	0.00%	1 ❤️‍🩹
projects/packages/videopress/src/dashboard/hooks/use-update-chapters.ts	5/5 (100.00%)	0.00%	0 💚
projects/packages/videopress/src/dashboard/components/editor/use-edit-session.ts	102/105 (97.14%)	0.95%	-1 💚

Full summary · PHP report · JS report

_{Coverage check overridden by I don't care about code coverage for this PR Use this label to ignore the check for insufficient code coveage. .}

[CGastrell]

Took the "all in" version for a spin on a JN site (WP 7.1.1). I think the direction is right — picking boot's placement as the single answer is what lets the SEO override delete cleanly, and dropping Scan's second SnackbarList removes the duplicate hazard instead of restyling around it. One snackbar per surface everywhere I checked.

Three things need sorting before it can land. I pushed fixes for all three to fix/notices-snackbar-52193, one commit each — cherry-pick them, or say the word and I'll open them as a PR into your branch.

1. Dangling import — projects/packages/my-jetpack/_inc/data/products/use-install-plugins.ts:1 still imports the deleted useGlobalNotices. It's the only typecheck error and it also fails Build all projects. It needs { type: 'snackbar' } as well, or the "installed successfully" toast gets created and never rendered.

2. Two my-jetpack suites fail to run — module-toggle and pending-notice mock @wordpress/data wholesale, so the real notices store resolves keyedReducer to undefined. Same shim the VideoPress suites here already carry. Jest-only; wp-notices is externalized at runtime.

3. My Jetpack toasts land bottom-left, under the admin sidebar. This one took a live site to spot. It's the only mount using a .module.scss, so CSS Modules hashes the .components-snackbar selector that snackbar-container() nests, and the centering half of the mixin never matches. Shipped CSS:

.snackbar-notices--aQOoS .components-snackbar--tQbsf { margin-inline: auto; }

Centre of the snackbar, viewport 1327 wide, centre at 664:

Surface	Centre
SEO / Newsletter (boot's list)	663
AI hub	664
Jetpack Settings	664
My Jetpack	87

At x=16 the sidebar paints over it and the message is clipped:

[screenshot uploading: My Jetpack toast clipped by the sidebar]

:global(.components-snackbar) sorts it — the pattern that file already uses for :global(.jp-admin-page__page):

[screenshot uploading: My Jetpack toast centred after the fix]

And here's the SEO page with the override gone, which was your original question — boot's placement, nothing overriding it:

[screenshot uploading: SEO page snackbar, boot placement]

A few smaller things I ran into, curious how you see them:

• Losing the type: 'snackbar' default means a missed call site renders nothing, silently. Use class_exists() guard for Featured_Content. #1 was exactly that miss. Would a thin helper or a lint rule be worth it, rather than leaning on review to catch the next one?
• _inc/client/settings/index.jsx:117 mounts <SnackbarNotices />, but nothing in _inc/client dispatches to @wordpress/notices — the Sharing tab's Publicize section is the legacy toggle, not the package. It's dead weight before and after this PR, so maybe worth dropping while we're in here?
• js-packages/components changelog is patch for removing a public export — I think that wants minor. And since the toast moves in My Jetpack, backup/protect/search/boost surface the same change as the three plugins that got entries.
• The branch says "bottom-left" but everything else lands bottom-centre, so my fix makes My Jetpack match the rest. Shout if it's meant to be the other way round and I'll flip it.

Two gaps in what I checked: the legacy Newsletter mount (that URL serves the wp-build dashboard on my site), and VideoPress/Social/Scan, which are plan-gated on a free JN site. Those only dispatch, and boot's renderer is verified on the pages I could reach — but worth a second pair of eyes if you have a site that reaches them.

How does this look to you?

— Terminator

[simison]

Feel free to push to the branch.

snackbar-notices--aQOoS type overrides as fixes won't be safe; something in the surrounding product CSS would need changes preferably instead.

Same for anything targeting component internal selectors; not sustainable as a fix.

[CGastrell]

Agreed, and thanks — that override was the wrong shape. Reworked it.

The real problem is that My Jetpack is the only one of the mounts placing its snackbars from a CSS module. snackbar-container() styles .components-snackbar itself, so a module hashes that selector out of existence and the centering silently never applies. The AI hub, Jetpack Settings and Newsletter mounts all use plain stylesheets, which is why only this one drifted.

So instead of re-declaring anything, the rule moves to the package's global stylesheet (_inc/style.module.scss, next to the other rules that style wp-admin chrome) and the component takes a plain class. We now write nothing that targets component internals — the mixin emits its own selector, unhashed:

.my-jetpack-snackbar-notices { position: fixed; bottom: …; }
.my-jetpack-snackbar-notices .components-snackbar { margin-inline: auto; }

Same result on the site, arrived at properly — centre 663 against a viewport centre of 664, one snackbar, via a real module toggle:

[screenshot uploading: My Jetpack toast centred via the global class]

Pushed all three to update/move-jetpack-notices-to-bottom-left. Typecheck is clean and the my-jetpack suite is green (24/187).

Worth noting the same trap applies to anything else that reaches for that mixin from a .module.scss later — it fails quietly, with no build warning and no visual clue until someone looks at a toast on a wide screen.

— Terminator

[simison]

Doesn't My Jetpack now use WP build and Boot container? Thought I saw that happen but could be wrong. That would ship notice slot without My Jetpack doing anything.

[CGastrell]

Rebased onto trunk and swept every screen this touches. Two findings.

Trunk has a duplicate-toast bug today, and this PR fixes it. My Jetpack and the AI Hub moved onto wp-build after this branch forked (#52446, #52411), so boot's Root already mounts a SnackbarNotices. Trunk still mounts <GlobalNotices /> inside boot's stage — one toggle, two toasts:

So both of this PR's mounts on those pages were redundant too. I dropped my earlier centering commit and deleted the mounts instead, as this branch already does for Scan:

SEO with the override gone, your original question:

Every screen, same probe — count, which list, center pixel (viewport centre is 664):

Screen	Under boot	Lists	Centre
My Jetpack	yes	1 — boot's	663
AI Hub	yes	1 — boot's	663
Newsletter (wp-build)	yes	1 — boot's	663
Newsletter (legacy app)	no	1 — its own	663
Jetpack Settings	no	1 — its own	663
SEO	yes	1 — boot's	663
Scan	yes	1 — boot's	663
VideoPress	yes	1 — boot's	663
Social	yes	1 — boot's	663

Newsletter's legacy app and Jetpack Settings aren't boot pages, so those two mounts stay.

Caveat on the shots: My Jetpack's are a real module toggle; the AI Hub pair is a dispatched notice, since AI saves need a plan the test site lacks.

Two rebase extras: private-thumbnail-source.test.tsx landed on trunk mocking the subpath this branch deletes, and the AI Hub's save-confirmation tests now render the app beside a SnackbarNotices (what boot supplies) since the mount is gone. Typecheck and all suites green.

Note the rebase rewrote your commit, so this needed a force-push.

Still open from last time:

• _inc/client/settings/index.jsx:117 mounts <SnackbarNotices /> but nothing in _inc/client dispatches to it. Drop it while we're here?
• js-packages/components: I'd had GlobalNotices removed outright, but the package is published to npm and we can't see who imports it outside the monorepo — so it's deprecated instead now, same shape as the Chip shim in Componentry: Migrate Chip to @wordpress/ui Badge #48162. Changelog is minor/deprecated, and the removal can ride the next major. Nothing in this repo imports it any more.
• backup/protect/search/boost surface the My Jetpack change too, so they may want changelog entries alongside the three that have them.

How does this look?

— Terminator

[simison]

Sounds good!

[simison]

BTW I think it's fine to remove instead of deprecate. It's so easy to migrate to core ones it doesn't seem issue with JP components, which aren't really used outside this repo anyway.

[CGastrell]

Rebased onto trunk again — #52494 landed in the middle of this and overlaps us in a useful way.

@enejb hit the same thing from the other direction and removed <GlobalNotices /> from my-jetpack-screen, with the same conclusion:

No snackbar list here: the wp-build page shell already renders the notices store, and a second list showed every notice twice.

So the My Jetpack half is fixed on trunk now and my commit for it is gone — dropped as empty during the rebase. The AI Hub is still duplicating on trunk (_inc/client/ai/main.jsx:434), so that one here is still doing work.

One thing worth flagging while this is open: use-main-features.test.tsx came with #52494 and mocks @wordpress/data wholesale, which trips over the core notices store — keyedReducer is not a function, and the suite won't run. That's the third suite needing the same one-liner:

jest.mock( '@wordpress/notices', () => ( { store: 'core/notices' } ) );

Anything that mocks @wordpress/data wholesale and reaches a file dispatching to the notices store will need it, so expect a couple more while this is in flight.

Typecheck clean; my-jetpack 309, components 115, videopress 1329, plugins/jetpack 952 + 493.

— Terminator

[simison]

I don't understand why we have this roundabout way of importing @wordpress/base-styles instead of doing it directly.

[CGastrell]

Fair point, and I've switched both files to @use "@wordpress/base-styles/mixins" directly.

To be clear about where it came from: the wrapper is the majority pattern in the monorepo, so I followed it rather than invented it. Counting stylesheets under projects/:

• @automattic/jetpack-base-styles/gutenberg-base-styles — 106 files
• @wordpress/base-styles directly — 44 files

The wrapper itself is six lines of @forward over z-index, colors, variables, breakpoints, mixins and animations. Its one real benefit is giving a project the mixins without declaring @wordpress/base-styles itself — but only 24 projects declare it directly, so for the rest the wrapper is doing actual work.

Neither of these two is in that group: plugins/jetpack and packages/newsletter both already depend on @wordpress/base-styles@13.1.0, and each was pulling the wrapper in for exactly one mixin. _mixins.scss is self-sufficient (it @uses its own wpds fallbacks, variables, colors, breakpoints and functions), so the direct import works standalone. Emitted CSS is byte-identical in both bundles and stylelint is happy.

Treating this as a proof of concept rather than a cleanup — the other 106 are out of scope here, and unpicking them needs the per-project dependency check doing first, since a direct import breaks any project that doesn't declare the package. Happy to file an issue for that sweep if it looks worth doing.

— Terminator

[CGastrell]

JETPACK-2754

[CGastrell]

BTW I think it's fine to remove instead of deprecate. It's so easy to migrate to core ones it doesn't seem issue with JP components, which aren't really used outside this repo anyway.

@simison I agree, but since it's a published package and there's precedent on how we handle this, I think it's no harm to first deprecate it.

[CGastrell]

Re-reviewed at aeee27b, merged locally with current trunk. The merge is clean. Typecheck and the JS suites pass (my-jetpack, videopress, newsletter, publicize, components, jetpack gui).

Verdict: minor issues, no blockers.

1. Two My Jetpack call sites still use the deprecated useGlobalNotices: features/use-bulk-feature-switch.ts:68 and features/use-main-features.ts:106. They still work through the shim, but they need the same useDispatch( noticesStore ) + { type: 'snackbar' } swap. Trunk's feature-list-bulk.test.tsx also still mocks the hook.
2. The same 10-line @wordpress/data mock is copied into about 9 VideoPress test files. A shared mock would stop them drifting apart.
3. The plugins/jetpack changelog is Type: other. The toast now shows in a new place on screen, so enhancement fits better.
4. Code coverage check fails. It needs an override label.

— Terminator

[CGastrell]

	Before	After
Save fails
Save completes