Add modern wp-build DataForm route for AI settings page

[jorgefilipecosta]

Summary

• Adds a new wp-build route (routes/ai-home/) that renders the AI settings page using @wordpress/dataviews DataForm and @wordpress/admin-ui Page components
• Exposes AI settings via the REST API (show_in_rest) so the frontend can read/save them
• Replicates the existing settings page layout using DataForm card layouts with collapsible sections
• Adds a page header with AI flask icon, subtitle, and Docs/Contribute action buttons (matching the design from Improve AI Experiments page UI with header, accordion, and entry points #153)

Key changes

• routes/ai-home/stage.tsx — Full DataForm-based settings page with:
  • General Settings card (global AI toggle)
  • Editor Experiments card (6 experiment toggles)
  • Admin Experiments card (1 experiment toggle)
  • Disabled checkbox state when global AI is off
  • REST API integration for loading/saving settings
  • Page header with AI icon and action buttons
• routes/ai-home/style.scss — Centered layout (max-width 680px) matching the Connectors page design
• includes/Settings/Settings_Registration.php — Added show_in_rest => true to all settings
• package.json — Added @wordpress/admin-ui and @wordpress/dataviews dependencies

Note on tools/ensure-boot-asset.cjs

The wp-build generated page template (page-wp-admin.php) hardcodes a reference to build/modules/boot/index.min.asset.php for dependency metadata. In Gutenberg core this file is generated from packages/boot/, but plugins don't have a local boot package — they rely on WordPress core's @wordpress/boot script module.

The tools/ensure-boot-asset.cjs script creates a small PHP proxy that defers to core's boot asset at runtime. This is necessary until @wordpress/build adds plugin-aware boot asset resolution (i.e., falling back to core's wp-includes/js/dist/script-modules/boot/index.min.asset.php when no local boot package exists).

Test plan

• Run npm run build:routes then visit Settings > AI (New)
• Verify header shows AI icon, title, subtitle, Docs and Contribute buttons
• Toggle experiments on/off and click Save — changes should persist on reload
• Disable the global AI toggle — experiment checkboxes should become disabled
• Enable the global AI toggle — experiment checkboxes should become editable again
• Verify settings sync with the old page at Settings > AI

Screenshot

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>
Co-authored-by: dkotter <dkotter@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: jeffpaul <jeffpaul@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[codecov]

Codecov Report

❌ Patch coverage is 60.36036% with 44 lines in your changes missing coverage. Please review.
✅ Project coverage is 61.28%. Comparing base (7d20bba) to head (f5a6a4e).
⚠️ Report is 129 commits behind head on develop.

Files with missing lines	Patch %	Lines
includes/Settings/Settings_Page.php	0.00%	30 Missing ⚠️
includes/bootstrap.php	91.78%	6 Missing ⚠️
includes/Asset_Loader.php	0.00%	4 Missing ⚠️
ai.php	0.00%	2 Missing ⚠️
includes/Settings/Settings_Registration.php	0.00%	2 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             develop     #340      +/-   ##
=============================================
+ Coverage      58.09%   61.28%   +3.19%     
+ Complexity       630      609      -21     
=============================================
  Files             46       46              
  Lines           3193     3136      -57     
=============================================
+ Hits            1855     1922      +67     
+ Misses          1338     1214     -124     

Flag	Coverage Δ
unit	61.28% <60.36%> (+3.19%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gziolo]

@dkotter or @justlevine, can you verify that the proposed approach to the build step is compatible as the intermediate step? It would allow converge on one approach in other PRs, namely I was thinking about this work from @Jameswlepage:

• Add AI Request Logging experiment with observability dashboard #149

[jeffpaul]

Ideally we're able to show Features at the top of the page, here's some low-fi mockups of what this could look like: #234 (comment)

[dkotter]

Left a few minor comments but overall this looks okay to me. Not sure I love the actual UI but that's probably a separate conversation.

One thing we are missing here is previously we have a single button to enable/disable things. We've now reverted back to a checkbox that requires you to also hit the save button. Any chance we can bring that single button click back, as that was a requested enhancement we added a few releases back.

[dkotter]

@dkotter or @justlevine, can you verify that the proposed approach to the build step is compatible as the intermediate step? It would allow converge on one approach in other PRs, namely I was thinking about this work from @Jameswlepage:

Changes to the build script look fine to me, assuming this question is around the changes in package.json? Seems to properly support building our current scripts and also support the new Dataviews UI. Would be great if we could use a single approach for both but no concern from me on how this currently works.

[gziolo]

I tested this PR and here are my findings:

• npm run build and npm run build:routes — both work correctly.
• Browser testing — everything works as expected.
• npm run start — the Settings > AI menu disappears. The issue is that wp-scripts start and wp-build --watch run concurrently and share the same build/ folder. One wipes the other's output, so the generated PHP files needed for the admin menu registration get lost.

