SQLite refresh breaks WordPress 5.0–5.4 legacy boot tests #4256

Summary

The August 11 SQLite integration refresh in e60564b breaks Playground boot for WordPress 5.0–5.4 on PHP 7.4. WordPress 5.5+ continues to pass, and WordPress 4.9 and older continue to pass through the separately pinned PHP 5.2 SQLite build.

This is a trunk regression rather than a failure caused by PR #4240. The trunk CI job shows the same version-specific SQLite failures: https://github.com/WordPress/wordpress-playground/actions/runs/31478314132/job/93737171584

Observed behavior

• WordPress 5.0–5.4 on PHP 7.4 time out while displaying Error connecting to the SQLite database.
• All five versions fail again during the test script's transient-failure retry.
• WordPress 5.5–6.2 on PHP 7.4 pass.
• WordPress 4.9 and older on PHP 5.2 pass.
• The previous SQLite refresh's test-legacy-wp-version-boot job passed: https://github.com/WordPress/wordpress-playground/actions/runs/30899567679/job/91960436903
• The current trunk job reaches the 30-minute timeout while retrying the failures, so GitHub reports it as cancelled rather than exposing the underlying deterministic regression cleanly.

Root cause

The refreshed archive includes WordPress/sqlite-database-integration#479, which removed the WP_SQLite_DB::db_version() override and retained only WP_SQLite_DB::db_server_info().

WordPress 5.0–5.4 predates wpdb::db_server_info(). Its inherited wpdb::db_version() directly calls mysqli_get_server_info( $this->dbh ) or mysql_get_server_info( $this->dbh ). For the SQLite drop-in, $this->dbh is a WP_MySQL_On_SQLite object rather than a native MySQL connection, so the legacy implementation cannot be used.

WordPress 5.5 introduced wpdb::db_server_info() and changed wpdb::db_version() to derive the numeric version from that overridable method. That explains the exact compatibility boundary: 5.0–5.4 fail while 5.5+ pass.

WordPress 4.9 and older do not encounter the refreshed implementation because Playground selects the pinned v3.0.0-rc.3-php52 archive for legacy PHP.

Immediate fix

Restore a compatibility override in WP_SQLite_DB upstream and then refresh Playground's generated SQLite archive:

public function db_version() {
	return preg_replace(
		'/[^0-9.].*/',
		'',
		$this->db_server_info()
	);
}

This keeps the full emulated server identity in db_server_info(), returns the numeric version expected by WordPress capability checks, avoids native MySQL calls on WordPress before 5.5, and matches the behavior of WordPress 5.5+.

If the upstream plugin does not intend to support WordPress below its declared minimum, Playground can temporarily restore trunk by pinning the last known-good SQLite archive instead.

Longer-term fix

Playground currently chooses the SQLite archive primarily by PHP version: PHP 5.2 receives the pinned patched archive, while everything else receives the moving SQLite trunk archive. That exposes WordPress 5.0–6.3 to upstream changes made under a newer declared WordPress minimum.

Introduce an explicit legacy-modern SQLite build and select it using both WordPress and PHP versions:

• PHP 5.2: pinned and PHP-5.2-patched SQLite build.
• WordPress below the current SQLite plugin's supported minimum on modern PHP: pinned legacy-modern SQLite build.
• Supported WordPress versions: current SQLite trunk build.

The selection logic should be shared by the website worker and CLI paths so both environments boot the same WordPress/PHP combinations with the same driver.

CI follow-up

Issue #3753 already proposes sharding test-legacy-wp-version-boot through its existing WP_ONLY filter. Sharding would make compatibility regressions like this fail faster and avoid exhausting the 30-minute job limit, but it is not a substitute for fixing or pinning the incompatible SQLite driver.

Acceptance criteria

• WordPress 5.0–5.4 boot successfully on PHP 7.4 in test-legacy-wp-version-boot.
• WordPress 5.5–6.2 and the PHP 5.2 legacy matrix remain green.
• The SQLite version-selection policy is explicit about unsupported WordPress versions.
• Website and CLI SQLite selection remain consistent.
• A refreshed SQLite archive cannot silently move legacy WordPress onto an incompatible driver.