Add save button to developer settings panel (Provider/Model selectors)

[Infinite-Null]

What?

Closes #763

Adds an explicit Save button to the Developer Settings panel (Provider/Model selectors), instead of saving changes immediately on every selection.

Why

Provider and Model changes were being saved as soon as you picked a new option, with no confirmation step. This was inconsistent with the rest of the settings UI, where changes are only saved when you click Save. A moderator flagged this during review.

How to test

1. Navigate to AI Settings and enable Enable AI.
2. Open the Developer Tools menu (three dots) and select Model selection.
3. Change the Provider or Model.
4. Confirm a Save button appears and the change is not saved yet.
5. Click Save and confirm the change persists.
6. Confirm clicking on "Reset to default" shows a Save button, and Save still behaves as expected.

Before / After

Before: Selecting a new Provider or Model saved it instantly.
After: Selecting a new Provider or Model shows a Save button; the change is only saved when you click it.

Screenshots / Recording

Before

Screen.Recording.2026-06-23.at.5.26.45.PM.mov

After

Screen.Recording.2026-06-23.at.5.21.27.PM.mov

Changelog Entry

Added - New feature.
Changed - Existing functionality.
Deprecated - Soon-to-be removed feature.
Removed - Feature.
Fixed - Bug fix.
Security - Vulnerability.
Developer - Development related updates.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.71%. Comparing base (27e202b) to head (0c8acab).
⚠️ Report is 5 commits behind head on develop.

Additional details and impacted files

@@              Coverage Diff              @@
##             develop     #761      +/-   ##
=============================================
+ Coverage      76.41%   76.71%   +0.29%     
  Complexity      1828     1828              
=============================================
  Files             87       87              
  Lines           7764     7764              
=============================================
+ Hits            5933     5956      +23     
+ Misses          1831     1808      -23     

Flag	Coverage Δ
unit	76.71% <ø> (+0.29%)	⬆️

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

☔ View full report in Codecov by Harness.
📢 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.

[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: Infinite-Null <[email protected]>
Co-authored-by: dkotter <[email protected]>

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

[dkotter]

Couple minor things but overall this looks good.

Ideally we get some E2E tests here though, to verify the new save button works and to also verify if you choose a provider/model and don't hit save, those values don't persist on page reload

[Infinite-Null]

Couple minor things but overall this looks good.

Ideally we get some E2E tests here though, to verify the new save button works and to also verify if you choose a provider/model and don't hit save, those values don't persist on page reload

Hi @dkotter, thank you for the feedback! I’ve added the E2E tests to verify the save button behavior and that unsaved provider/model selections do not persist after a page reload. I’ve also made the necessary spacing fallback updates.

When you have a chance, could you please take another look? Thank you!

[dkotter]

One last thing I noticed in my testing that's worth discussing. If I choose a Provider (and/or a Model) and save, if I come back later and click the Reset to default link, I then have to save again for that to persist.

While I know that matches the initial behavior, it almost feels like a user taking the action of clicking Reset should be enough to trigger a save. Any thoughts on that?

[Infinite-Null]

One last thing I noticed in my testing that's worth discussing. If I choose a Provider (and/or a Model) and save, if I come back later and click the Reset to default link, I then have to save again for that to persist.

While I know that matches the initial behavior, it almost feels like a user taking the action of clicking Reset should be enough to trigger a save. Any thoughts on that?

Hi @dkotter, I appreciate you raising this. I had the same thought initially. One consideration I had, though, is that if someone clicks “Reset to default” by mistake, automatically saving it could be unexpected and would immediately overwrite their previously saved provider/model selection.

Keeping it as a pending change that requires Save also stays consistent with the rest of the form behavior, where changes are only persisted after explicitly saving. That said, I’m happy to adjust it if we feel Reset should be treated as an immediate action and reverted to the original behavior.

[dkotter]

One consideration I had, though, is that if someone clicks “Reset to default” by mistake, automatically saving it could be unexpected and would immediately overwrite their previously saved provider/model selection

While that's certainly possible, I would argue it's not likely someone will accidentally click that but if they do, not hard to reselect the provider and model.

On the flip side, when I was testing, I actually didn't realize I needed to hit save again after resetting and took me a bit to figure out why a feature was using the wrong model.

Now that's just my own experience and my own opinion but I'd argue for making the change to auto-save after resetting

[Infinite-Null]

One consideration I had, though, is that if someone clicks “Reset to default” by mistake, automatically saving it could be unexpected and would immediately overwrite their previously saved provider/model selection

While that's certainly possible, I would argue it's not likely someone will accidentally click that but if they do, not hard to reselect the provider and model.

On the flip side, when I was testing, I actually didn't realize I needed to hit save again after resetting and took me a bit to figure out why a feature was using the wrong model.

Now that's just my own experience and my own opinion but I'd argue for making the change to auto-save after resetting

That makes sense, especially given the testing experience you described. I’ve updated the behavior so that clicking “Reset to default” now immediately resets and persists the settings without requiring an additional click on Save. I have also updated the tests accordingly.

@dkotter when you have a moment, I’d appreciate it if you could take a look.

Screen.Recording.2026-06-25.at.1.06.49.AM.mov