Skip to content

Conversation

@bcotrim
Copy link
Contributor

@bcotrim bcotrim commented Dec 24, 2025

Related issues

Proposed Changes

  • Add quit confirmation dialog when user quits Studio with running sites
  • Dialog offers two options: "Stop sites" or "Leave running"
  • "Remember my choice" checkbox saves preference to skip dialog on future quits
  • Store preference as stopSitesOnQuit boolean in user data (undefined = show dialog, true = stop, false = leave running)
  • Add getRunningSiteCount() helper function to track running sites
  • Conditionally stop servers on quit based on user preference

Testing Instructions

Happy Path

  • Start one or more sites, then quit Studio (Cmd+Q or close window)
  • Verify modal appears with "Stop sites" and "Leave running" buttons
  • Click "Stop sites" → verify sites stop, then app quits
  • Click "Leave running" → verify app quits but sites continue running (check with studio site list)

Remember Choice

  • Start a site, quit Studio, check "Remember my choice", click "Stop sites"
  • Start a site again, quit Studio → verify no dialog appears and sites stop
  • To reset: manually delete stopSitesOnQuit from ~/Library/Application Support/WordPress Studio/appdata-v1.json

Edge Cases

  • Quit with no running sites → no dialog should appear
  • CMD+Q keyboard shortcut respects modal behavior

Pre-merge Checklist

  • Have you checked for TypeScript, React or other console errors?

@bcotrim bcotrim self-assigned this Dec 24, 2025
@bcotrim bcotrim requested review from a team and fredrikekelund December 24, 2025 15:37
src/index.ts Outdated
runningSiteCount
),
buttons: [ __( 'Stop sites' ), __( 'Leave running' ) ],
checkboxLabel: __( 'Remember my choice' ),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use something lile "Don't ask again" to be consistent with other checkboxes around the app?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that actually we have default fallback as Don't show this warning again. I would propose change teh default value to Don't ask again and remove checkboxLabel here and in src/components/content-tab-import-export.tsx

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I am generally okay to keep Don't show this warning again as default as well. I think the default wording could be either of those but I don't think we should introduce another option such as Remember my choice. I think we should stick to the same wording everywhere across the app.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it to Don't ask again for consistency with other dialogs.
My original reasoning for Remember my choice was to make it explicit that we'd save and use that choice in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that actually we have default fallback as Don't show this warning again. I would propose change teh default value to Don't ask again and remove checkboxLabel here and in src/components/content-tab-import-export.tsx

I agree we should standardize the checkbox across the app. To avoid increasing the scope of this PR, I propose we do that refactor in a follow-up after this one is merged.

checkboxLabel: __( 'Remember my choice' ),
cancelId: LEAVE_RUNNING_BUTTON_INDEX,
defaultId: STOP_SITES_BUTTON_INDEX,
} );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it looks fine but I am wondering about the scenario where the user might change their mind and for example, might want to stop some sites manually. Should not they have an option to close this disalog without picking anything?

Image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, if we go with adding this option, let's ensure that the Esc button just closes the popup, since now it applies "closing app w/o turning off sites", which is IMO a bit unexpected.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to this one, I think we should provide some way for the user to get out of this screen.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the suggestions, I added a Cancel option, that is also triggered by Esc

Copy link
Contributor

@fredrikekelund fredrikekelund left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the points made by @katinthehatsite. Functionality-wise, this is good, though 👍

E2E tests are currently broken for other reasons, too, but I believe we'll need to add some explicit handling for E2E test cases here, too. I.e., fall back to the previous logic in the E2E test context and don't display this modal.

src/index.ts Outdated
Comment on lines 104 to 105
let isQuittingConfirmed = false;
let shouldStopSitesOnQuit = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional, but I would consider moving these variable declarations inside appBoot, closer to where they're actually used.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine, but I'm assuming the AI wrote these tests, and I'm starting to question the value of tests written entirely by AI. This is a very testable function, so the tests are easy to read, but I know I'll be trying the inverse approach soon: TDD and letting the AI write the implementation based on my tests.

Copy link
Contributor

@nightnei nightnei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for addressing the changes

I agree we should standardize the checkbox across the app. To avoid increasing the scope of this PR, I propose we do that refactor in a follow-up after this one is merged.

Makes sense 👍

Functionality-wise, "Stop sites" doesn't work for me. Could you please double-test it? And in appdata-v1.json I still see "autoStart": true,, maybe it my local issue or maybe it's due to runnign Studiio via npm start instead of builded version 🤔

@fredrikekelund
Copy link
Contributor

And in appdata-v1.json I still see "autoStart": true

I believe this is what we want. Whether or not we stop the servers when quitting Studio has more to do with the CLI than with changing Studio's existing behavior. We fully expect that most users won't work with the CLI, so the fact that the new "default" is the same as the old default, just gated by a button in this modal, makes a lot of sense to me.

@fredrikekelund
Copy link
Contributor

@bcotrim, something struck me just now: do you think there's a case to be made for not displaying this modal if the user hasn't installed/activated the Studio CLI? The reason for this change is really that users might have started sites using the CLI, and they might not expect them to be stopped just because they close Studio.

@katinthehatsite
Copy link
Contributor

Functionality-wise, "Stop sites" doesn't work for me. Could you please double-test it? And in appdata-v1.json I still see "autoStart": true,, maybe it my local issue or maybe it's due to runnign Studiio via npm start instead of builded versio

This seems to be working as expected for me - the sites were stopped one by one when I chose that option.

On my end, things look good 👍 I will approve later once other comments are addressed.

@bcotrim
Copy link
Contributor Author

bcotrim commented Jan 6, 2026

@bcotrim, something struck me just now: do you think there's a case to be made for not displaying this modal if the user hasn't installed/activated the Studio CLI? The reason for this change is really that users might have started sites using the CLI, and they might not expect them to be stopped just because they close Studio.

That makes sense, added in 35e4b2d

Functionality-wise, "Stop sites" doesn't work for me. Could you please double-test it? And in appdata-v1.json I still see "autoStart": true,, maybe it my local issue or maybe it's due to runnign Studiio via npm start instead of builded version 🤔

I couldn't replicate the issue, with CLI installed or not. All tests were done running npm start. Could you check again and share more details, please? Do you see anything in the logs?

Copy link
Contributor

@fredrikekelund fredrikekelund left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍 It takes a while for all sites to stop after quitting the app and choosing Stop sites (maybe that's what @nightnei observed in #2314 (review)). This PR doesn't make a difference on that front, but it's good to be aware of.

#2299 has a small change to how sites are stopped (the site stop-all child process is forked in detached mode). It won't make a difference to performance, but again, good to be aware of.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants