My Jetpack: register wp-build-polyfills so the app (and Boost) loads without Gutenberg on WP < 7.0

[CGastrell]

Proposed changes

• Register the shared WP_Build_Polyfills shim before enqueuing my_jetpack_main_app, providing the wp-notices / wp-private-apis / wp-theme script handles the My Jetpack bundle depends on when the runtime doesn't ship them (WP < 7.0 with the Gutenberg plugin inactive).
• On trunk, my_jetpack_main_app began depending on the wp-theme handle after the @wordpress/* monorepo bump (Update Bundled @wordpress/* monorepo #49272, "Update Bundled @wordpress/* monorepo") — driven mainly by @wordpress/dataviews 14.3→17.x. DataViews 17.x renders its form controls with bundled @wordpress/ui popup/dialog components that wrap in @wordpress/ui's ThemeProvider, which imports @wordpress/theme; the build externalizes that to the wp-theme script handle. (Verified via webpack's dependency reason graph on the frozen trunk build; Jetpack 16.0, on DataViews 14.3, does not pull this code path and has no wp-theme dep.) WP core registers wp-theme only from 7.0 (6.9 ships none); Jetpack supports the current + previous WP release (today 6.9 / 7.0). With Gutenberg inactive on 6.9, wp-theme is unregistered, so WordPress silently drops my_jetpack_main_app — and any script that hard-depends on it, notably Jetpack Boost's admin bundle, is dropped too, rendering a blank admin page with no console error.
• This mirrors the existing approach in Jetpack Social / VideoPress / Newsletter / Forms, which already register WP_Build_Polyfills. The shim is conditional and no-ops once wp-theme is provided by Gutenberg or WP ≥ 7.0.
• Propagates the new automattic/jetpack-wp-build-polyfills dependency into the composer.lock of every plugin that bundles My Jetpack.

Scope: trunk regression, not present in any released version. The trigger (@wordpress/dataviews 17.x, via #49272) merged to trunk after branch-16.0 was cut; every stable release through 16.0 bundles DataViews ≤ 14.3.0, which never pulls the @wordpress/ui ThemeProvider path — so @wordpress/theme is not imported and no wp-theme dep is emitted (verified by building the 16.0 tag frozen: my_jetpack_main_app has no wp-theme). It first reaches a release with 16.1.

How the bug happens

flowchart TD
    A["my_jetpack_main_app build<br/>bundles @wordpress/dataviews 17.x"] --> B["DataViews renders form controls<br/>with @wordpress/ui components"]
    B --> C["@wordpress/ui ThemeProvider<br/>imports @wordpress/theme"]
    C --> D["build adds a script dependency:<br/>my_jetpack_main_app needs <b>wp-theme</b>"]
    D --> Q{"What registers wp-theme<br/>at runtime?"}
    Q -->|"WP 7.0+ core, or active Gutenberg"| G1["environment provides wp-theme"]
    Q -->|"this PR"| G2["WP_Build_Polyfills registers<br/>a fallback wp-theme"]
    Q -->|"WP 6.9 and Gutenberg off, no fix"| K["WordPress drops my_jetpack_main_app<br/>(no console error)"]
    G1 --> OK["script loads<br/>My Jetpack & Boost render"]
    G2 --> OK
    K --> M["My Jetpack page is blank"]
    K --> N["jetpack-boost-admin depends on it →<br/>dropped too → Boost page is blank"]
    classDef bad fill:#f8d7da,stroke:#c33,color:#611;
    classDef good fill:#d7f0d9,stroke:#3a3,color:#161;
    classDef fix fill:#d7e6fb,stroke:#36c,color:#124;
    class K,M,N bad
    class OK,G1 good
    class G2 fix

Loading

Cause and effect, step by step:

1. My Jetpack's admin app (my_jetpack_main_app) is built with @wordpress/dataviews 17.x.
2. DataViews 17.x renders its form controls with @wordpress/ui components (dropdowns, dialogs, tooltips). Those components use @wordpress/ui's ThemeProvider, which imports @wordpress/theme.
3. The build turns that @wordpress/theme import into a WordPress script dependency named wp-theme. The code is not bundled into the file — the file now expects WordPress to provide a wp-theme script at runtime.
4. WordPress core first ships a wp-theme script in WP 7.0. WP 6.9 does not have it. The Gutenberg plugin also provides it — but only while Gutenberg is active.
5. So on WordPress 6.9 with the Gutenberg plugin turned off, no wp-theme script exists.
6. WordPress refuses to output any script whose dependency is missing, so it silently drops my_jetpack_main_app. No console error appears, because no script ever ran.
7. The My Jetpack page mounts its React app into that script. With the script gone, the page body renders blank.
8. Jetpack Boost is hit harder: its own admin script lists my_jetpack_main_app as a dependency, so when that is dropped, Boost's script is dropped too — the Boost settings page is also blank.

How this PR mitigates it: before enqueuing my_jetpack_main_app, My Jetpack registers a fallback wp-theme script (via the shared WP_Build_Polyfills shim) so the handle always exists. When WordPress 7.0+ or an active Gutenberg already provides wp-theme, the fallback does nothing.

What pulls in the wp-theme dependency

The bug appears whenever my_jetpack_main_app's bundle imports @wordpress/theme — directly, or transitively through @wordpress/ui — because the build externalizes that import to the wp-theme script handle.

In the current My Jetpack build the path is @wordpress/dataviews 17.x → the @wordpress/ui components it renders → ThemeProvider → @wordpress/theme, which is the change that introduced it here:

Package	Its part in the chain	Evidence
@wordpress/dataviews	17.x renders @wordpress/ui components that use ThemeProvider — the path that appeared in the trunk build	14.3.0 → clean; bumping only DataViews to 17.1.0 → wp-theme appears
@wordpress/ui	its ThemeProvider does the actual import from '@wordpress/theme'	every @wordpress/ui ≥ 0.13 imports theme
@wordpress/theme	the imported package the build externalizes to the wp-theme handle	—

DataViews is not special here — it is simply the path that pulled the import into this bundle. Any direct use of @wordpress/ui, or a direct @wordpress/theme import, would introduce wp-theme on its own. The fix therefore targets the missing handle, not any single package.

Simplest check on any build: the bug is present when my_jetpack_main_app's built index.asset.php lists wp-theme. Combined with WordPress < 7.0 and Gutenberg inactive, that is the exact failing condition.

Related product discussion/links

• Design Systems: @wordpress/theme stabilization for WP 7.1 (internal P2 — shortlink to add).
• Complementary shim-side change: WP Build Polyfills: force-replace boot and theme on WP 7.0 #50309 (force-replace wp-theme / @wordpress/boot on WP 7.0, where core ships them incomplete). Both PRs touch automattic/jetpack-wp-build-polyfills (different parts — this one adds a consumer, WP Build Polyfills: force-replace boot and theme on WP 7.0 #50309 changes the shim), so whichever merges second needs a lock refresh (tools/check-intra-monorepo-deps.sh -au).

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

No.

Testing instructions

Repro (before this PR, on trunk / a build with @wordpress/dataviews 17.x):

1. WordPress < 7.0 (e.g. 6.9.x) with the Gutenberg plugin deactivated.
2. Jetpack and Jetpack Boost active.
3. Visit Jetpack → Boost (admin.php?page=jetpack-boost): the content area is blank, the admin menu/top bar render, and there is no console error. my_jetpack_main_app and jetpack-boost-admin are absent from the page source — dropped by WordPress because of the unregistered wp-theme dependency.

Verify (with this PR):
4. Same environment → the Boost admin page renders normally.
5. Activate the Gutenberg plugin → still renders (the polyfill no-ops when wp-theme is already registered).
6. The My Jetpack page (admin.php?page=my-jetpack) also renders in both states.

[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 fix/my-jetpack-wp-theme-polyfill branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack fix/my-jetpack-wp-theme-polyfill

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:

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.

---

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

---

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

---

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

---

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.

---

Starter Plugin 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.

---

Protect 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 1 file.

File	Coverage	Δ%	Δ Uncovered
projects/packages/my-jetpack/src/class-initializer.php	97/342 (28.36%)	0.90%	2 ❤️‍🩹

Full summary · PHP report · JS report

[LiamSarsfield]

LGTM; I built the package locally to sanity-check the handle list: the only polyfill-covered handles in build/index.asset.php are wp-notices, wp-private-apis, and wp-theme, so the set is right. Timing checks out too, since register() registers synchronously once wp_default_scripts has fired. Suite passes for me.

Some nits:

1. Move self::register_wp_build_polyfills() above the do_action( 'myjetpack_enqueue_scripts' ) on the line before it. If any callback on that hook calls WP_Build_Polyfills::register() first with a narrower handle set, it flips the registrar's $hooked flag and my-jetpack's own call records the request without registering anything for the current request (class-wp-build-polyfills.php:92). Nothing hooks it that way today, but it's a public extension point one line above the call, and the reorder costs nothing.

2. Nothing guards the hand-maintained handle list against the bundle drifting. A future @wordpress/* bump that pulls in, say, wp-views would blank-page again with no console error while the test stays green. wp-build-polyfills has a pattern for this in test_boot_asset_has_no_unregistered_handles; a my-jetpack version that reads build/index.asset.php and skips when unbuilt would catch it.

3. git diff --check origin/trunk...HEAD flags trailing blank lines in seven of the plugin changelog files.

4. Tiny one: the my-jetpack changelog entry leads with the shim. Flipping it to lead with the user outcome ("Fix the My Jetpack app failing to load…") reads better in release notes.

If you touch the test anyway, a tearDown() that resets the registrar statics (same pattern as WP_Build_Polyfills_Test) would keep a future second test from inheriting the leftover state. Optional.

[CGastrell]

Thanks @LiamSarsfield — all four addressed in 253d5dc:

1. Reorder — register_wp_build_polyfills() now runs before do_action( 'myjetpack_enqueue_scripts' ), so a hook consumer tripping $hooked first can't leave our handles recorded-but-unregistered.
2. Bundle-drift guard — added test_requested_handles_cover_polyfilled_bundle_dependencies(): reads build/index.asset.php, intersects its deps with WP_Build_Polyfills::SCRIPT_HANDLES, and fails if any isn't in our requested set; markTestSkipped when unbuilt. Verified it passes against a fresh build.
3. Trailing blank lines — stripped from the seven propagated composer.lock changelogs; git diff --check is clean.
4. Changelog wording — flipped to lead with the user outcome.

Also took the optional tearDown() static reset (mirrors WP_Build_Polyfills_Test).

[anomiex]

Seems reasonable. I'm not sure just how much point there is to projects/packages/my-jetpack/tests/php/Register_Wp_Build_Polyfills_Test.php though. Minor suggestions inline.

[anomiex]

Suggested change

	Fix the My Jetpack app failing to load on WordPress installs without the Gutenberg plugin active, where the wp-theme script handle it depends on is otherwise unregistered.
	Fix the My Jetpack app failing to load on WordPress 6.9 installs without the Gutenberg plugin active, where the wp-theme script handle it depends on is otherwise unregistered.

[anomiex]

Suggested change

	Fix a blank Boost admin page on WordPress installs without the Gutenberg plugin active, where the wp-theme script handle the embedded My Jetpack app depends on was otherwise unregistered.
	Fix a blank Boost admin page on WordPress 6.9 installs without the Gutenberg plugin active, where the wp-theme script handle the embedded My Jetpack app depends on was otherwise unregistered.

[anomiex]

Seems like AI over-explanation to me.

Suggested change

	* Register polyfills for the wp-notices / wp-private-apis / wp-theme handles the
	* My Jetpack app bundle depends on but WP < 7.0 does not ship (or ships with an
	* incomplete allowlist) when the Gutenberg plugin is not active.
	*
	* Without this, `my_jetpack_main_app` is enqueued with an unregistered `wp-theme`
	* dependency, so WP silently drops the script (no console error) and the My Jetpack
	* app — plus any consumer that hard-depends on it, such as Jetpack Boost — renders
	* a blank page. Only the handles the bundle actually uses are requested.
	*
	* Register polyfills for the wp-notices / wp-private-apis / wp-theme handles the
	* My Jetpack app bundle depends on but WP < 7.0 does not ship (or ships with an
	* incomplete allowlist).
	*

[LiamSarsfield]

Tested on JN with Gutenberg off and My Jetpack and Boost render where trunk was blank. LGTM.

One fast-follow: the tests assert the get_consumers() map, not the ordering that broke, so reverting the reorder still passes. A test that runs Initializer::enqueue_scripts() and checks wp-theme registers before my_jetpack_main_app would catch that.

Two minor: test_requested_handles_cover_polyfilled_bundle_dependencies calls markTestSkipped() when build/ is absent (the CI state), so it's a no-op on PRs; fail instead of skip. And not this PR, but WP_Build_Polyfills::register() returns early once $hooked is set, so a later caller after wp_default_scripts fires gets recorded but not registered. Nothing hits it today; maybe fold into #50309.

Nice fix 🚀

[CGastrell]

Applied in df02d7f.

@anomiex — all three:

• Both changelogs now say "WordPress 6.9 installs" (7.0 registers wp-theme).
• Trimmed the register_wp_build_polyfills() doc comment to your suggestion.
• On the test's value: fair. I've slimmed it to the single handle-set coverage test and dropped the extra one (see below).

@LiamSarsfield — on the follow-ups:

• Drift test was a no-op in CI (skips when build/ is absent) — removed it rather than fail-on-missing-build, which would break the buildless PHP job.
• Ordering isn't guarded — agreed, but a faithful test means running Initializer::enqueue_scripts(), which pulls in Modules/Connection_Manager/Speed_Score_History/wp_localize_script; not worth mocking all of that for the reorder. Left as-is.
• register() returns early once $hooked is set (later caller after wp_default_scripts gets recorded but not registered) — agreed this is shim-side; folding into WP Build Polyfills: force-replace boot and theme on WP 7.0 #50309 rather than working around it here.