Make WP install/DB checks resilient to post-flush stdout (fixes false-negative "Error connecting to the SQLite database")

[ivan-ottinger]

Symptom

Running @wp-playground/cli server with --wordpress-install-mode=install-from-existing-files-if-needed against an imported WordPress site exits with:

Error: Error connecting to the SQLite database.

…on a site whose SQLite database is healthy (PRAGMA integrity_check returns ok, wp_options.siteurl is set, all WordPress tables are present). Switching only the --wordpress-install-mode flag to do-not-attempt-installing boots the same site cleanly, which rules out the site, the file mount, and the SQLite plugin as the cause.

Reproducer

# Fails with "Error: Error connecting to the SQLite database." (process exits)
npx -y @wp-playground/cli@3.1.28 server \
  --port=8902 --site-url=http://localhost:8902 \
  --mount=/path/to/site:/wordpress \
  --wordpress-install-mode=install-from-existing-files-if-needed

# Same site, only the install-mode changes — boots fine
npx -y @wp-playground/cli@3.1.28 server \
  --port=8901 --site-url=http://localhost:8901 \
  --mount=/path/to/site:/wordpress \
  --wordpress-install-mode=do-not-attempt-installing

We have a real-world Jetpack-backed site backup that reproduces this deterministically: https://linear.app/a8c/issue/PLAYGRD-653/bug-wordpress-install-modeinstall-from-existing-files-if-needed-fails

What I observed in the code

packages/playground/wordpress/src/boot.ts has two functions that each run a small PHP probe with ob_start() / ob_clean() / ob_end_flush(), then strictly compare the captured PHP stdout to "1":

• isWordPressInstalled() — line 511, returns result.text === '1' on line 529
• isDatabaseConnectionValid() — line 639, returns result.text === '1' on line 639

The user-facing Error: Error connecting to the SQLite database. is thrown when one of these checks returns false. In the failing reproducer above, that happens on a site where the underlying state we can independently inspect (database integrity, WP options, tables) is fine. So the boolean these functions return doesn't reflect the site state — something about the captured result.text makes the strict-equality check return false.

I did not pinpoint exactly what is in result.text in the failing run.

Status across versions

The same text === "1" lines are present in:

• @wp-playground/wordpress@3.1.28
• @wp-playground/wordpress@3.1.33 (latest published as of writing)

So the symptom is reproducible on both, and there's no parallel fix already shipped.

Proposed fix

Wrap the controlled output in a sentinel and match by .includes() instead of ===. This makes the check tolerant of any extra bytes that may end up alongside the '1'/'0'.

-			echo is_blog_installed() ? '1' : '0';
+			echo '<<PG-RESULT:' . ( is_blog_installed() ? '1' : '0' ) . ':END>>';
 			ob_end_flush();
 		`,
 		env: { DOCUMENT_ROOT: php.documentRoot },
 	});
-	return result.text === '1';
+	return result.text.includes('<<PG-RESULT:1:END>>');

Both call sites get the same change. The -1 (file-not-found) branch is also wrapped to keep the protocol uniform — both existing callers only check the boolean return, so behavior is unchanged for the negative case. packages/playground/wordpress/src/legacy-wp/legacy-boot.ts uses different probes and is unaffected.

Verification

Patched a local copy of @wp-playground/wordpress with this diff and re-ran the failing reproducer above. With the patch applied, the wp server starts cleanly and the site is reachable. Without the patch, the same command fails as described in the symptom section.