You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Consolidate how Studio locates, detects, dumps and prepares the site database #5196
Studio's SQLite handling is spread across about 30 non-test files as repeated literals and calls. Consolidating it into a few helpers simplifies today's code and leaves a few clear places to branch if Studio ever supports another database engine.
Current state (trunk)
The .ht.sqlite path is spelled out 18 times across 9 files: the importer, the Playground validator, pull-reprint, phpMyAdmin, blueprints, sqlite-collations, sqlite-journal-mode, config set and packages/common/lib/sqlite-integration.ts.
Each of these infers the site's database in its own way:
config set checks for the database file;
the Playground validator looks for a database file and no SQL dumps;
wp sqlite export is run from three places in export-database.ts, and wp sqlite import is run separately from importer.ts.
keepSqliteIntegrationUpdated is called from 8 places (create, start, export, import, push, blueprints, the importer), each with its own progress logging.
The AI agent's WP-CLI tool description hardcodes "Studio sites use SQLite" (apps/cli/ai/tools/wp-cli.ts).
Database engine: one getSiteDatabaseEngine( sitePath ), derived from what's on disk; no new stored setting.
Dump and load: a single module with dumpDatabase( site ) and loadDatabase( site, files ) wraps the wp sqlite export/import calls. The collation normalisation stays inside it.
Preparation: one ensureSiteDatabaseReady( site ) replaces the scattered keepSqliteIntegrationUpdated calls and their logging.
AI tool text: the WP-CLI tool's database description comes from the engine helper.
Behaviour is unchanged throughout: same archives, same push format, same database location.
Parking this. Studio has no MySQL plan (the #3997 proof of concept was closed), so a standalone refactor would add review load with no change users can see. When an export needs to include the SQLite database, that change will touch export-database.ts, the exporter's exclusions and the database path. The path and dump/load consolidation described here should be done as part of that work. If another database engine is scheduled later, this issue lists where the seams go.
Reopening: Studio now plans to support MySQL, so this seam is the first step of that work, not a standalone refactor. It will be done on trunk directly instead of on top of #5188. getSiteDatabasePath() returns today's location, and #5188 changes it in one place once it lands. Behaviour stays the same for SQLite sites. Later MySQL work (runtime, creating sites, export and import, conversion) branches off these helpers. The proof of concept in #3997 is the reference.
Update: the stand-alone refactor (#5263) is closed. These helpers (one database path helper, one dump/load module, engine detection) will be built inside the first MySQL support PR, where the MySQL code uses each one, instead of before it.
Activity
chubes4 commentedon Oct 20, 2026
Parking this. Studio has no MySQL plan (the #3997 proof of concept was closed), so a standalone refactor would add review load with no change users can see. When an export needs to include the SQLite database, that change will touch
export-database.ts, the exporter's exclusions and the database path. The path and dump/load consolidation described here should be done as part of that work. If another database engine is scheduled later, this issue lists where the seams go.Comment by Claude Opus via Pi on Chris's behalf.
chubes4 commentedon Oct 21, 2026
Reopening: Studio now plans to support MySQL, so this seam is the first step of that work, not a standalone refactor. It will be done on trunk directly instead of on top of #5188.
getSiteDatabasePath()returns today's location, and #5188 changes it in one place once it lands. Behaviour stays the same for SQLite sites. Later MySQL work (runtime, creating sites, export and import, conversion) branches off these helpers. The proof of concept in #3997 is the reference.Comment by Claude Opus via Pi on Chris's behalf.
chubes4 commentedon Oct 21, 2026
Update: the stand-alone refactor (#5263) is closed. These helpers (one database path helper, one dump/load module, engine detection) will be built inside the first MySQL support PR, where the MySQL code uses each one, instead of before it.
Comment by Claude Opus via Pi on Chris's behalf.