Repository navigation
Conversation
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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 intotests/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.
getSiteDatabasePath( sitePath )inpackages/common/lib/site-database.tsis now the only place that builds the.ht.sqlitepath. 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.getSiteDatabaseEngine( sitePath )decides between SQLite and an external MySQLwp-config.phpusing the ruleneedsSqliteSetupalready used.config set, the Playground import validator and SQLite setup all call it now.dumpDatabase()andloadDatabase()inapps/cli/lib/site-database/wrap thewp sqlite exportandwp sqlite importcalls that export, push and the importer used to make separately. Collation normalisation stays inside them.export-database.tsis gone.ensureSiteDatabaseReady( sitePath )replaces the 8 separatekeepSqliteIntegrationUpdatedcalls. Each caller keeps its own progress messages.wp_clitool 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.studio site createa site, then start it, and check WordPress loads.studio export <file>.zip --path <site> --mode full, thenunzip -lit. Thesql/dump should be there, the same as from trunk.Pre-merge Checklist