Bug: SQLite database connection error after updating to v1.7.4

[ykrayden]

Quick summary

After updating WordPress Studio from v1.7.3 to v1.7.4 on macOS (Apple Silicon), existing local sites fail to start with Error connecting to the SQLite database. The db.php dropin file in wp-content/ is not regenerated during the update, breaking the SQLite connection for all pre-existing sites.

Steps to reproduce

1. Run WordPress Studio v1.7.3 with an existing local site (SQLite-based)
2. Apply the in-app update to v1.7.4
3. Restart the app
4. Try to start the existing local site

What you expected to happen

The existing site starts normally, as it did in v1.7.3.

What actually happened

The existing site starts normally, as it did in v1.7.3.
What actually happened
The site fails to start with the following error:

Error connecting to the SQLite database.
Failed to start site
Exit code: 1

Note: Newly created sites on v1.7.4 start without issues. Only pre-existing sites are affected. The SQLite database file itself is not corrupted (PRAGMA integrity_check; returns ok).

Impact

Most (> 50%)

Available workarounds?

Yes, easy to implement

Platform

Mac Silicon

Logs or notes

Workaround: Manually restore db.php from Studio's bundled files:

bashcp ~/Library/Application\ Support/Studio/server-files/sqlite-database-integration/db.copy \
   ~/Studio/<site-folder>/wp-content/db.php

Replace with your actual site directory name, then restart the site from the Studio app.

Error log:

[2026-02-19T09:12:52.069Z][erro][main] Error occurred in handler for 'startServer': CliCommandError:
[Last error message] WordPress サーバーを起動できませんでした: Error connecting to the SQLite database.
[Base message] Failed to start site
[Exit code] 1
     at ChildProcess.<anonymous> (/Applications/Studio.app/Contents/Resources/app.asar/dist/main/index.js:26146:21)
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1101:16)
    at ChildProcess._handle.onexit (node:internal/child_process:304:5)

• App version: 1.7.4 (previous: 1.7.3)
• OS: macOS, Apple Silicon (arm64)
• Built from commit: c660abd

[sejas]

@ykrayden, thanks for reporting the issue and for sharing a workaround. I tried following the same steps, but I couldn’t reproduce the issue.

My steps were:

• Downgrade Studio using 1.7.3
• Create a new site using 1.7.3
• Update the App to 1.74
• Start the site just created
• Confirm the site works

I tried it in different languages, too, in case the WordPress setup was different, without any luck.
During every step I confirmed the wp-content/db.php file was there all the time.

I also tried by removing db.php file and the site starts without throwing an error, but then I see the Error establishing a database connection error when accessing the site. I confirm the db.php is not generated in 1.7.3 or 1.7.4 , but I wonder why would be missing in the first place.

@ykrayden , do you know if I'm following the correct steps?

[ykrayden]

@sejas

Thank you for looking into this!

I think the key difference might be that my site was not created on v1.7.3 — it was an existing site that had been running on an older version before 1.7.3. So the steps to reproduce might be:

1. Have an existing site created on a version older than 1.7.3
2. Run it successfully on v1.7.3
3. Keep the site running (active/started) and apply the in-app update to v1.7.4
4. After the update, navigate away from the current page in the app
5. The site becomes unreachable and fails to restart

One important detail: the update was applied while the site was actively running. After the update completed, navigating to another page in the app caused the site to stop responding. On subsequent attempts to restart the site, it failed with the SQLite connection error.

In my case, db.php was present and working on v1.7.3, but after updating to v1.7.4 in this way, the site failed to start. It's possible that updating while the site was active caused db.php to become outdated or incompatible with the new version's SQLite integration.

Copying db.php from the bundled server-files/sqlite-database-integration/db.copy resolved the issue, which suggests the file was outdated rather than missing entirely.

Note: The troubleshooting and root cause analysis were done with the help of Claude AI.

Hope this helps narrow it down!

[wojtekn]

@ykrayden all my sites, even those created months ago, still work fine in 1.7.4.

Do you have a copy of the db.php file from the broken site? Or maybe do you have any other broken sites you could check?

[ykrayden]

@wojtekn

db.php

To give more context: I have 9 sites in total. The first broken site was already reported. I found a second site ('rayden') with a similar issue. This site has not been started or edited for a while — it has been left untouched.

I retrieved its db.php and here is the content:

<?php
/**
 * Plugin Name: SQLite integration (Drop-in)
 * Version: 1.0.0
 * Author: WordPress Performance Team
 * Author URI: https://make.wordpress.org/performance/
 *
 * This file is auto-generated and copied from the sqlite plugin.
 * Please don't edit this file directly.
 *
 * @package wp-sqlite-integration
 */

define( 'SQLITE_DB_DROPIN_VERSION', '1.8.0' );

// Tweak to allow copy-pasting the file without having to run string-replacements.
$sqlite_plugin_implementation_folder_path = realpath( __DIR__ . '/mu-plugins/sqlite-database-integration' );
if ( ! file_exists( $sqlite_plugin_implementation_folder_path ) ) { // Check that the folder exists.
$sqlite_plugin_implementation_folder_path = realpath( __DIR__ . '/plugins/sqlite-database-integration' );
}

Claude AI provided the following analysis:

Comparing this with the current db.copy template bundled in Studio:

$sqlite_plugin_implementation_folder_path = '{SQLITE_IMPLEMENTATION_FOLDER_PATH}';

It looks like the broken db.php is an older version that searches for the SQLite integration in mu-plugins or plugins — but Studio stores it in a different location. Since the path can't be resolved, the file hits the early return and the SQLite connection is never established.

The current db.copy template uses a {SQLITE_IMPLEMENTATION_FOLDER_PATH} placeholder that Studio is supposed to replace with the actual path when generating db.php. It seems this regeneration did not happen during the update, leaving the old incompatible db.php in place.

This second site ('rayden') is interesting because it was not actively running at the time of the update, which suggests the issue may not be limited to sites that were running during the update.

[sejas]

@ykrayden, thanks for providing more information. The db.php file seems correct. It has the same content as the latest db.php on new sites. I also tried replacing your db.php on one of my new sites, and it started correctly. I think the issue might be different, at least in this case.
Could you create zip of your site and share it with me? You can DM me in antoniosejas in Make Slack, X or LinkedIn

Maybe your wp-content/mu-plugins/sqlite-database-integration folder has a different name 🤔

❯ ls -la wp-content/mu-plugins
total 0
drwxr-xr-x@  3 user  staff   96 Feb 20 11:52 .
drwxr-xr-x@ 10 user  staff  320 Feb 20 11:56 ..
drwxr-xr-x@ 17 user  staff  544 Feb 20 12:00 sqlite-database-integration

[ykrayden]

@sejas, Hi, I sent you a reply on X (@ReiwaDengyoInc) to arrange sharing the site zip and logs. Please let me know your preferred way to receive the files. Thank you!