Sync site list when CLI creates sites while app is running

[bcotrim]

Related issues

• Fixes STU-1164
• Fixes STU-1163

Proposed Changes

• Add useIpcListener for user-data-updated event in use-site-details.tsx to refresh the site list when the appdata file changes externally (e.g., when CLI creates a site or modifies site settings)
• Handle edge case where the currently selected site is deleted externally by resetting selection to the first available site

Root cause: The file watcher (user-data-watcher.ts) already broadcasts user-data-updated IPC events when the appdata file changes, but use-site-details.tsx was not listening to this event. The snapshot slice listened to it for preview sites, but the main site list did not.

Testing Instructions

Test STU-1164 (Site creation)

1. Open Studio app
2. Build the CLI: npm run cli:build
3. Create a site via CLI: node dist/cli/main.js site create --path /tmp/test-site-cli
4. Verify the new site appears in the sidebar immediately

Test STU-1163 (Site settings changes)

1. Open Studio app with an existing site
2. Open the Settings tab for the site
3. Run node dist/cli/main.js site set-domain hello.wp.local --path PATH_TO_SITE
4. Verify the "Local URL" setting updates in Studio UI
5. Test other commands: set-php-version, set-wp-version, set-https

Pre-merge Checklist

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

[nightnei]

Test STU-1164 (Site creation)

Worked as expected

3. Run node dist/cli/main.js site set-domain hello.wp.local --path PATH_TO_SITE

The changes are not reflected in Studio, tested a few times and reinstalled node_moduels and rebuild

set-php-version

Also changes are not reflected in Studio

set-wp-version

Stucks endlessly on Changing WordPress version… and can't be termninated with controll+c
UPDATE: I got error and again it stucks:

[nightnei]

Run node dist/cli/main.js site set-domain hello.wp.local --path PATH_TO_SITE

Fixed

node dist/cli/main.js site set-wp-version 6.4 --path=~/Studio/bbb

Now I get error. It's newly created site with `node dist/cli/main.js site create --path /tmp/test-site-cli. And Still controll+c doesn't work.

set-php-version

works

set-https

Success, but actually it doesn't work and fails something

[bcotrim]

thanks for the review @nightnei

I couldn't replicate any of the issues, can you run npm install and npm run cli:build and test again please?

[nightnei]

LGTM and works as expected 👍
Looks like something was wrong locally for me when I tested before

[sejas]

We removed and introduced the useIpcListener( 'user-data-updated' listener multiple times in the past. See:

• Removed #2148
• Added #2161
• Removed #2164

I understand this is a good way to update the Studio UI from external changes, such as the CLI creating a new site, although I wonder why we removed it in the first place.

[sejas]

It works as expected. Great work! I confirmed that the site appears automatically in the left sidebar when creating a new site with the Studio CLI. I also tested node dist/cli/main.js site set-domain hello.wp.local --path /tmp/test-site-cli and node dist/cli/main.js site set-php-version 8.4 --path /tmp/test-site-cli.

[fredrikekelund]

In #2172, we decided that Studio should rely on studio site list --watch to subscribe to updates to the list of sites. The logic in src/modules/cli/lib/execute-site-watch-command.ts already supports parsing new sites, AFAICT. The reason new sites don't show up on the front-end is most likely that the site-status-changed IPC event handler only supports sites that already exists.

Instead of implementing this second, competing approach for subscribing to changes, we should look into fixing the site-status-changed IPC event handler.

[fredrikekelund]

This is a concern for a later PR, but I think we should reconsider storing a global list of SiteServer instances in the node process. The CLI (or pm2, really) will soon be the source of truth for whether a server is running. It might make more sense to treat server instances as ephemeral variables in the node process, always reading from disk or the CLI whenever the client process queries them.

[fredrikekelund]

@bcotrim and I just huddled about this change and concluded that while we are both a little concerned about the relationship between the appdata watcher and the site list watcher being confusing, we still think it's a good idea to land this change for now, to resolve the concrete issues at hand and keep up the momentum.

@bcotrim will add a pretty exhaustive comment for now as a first step towards clarifying the relationship between the newly added watcher callback and the site list watcher (src/modules/cli/lib/execute-site-watch-command.ts). He'll also add a Linear issue detailing potential future refactorings in this area, to ensure the architecture remains clear and quality doesn't deteriorate with future changes

[fredrikekelund]

This is up to you, @bcotrim, but I still also think we could consider updating the site-status-changed IPC event handler to also handle new sites and not just existing ones.

[bcotrim]

This is up to you, @bcotrim, but I still also think we could consider updating the site-status-changed IPC event handler to also handle new sites and not just existing ones.

I considered this, but I think it's better to leave it for the refactor:

• Adding it now would still require user-data-updated for cases without PM2 events (stopped site edits/deletions, new sites not started)
• We'd end up with both handlers potentially fetching the site list, adding more overlap

For now, keeping clear separation (status handler = status only, data handler = everything else) seems cleaner until we do the proper refactor.

[fredrikekelund]

I believe I just ran into a regression caused by this PR. While creating a site, the site list seems to get overwritten by the user-data-updated listener. For the user, this means that the "loading screen" is hidden just a second or two after creating the site, and there's no indication in the sidebar that the site is currently being created.

cc @bcotrim