Skip to content

Studio: site shows offline after import - #4106

Merged
katinthehatsite merged 2 commits into
trunkfrom
fix/sites-marked-as-stopped-after-import
Jul 10, 2026
Merged

Studio: site shows offline after import#4106
katinthehatsite merged 2 commits into
trunkfrom
fix/sites-marked-as-stopped-after-import

Conversation

@katinthehatsite

Copy link
Copy Markdown
Contributor

Related issues

Fixes STU-1982

How AI was used in this PR

It was used to identify the best approach to use.

Proposed Changes

This PR ensures that the site that was previously started remains started after either import or pull processes complete.

Testing Instructions

  • Pull the changes from this branch
  • Build CLI with npm run cli:build
  • Run node apps/cli/dist/cli/main.mjs site create --name test-status
  • Confirm that the site shows as online
  • Run node apps/cli/dist/cli/main.mjs import <backup.tar.gz> --path ~/Studio/test-status (replace the backup link with your own backup)
  • Run node apps/cli/dist/cli/main.mjs site list
  • Open a site in a browser and confirm it is online
  • Test the same steps on trunk and confirm that the site is showing as offline after import

Pre-merge Checklist

  • Have you checked for TypeScript, React or other console errors?
@katinthehatsite katinthehatsite self-assigned this Jul 7, 2026
@katinthehatsite
katinthehatsite requested a review from a team July 7, 2026 12:22
@wpmobilebot

wpmobilebot commented Jul 7, 2026

Copy link
Copy Markdown
Collaborator

📊 Performance Test Results

Comparing 621aa15 vs trunk

app-size

Metric trunk 621aa15 Diff Change
App Size (Mac) 1419.25 MB 1411.79 MB 7.45 MB 🟢 -0.5%

site-editor

Metric trunk 621aa15 Diff Change
load 754 ms 1093 ms +339 ms 🔴 45.0%

site-startup

Metric trunk 621aa15 Diff Change
siteCreation 6513 ms 6987 ms +474 ms 🔴 7.3%
siteStartup 2395 ms 2401 ms +6 ms ⚪ 0.0%

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

@bcotrim bcotrim left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Thanks for fix, LGTM 👍

One suggestion: I would move the updateSiteLatestCliPid inside the startWordPressServer. It's a small refactor, but it would ensure we would never run into this issue again.
What do you think?

@gcsecsey gcsecsey left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I also ran into this issue recently and this solution LGTM.

@gcsecsey

gcsecsey commented Jul 9, 2026

Copy link
Copy Markdown
Member

I'm working on E2E tests that will verify this fix too, so I'd like to proceed with landing this. @bcotrim I think the refactor you suggested makes sense, I looked into implementing it, and pushed it as a single commit for now, let me know what you think.

@bcotrim

bcotrim commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

LGTM @gcsecsey 👍

@katinthehatsite

Copy link
Copy Markdown
Contributor Author

Thanks for making the adjustments @gcsecsey - I will go ahead and merge this now 👍

@katinthehatsite
katinthehatsite merged commit bdea6df into trunk Jul 10, 2026
11 checks passed
@katinthehatsite
katinthehatsite deleted the fix/sites-marked-as-stopped-after-import branch July 10, 2026 07:31
gcsecsey added a commit that referenced this pull request Jul 13, 2026
## Related issues

- Related to STU-1870
- The running-site case is the regression test for STU-1982 / #4106

## How AI was used in this PR

Claude Code planned and implemented the suite under my direction. The
running-site case caught the STU-1982 bug independently before we found
the existing issue and fix. I reviewed the result.

## Proposed Changes

Import coverage currently lives only in the Playwright desktop suite,
which the migrate-E2E-to-CLI project is moving away from.

This PR adds real end-to-end CLI coverage using the minimal in-repo
fixtures from #4151 (generated from the "MyPet" demo site):

- Each supported backup format is imported into a freshly created site
via the built CLI. Each case asserts the import exists cleanly, the
backup's custom theme lands on disk, the SQLite database is created, and
the imported content is really served (`wp option get blogname` →
`MyPet`) against a stopped site, exercising the in-process PHP-WASM
path.
- The running-site case verifies that importing into a running site
stops it and restores it to running afterward. This is the symptom of
STU-1982 (`site list` reporting Offline after import), now guarded
against regression.
- It also fixes a dev-machine-only gap in the shared e2e harness:
`runCli` didn't isolate the legacy Electron appdata lookup, so the
`00-check-studio-compatibility` migration could find a developer's real
pre-split `appdata-v1.json` and abort the CLI — passing in CI (clean
machines), failing locally. The same fix rides the STU-1871
blueprint-tests branch; whichever merges second drops its copy in a
trivial merge.

The new tests are tagged `e2e`: they're skipped in the per-PR unit job
(which doesn't build the CLI), so they add zero per-PR CI cost, and run
in the manual "CLI E2E Tests" Buildkite job alongside the other migrated
suites.

## Testing Instructions

1. `npm run cli:build`
2. `npm test -- apps/cli/commands/tests/import.e2e.test.ts`
3. Optionally run the whole slow suite: `npm test -- --tagsFilter='e2e'
--no-file-parallelism`

## Pre-merge Checklist

- [ ] Have you checked for TypeScript, React or other console errors?

---------

Co-authored-by: Rahul Gavande <rahul.gavande@automattic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

4 participants