Proposed fix: Use separate build folders for each tool so they don't interfere with each other during development.

[jorgefilipecosta]

Addressed the npm run start conflict. The root cause is webpack's output.clean.keep regex only preserving fonts/ and images/, which wipes all wp-build output on every rebuild.

Regarding separate build folders — both wp-build (BUILD_DIR hard-coded in build.mjs) and Asset_Loader.php (hard-codes build/ paths) would need upstream changes, so that's not feasible right now.

Instead, extended the clean.keep regex in webpack.config.js to also preserve wp-build directories (modules, pages, routes, scripts, styles). This lets both tools coexist in build/ during watch mode — webpack still cleans its own stale output normally.

[jorgefilipecosta]

Hi @gziolo, @dkotter thank you a lot for the reviews, I think all the feedback was applied.

[justlevine]

This is necessary until @wordpress/build adds plugin-aware boot asset resolution

would need upstream changes, so that's not feasible right now.

Yah the wp-admin part is required it is wp-build works.

@jorgefilipecosta @gziolo how future-compat is this current config?

It's one thing to be dogfooding a library to provide early feedback, but based on the lack of basic "plugin" support and these coexistence workarounds y'all had to find, how confident do you feel that our config won't require undue maintenance while the lib has a chance to stabilize?

If it is unstable, I ultimately defer to @dkotter and @jeffpaul as to whether they think it's a good idea to assume the potential tech debt, but I do want to remind folks that we're not just about to become a canonical plugin, but we're about to become the first canonical plugin that WordPress directly promotes in Core, and we don't want a breaking 0.3.0 holding up a patch or security release while we're still getting our feet wet.

I'm not sure what parts of this new build process are required for the latest dataviews lib, nor what about the new build process delayed WP7.0/how it was eventually resolved and whether it's relevant to us here, but assuming knowing both help decide whether this is a conversation worth having, or premature worry.

---

(Changes themselves look fine to me 🚀)

[gziolo]

@justlevine, all fair feedback. I wasn’t aware of all the limitations of wp-build surfaced in this PR. I’m less worried about that as Gutenberg and WP core also use it, so in theory it should improve substantially over time.

@jorgefilipecosta, wp-scripts is flexible enough to output to a different folder. If I recall correctly in the past Gutenberg was using two different build folders to avoid race conditions between scripts and script modules. The solution you proposed works today but it really brittle and something unexpected can pop up in the future as soon wp-build will need its cleanup. It all really depends on how long two build systems will coexist. Therefore, I’m too worried about it, but it’s important to keep it in mind.

[dkotter]

Overall this looks good to me, noting we do lose the single click, toggle things on that we have right now (I think I flagged this in Slack or on GitHub somewhere). That does feel like a regression, as I know have to click a checkbox and then click the save button instead of just clicking a single button. If it's possible to update that, I think that would be great but not something that needs to be part of this PR.

Edit: also looks like a failing E2E test that would be great to clean up

[jorgefilipecosta]

@justlevine, all fair feedback. I wasn’t aware of all the limitations of wp-build surfaced in this PR. I’m less worried about that as Gutenberg and WP core also use it, so in theory it should improve substantially over time.

@jorgefilipecosta, wp-scripts is flexible enough to output to a different folder. If I recall correctly in the past Gutenberg was using two different build folders to avoid race conditions between scripts and script modules. The solution you proposed works today but it really brittle and something unexpected can pop up in the future as soon wp-build will need its cleanup. It all really depends on how long two build systems will coexist. Therefore, I’m too worried about it, but it’s important to keep it in mind.

Good point @gziolo, I updated to use two distinct folders as suggested.

[jorgefilipecosta]

Given that I did the small two folders change I will need another approval.

[jorgefilipecosta]

Overall this looks good to me, noting we do lose the single click, toggle things on that we have right now (I think I flagged this in Slack or on GitHub somewhere). That does feel like a regression, as I know have to click a checkbox and then click the save button instead of just clicking a single button. If it's possible to update that, I think that would be great but not something that needs to be part of this PR.

Edit: also looks like a failing E2E test that would be great to clean up

Hi @dkotter
CI is green. I will happily iterate on the UI as follow up to get auto saving and something closer to the mockup @jeffpaul shared, I guess as immediate next steps we should replace checkbox with toggle control and remove the save to have auto save.

[gziolo]

Tested locally — both build folders work correctly in production and development modes. The two-folder approach cleanly avoids the watch-mode race condition. Approved, with agreed follow-ups to be tackled separately (toggle controls + auto-save, UI closer to mockups).

[justlevine]

@jorgefilipecosta was there a particular reason this version was chosen when the latest version available is 0.9.0?

There's no changelog in the repo...