[chubes4]

Related issues

• Fixes Prepare for SQLite Database Integration 3.1's randomized database path #4981
• Related to SHOW CREATE TABLE quotes numeric temporal defaults (DEFAULT 0 → '0'), breaking MySQL import WordPress/sqlite-database-integration#541 (the H5P / DEFAULT 0 push failure). That fix, Normalize zero defaults of temporal columns WordPress/sqlite-database-integration#542, ships in a 3.1.x release, and this PR is what lets Studio move to it.

Important

Blocked on a wp-cli-sqlite-command release. Studio bundles the latest release of that command, currently v1.1.9. On SQLite Database Integration 3.1 it fatals with Undefined constant "Automattic\WP_CLI\SQLite\FQDB", which breaks studio export and studio push. Automattic/wp-cli-sqlite-command#36 fixes this and is merged, but not released yet. Merge this after a release that includes #36. I'll also move the pin here to the 3.1.x release that contains #542 once it ships.

How AI was used in this PR

Claude (Anthropic), via the Pi coding agent and a Homeboy cook, at Chris Huber's direction:

• traced how 3.1 decides whether to move the database;
• produced the change, then reworked the tests by hand;
• ran the real-site verification below;
• drafted this description.

Chris reviewed the approach.

Proposed Changes

SQLite Database Integration 3.1 moves an existing wp-content/database/.ht.sqlite into a randomized wp-content/database/.ht.<hex>/.ht.sqlite the first time it loads, unless an explicit path is configured. Studio reads the database at the fixed path in many places: phpMyAdmin, blueprints, collation repair, journal mode, import/export, pull, and the AI prompt. All of those would lose the database.

• Studio keeps the fixed path for its sites. The db.php drop-in Studio generates now starts with:

  if ( ! defined( 'DB_PATH' ) && ! defined( 'FQDB' ) && ! defined( 'DB_DIR' ) && ! defined( 'DB_FILE' ) ) {
  	define( 'DB_PATH', __DIR__ . '/database/.ht.sqlite' );
  }

  DB_PATH is 3.1's explicit-path constant (Support DB_PATH as the primary database path constant WordPress/sqlite-database-integration#512), so the plugin leaves the database in place. None of the places listed in Prepare for SQLite Database Integration 3.1's randomized database path #4981 need to change.
• Existing sites are covered before 3.1 loads. Studio regenerates its stock drop-in, together with the plugin copy, on start, create, export, push and import.
• Sites that set their own database location in wp-config.php keep it. The guard skips the definition, and custom SQLite drop-ins are still preserved.
• The fixed path never leaves the machine. Exports and pushes already exclude wp-content/database and wp-content/db.php, so the randomized path's defense against web downloads isn't needed for Studio sites.
• Bumps SQLite Database Integration from 3.0.2 to 3.1.0.

Testing Instructions

Upgrade an existing site:

1. With Studio from trunk (SQLite 3.0.2), create a site, add a post, and stop it.
2. Build the CLI from this branch (npm run cli:build) and start the same site with it.
3. Check that wp-content/mu-plugins/sqlite-database-integration/load.php reports 3.1.0 and that wp-content/db.php starts with the DB_PATH definition.
4. Check that wp-content/database/ still contains .ht.sqlite, and no .ht.<hex>/ directory or db-path.php.
5. Check that the site serves the post and that wp eval 'echo DB_PATH;' prints <site>/wp-content/database/.ht.sqlite.

Export (needs wp-cli-sqlite-command with #36): replace apps/cli/dist/cli/wp-files/sqlite-command with a trunk build, then run studio export. Check that:

• the SQL dump contains every table and the post;
• the archive contains no wp-content/database or wp-content/db.php;
• the dump imports into MySQL with sql_mode='STRICT_TRANS_TABLES'.

Without the DB_PATH definition, step 4 shows the database moved into .ht.<hex>/.ht.sqlite. I verified this on a copy of the same site.

Results:

Check	Result
Upgrade start 3.0.2 → 3.1.0	Database stayed at wp-content/database/.ht.sqlite; post served; DB_PATH fixed
Same site, no DB_PATH	Database moved to .ht.<hex>/.ht.sqlite
studio export with bundled sqlite-command v1.1.9	❌ Undefined constant FQDB (blocker above)
studio export with sqlite-command trunk (#36)	✅ 12 tables + post, no database files in archive, strict MySQL import OK
vitest run packages/common/lib/tests/sqlite-integration.test.ts	58 passed; the new DB_PATH test fails without the change
npm run typecheck --workspace packages/common, eslint	Clean

Not covered: importing a Playground export that uses the randomized layout. The importer matches any wp-content/database/**/.ht.sqlite and moves it to the fixed path, so it should work, but I haven't tested it.