Skip to content

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

Closed as not planned

Description

@chubes4

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:
  • 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).

Plan

  1. Database path: one getSiteDatabasePath( sitePath ) used by every caller. Stacked on Keep the SQLite database at a fixed path with DB_PATH #5188, which sets the fixed path through DB_PATH.
  2. Database engine: one getSiteDatabaseEngine( sitePath ), derived from what's on disk; no new stored setting.
  3. 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.
  4. Preparation: one ensureSiteDatabaseReady( site ) replaces the scattered keepSqliteIntegrationUpdated calls and their logging.
  5. 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.

Activity

  1. chubes4 commented on Oct 20, 2026

    @chubes4
    ContributorAuthor

    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.

  2. chubes4 commented on Oct 21, 2026

    @chubes4
    ContributorAuthor

    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.

  3. chubes4 commented on Oct 21, 2026

    @chubes4
    ContributorAuthor

    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.

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions