Search: retire the wp-build flag and the legacy dashboard bundle

[dhasilva]

Part of JETPACK-2568. Its other open item, the Customberg decision, is not covered here.

Proposed changes

Retires the search-wp-build feature flag added by #52416. The Jetpack Search dashboard now always renders through wp-build, inside the rounded frame, and the legacy dashboard bundle is gone. This follows the same steps as the My Jetpack retirement in #52446.

• The dashboard always renders through wp-build. The flag constant, its registration in Initializer::init(), is_modernized(), is_wp_build_dashboard_active() and every branch on them are removed. Initializer::init() is back to its pre-port shape.
• The legacy bundle is deleted. src/dashboard/index.jsx, tools/webpack.dashboard.config.js and the build-dashboard script (from both build and watch) are removed, so the package no longer builds or ships build/dashboard/. The dashboard was shipping twice: roughly 735 KB per mirror while the flag was off (item D in JETPACK-2686).
• src/dashboard/scss/admin-layout.scss is deleted. Since Admin page layout: clip Boot's stage so it can't add a second scrollbar #52507 the route imports route.scss, which covers everything in this file, so only the legacy entry used it.
• The initial state stays on the script-less jetpack-search-dashboard-data handle the wp-build path already used. load_admin_scripts() no longer branches. No other plugin depends on the retired jp-search-dashboard handle (checked in the Search: serve the dashboard through wp-build, UI unchanged #52416 review, and re-checked with git grep across projects/).
• An unbuilt checkout renders an empty page instead of falling back to the legacy dashboard, which no longer exists. My Jetpack and Social behave the same way.
• automattic/jetpack-feature-flags is no longer required. Nothing else in the package uses it. The Jetpack and Search plugin locks each lose only that one require line: My Jetpack still requires the package, so it stays bundled.
• Tests: Dashboard_Wp_Build_Fallback_Test becomes Dashboard_Wp_Build_Test. The flag and fallback cases are gone. What remains covers the generated render call, the empty unbuilt render, the data handle, and both drift checks on the generated function name.

Verification already done

• jp test php packages/search: 763 pass. On an unbuilt checkout, 1 skipped (the build-guarded drift test). After jp build packages/search, all 6 Dashboard_Wp_Build_Test cases pass, drift test included.
• jp test php packages/sync (the package's AGENTS.md asks for it): 164 pass.
• JS: 1234 + 738 tests pass, and all five size-limit budgets pass. tsgo --noEmit, ESLint, PHPCS and jp phan packages/search are clean. .github/files/check-lock-files.sh passes.
• jp build packages/search produces no build/dashboard/, and the generated page-wp-admin.php defines jetpack_search_jetpack_search_dashboard_wp_admin_render_page().
• On a local Docker site (Jetpack plugin, self-hosted), I loaded Jetpack → Search with search-wp-build no longer registered anywhere:
  • The app mounts at #jetpack-search-dashboard-wp-admin-app, with #jp-search-dashboard (16px) inside.
  • The Overview / Settings / AI Answers tabs are present, and the page resolves to #/overview.
  • The hero measures 36px / 39.996px and is 508px wide, as in Search: serve the dashboard through wp-build, UI unchanged #52416's acceptance check.
  • The only dashboard script requested is build/routes/dashboard/content.js. Nothing is requested from build/dashboard/.

Not verified: the standalone Search plugin without Jetpack, Atomic, and WordPress.com Simple. On Simple, the dashboard is subclassed outside this repo to change the menu priority. That subclass could not have referenced anything removed here, since all of it was added by #52416 the day before.

Related product discussion/links

• Follow-up to Search: serve the dashboard through wp-build, UI unchanged #52416 (JETPACK-2568), part of JETPACK-2566
• Rebased on Admin page layout: clip Boot's stage so it can't add a second scrollbar #52507 (fixes the second scrollbar on the Overview tab) and Search: build the package's independent steps concurrently #52457 (concurrent package build)
• Same retirement for My Jetpack: My Jetpack: retire the wp-build flag and the legacy dashboard bundle #52446
• Mirror size: JETPACK-2686, item D

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

No.

Testing instructions

Clear any leftover override first. On Jurassic Ninja: wp companion feature-flag reset search-wp-build. Locally, remove any jetpack_feature_flag_enabled_search-wp-build filter (mu-plugin or Code Snippet). Nothing reads the flag anymore, so a leftover is harmless, but removing it proves the page doesn't need it.

Dashboard (Jetpack plugin)

• Go to Jetpack → Search. It renders inside wp-build's rounded frame, with no flag set.
• Click through Overview / Settings / AI Answers, and reload directly on admin.php?page=jetpack-search#/settings.
• In the console, document.querySelector( '#jetpack-search-dashboard-wp-admin-app #jp-search-dashboard' ) finds the wrapper, and window.JP_CONNECTION_INITIAL_STATE is defined.
• In the Network tab, nothing loads from jetpack-search/build/dashboard/, and build/routes/dashboard/content.js loads.

Standalone Search plugin

• Deactivate Jetpack and activate the Search plugin. Repeat the steps above on its Search page.

🤖 Generated with Claude Code

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

---

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.

[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 update/search-retire-wp-build-flag branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack update/search-retire-wp-build-flag

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

[jp-launch-control]

Code Coverage Summary

Coverage changed in 2 files.

File	Coverage	Δ%	Δ Uncovered
projects/packages/search/src/dashboard/class-dashboard.php	21/84 (25.00%)	-17.20%	0 💚
projects/packages/search/src/initializers/class-initializer.php	17/66 (25.76%)	-1.11%	0 💚

Full summary · PHP report · JS report

[CGastrell]

Tested on a Jurassic Ninja site and an Atomic Business site. Same page, three states:

	Before (trunk, flag off)	After — Jetpack plugin	After — standalone Search
wp-build mount	absent	present	present
Legacy #jp-search-dashboard	present	absent	absent
Legacy bundle	build/dashboard/jp-search-dashboard.js + .css	none	none
Dashboard assets	—	routes/dashboard/content.min.js, modules/init/index.min.js	same
Data handle	absent	jetpack-search-dashboard-data-js-before	same
PHP errors	none	none	none

Also checked: Dashboard resolves to each plugin's own jetpack_vendor/ copy; no search-wp-build / WP_BUILD_FEATURE_FLAG / is_wp_build_dashboard_active left in the synced source; build/dashboard/ absent from both plugins; content.min.js serves 200 while the legacy bundle URL 404s. On Atomic the installed mirror confirms build/dashboard/ is gone and jetpack-feature-flags still ships via my-jetpack.

Standalone Search — listed as unverified — behaves identically to Jetpack. Atomic passes with no flag registered anywhere.

The removed WP_BUILD_FEATURE_FLAG and register_feature_flags() were public but arrived in #52416, still unreleased, so no deprecation is owed. The Simple subclass overrides only the menu priority, the constructor, add_wp_admin_submenu(), check_plan_deactivate_search_module() and should_enqueue_tracking_script() — none of them touched here — and it does call init_hooks(), so the wiring holds by inspection.

One suggestion: drop "on every site" from the packages/search changelog entry. #52416 never reached users, so no one saw a site without the frame; the tail points at a flag they never knew existed. The two plugin entries read better as-is.

Not covered: Simple at runtime, and the client-side half everywhere (the #jp-search-dashboard wrapper stage.tsx mounts, the 16px em base, tab routing) — server-side fetches can't reach those, though stage.test.tsx pins the wrapper id.

Verdict: no blockers, merge after the changelog nit.

Terminator

[dhasilva]

Dropped "on every site" from the packages/search entry in 3f13323. The port's entry was Comment:-only and the last release (8.1.2, Sep 15) predates it, so the tail pointed at a state no reader saw. The two plugin entries are unchanged. For the record, My Jetpack's equivalent entry shipped with the same tail in 6.4.0 (#52446); I left that one alone.

On your two gaps: the client-side half is verified locally — the #jp-search-dashboard wrapper, the 36px/40px hero against the wrapper's 16px em base, and tab routing across Overview / Settings / AI Answers, plus a single scroll container now that #52507 has landed. Simple at runtime is still unverified.

Generated by Claude.