Skip to content

Consolidate how Studio locates, detects, dumps and prepares the site database - #5263

Closed
chubes4 wants to merge 1 commit into
trunkfrom
fix/issue-5196-studio
Closed

chubes4 wants to merge 1 commit into
trunkfrom
fix/issue-5196-studio

Conversation

@chubes4

@chubes4 chubes4 commented Oct 21, 2026

Copy link
Copy Markdown
Contributor

Related issues

How AI was used in this PR

The refactor and its tests were written by the Pi coding agent on Homeboy's heavy tier (roadie/cook-heavy); the run records don't say which model served it. Claude Opus via Pi reviewed the result, reverted two out-of-scope test-harness edits the agent made (vitest.config.ts, the native PHP router e2e test), moved the new tests into tests/ folders, ran the gates and wrote this description. Homeboy's candidate adoption got stuck, so the commit was pushed and this PR opened by hand rather than by Cook. Chris reviews the PR before it merges.

Proposed Changes

This is the first step toward MySQL support in Studio; #3997 is the earlier proof of concept. Today the code that finds, detects, dumps and prepares a site's database is scattered through the CLI. This collects it behind a few helpers, so a second database engine only has to plug in at those points. Nothing changes for SQLite sites.

  • Location: getSiteDatabasePath( sitePath ) in packages/common/lib/site-database.ts is now the only place that builds the .ht.sqlite path. Before, it was written out in 9 files. When Keep the SQLite database at a fixed path with DB_PATH #5188 lands, it changes the path in that one place.
  • Engine detection: getSiteDatabaseEngine( sitePath ) decides between SQLite and an external MySQL wp-config.php using the rule needsSqliteSetup already used. config set, the Playground import validator and SQLite setup all call it now.
  • Dump and load: dumpDatabase() and loadDatabase() in apps/cli/lib/site-database/ wrap the wp sqlite export and wp sqlite import calls that export, push and the importer used to make separately. Collation normalisation stays inside them. export-database.ts is gone.
  • Preparation: ensureSiteDatabaseReady( sitePath ) replaces the 8 separate keepSqliteIntegrationUpdated calls. Each caller keeps its own progress messages.
  • AI tool text: the database part of the wp_cli tool description now comes from the engine and path helpers. The text is the same as before.

Testing Instructions

Unit tests cover the new helpers. The existing tests pass with only their imports and mocks updated.

  • npm run lint && npm run typecheck && npm test -- --tagsFilter='!e2e' passes locally: 3,175 tests.
  • Smoke test that nothing changed:
    1. studio site create a site, then start it, and check WordPress loads.
    2. studio export <file>.zip --path <site> --mode full, then unzip -l it. The sql/ dump should be there, the same as from trunk.
    3. Import that archive into a new site and check that the content arrives.
    4. Push a site to a WordPress.com staging site, if you have one.

Pre-merge Checklist

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

@chubes4

chubes4 commented Oct 21, 2026

Copy link
Copy Markdown
Contributor Author

Closing. On its own this adds about 54 lines of production code for helpers that only MySQL would use, and there's no MySQL code yet. The database helpers will go into the first MySQL PR instead, so each one is added when something actually calls it. The branch stays up for reference.

Comment by Claude Opus via Pi on Chris's behalf.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Consolidate how Studio locates, detects, dumps and prepares the site database

1 participant