WP Build Polyfills: bump @wordpress/theme to 0.17.0 to fix blank Forms/VideoPress dashboards on WP 6.9

[enejb]

Proposed changes

Fixes the blank "Something went wrong!" wp-build admin dashboards on Jetpack 16.0 / WordPress 6.9 — reported for Forms, and reproduced identically on VideoPress.

Bumps @wordpress/theme from ^0.15.0 to ^0.17.0 in wp-build-polyfills. That's the whole fix.

Root cause: boot and theme are a mismatched pair on 16.0

wp-build-polyfills on branch-16.0 resolves:

Package	Version on 16.0
@wordpress/boot	0.17.0
@wordpress/theme	0.15.1

The polyfill's boot module renders ThemeProvider as a public export of wp.theme:

(0, x.jsx)(h.ThemeProvider, { isRoot: true, ... })   // h = the wp-theme external

But @wordpress/theme 0.15.1 only exports privateApis. You can see it in the script 16.0 actually serves — ThemeProvider is compiled in, but never exported:

t.d(a, { privateApis: () => n.j });   // no ThemeProvider
(window.wp = window.wp || {}).theme = a;

So boot reads undefined, React throws #130 (type is invalid ... got: undefined), the error boundary catches it, and the page renders "Something went wrong!".

@wordpress/theme added the public export in 0.17.0:

export { privateApis } from './private-apis';
export { ThemeProvider } from './theme-provider';   // ← new

Every wp-build (script-module) dashboard boots through that module, which is why one dependency skew breaks multiple products at once. This was never a Forms bug.

Why this doesn't affect trunk

Trunk bumped theme to 0.17.0 as part of the @wordpress/* monorepo update (#49272), re-pairing boot and theme. That PR is ~281 files, so it isn't a sane cherry-pick for a point release — hence this minimal, targeted bump instead.

Blast radius

Rebuilding the package with only this bump changes exactly one built artifact — build/scripts/theme/index.js (+ its .asset.php). Every other polyfill asset (boot, route, a11y, notices, private-apis, views) is byte-identical to what 16.0 ships. @wordpress/ui does not need to move; theme alone is sufficient.

Testing instructions

Verified on a Jurassic Ninja site running WordPress 6.9.4 + Jetpack 16.0 (Gutenberg not installed), driven with Playwright.

Before — Jetpack → Forms and Jetpack → VideoPress both render "Something went wrong!", console shows Minified React error #130 originating in jetpack-wp-build-polyfills/build/modules/boot/index.js.

After (production build of this branch rsynced to the same site):

• Forms renders the forms list and Responses tabs.
• VideoPress renders Overview, views trends, and stats.
• My Jetpack and Boost continue to render (unaffected — they never depended on wp-theme on 16.0).
• React error #130 is gone from the console.

To reproduce:

1. WordPress 6.9.x, Jetpack 16.0, Gutenberg plugin inactive.
2. Visit admin.php?page=jetpack-forms-responses-wp-admin → blank error page on stock 16.0.
3. Apply this branch, rebuild wp-build-polyfills, and reload → dashboard renders.

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

No.

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

bin/jetpack-downloader test jetpack fix/wp-build-polyfills-theme-provider

bin/jetpack-downloader test jetpack-mu-wpcom-plugin fix/wp-build-polyfills-theme-provider

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.

[jp-launch-control]

Code Coverage Summary

No summary data is available for parent commit 18e76ed, so cannot calculate coverage changes. 😴

If that commit is a feature branch rather than a trunk commit, this is expected. Otherwise, this should be updated once coverage for 18e76ed is available.

Full summary · PHP report · JS report

[dhasilva]

LGTM, tested locally on WP 6.9.1 without Gutenberg.

[simison]

@enejb most of the file changes in that #49272 were due to the Theme version bump and breaking changes within it. UI, Admin UI packages and much of the code in Jetpack now expect theme variables that are not present in the latest wp-theme. I think a full PR cherry-pick would have actually been better and safer. That's exactly why everything was updated in one go in a single PR instead of separately. :-)

Did you check if everything in the UIs built by WP-Build is working across Jetpack? Fortunately, Jetpack uses a lot of manual theme token fallbacks in previous versions, which protects a lot from missing tokens.