[website] Fix broken e2e tests because of sqlite db integration update

[akirk]

Motivation for the change, related issues

The SQLite database integration plugin was refreshed on Jan 22, introducing new classes (WP_PDO_Proxy_Statement and WP_PDO_MySQL_On_SQLite). The Adminer and phpMyAdmin extensions weren't updated to load these new files, causing both database tools to fail with:

Fatal error: Uncaught Error: Class "WP_PDO_Proxy_Statement" not found

This broke the e2e tests for "Database panel > should load and open Adminer" and "Database panel > should load and open phpMyAdmin".

Implementation details

Added the missing require_once statements for the two new SQLite driver classes to both:

• adminer-mysql-on-sqlite-driver.php
• DbiMysqli.php

Testing Instructions (or ideally a Blueprint)

1. Run npx nx e2e playground-website and verify the Database panel tests pass
2. Or manually: Open Playground → Database panel → Click "Open Adminer" or "Open phpMyAdmin" → Should load without errors

[bgrgicak]

@akirk does it work for you locally? I'm getting CORS errors when I try to start Adminer or PHPMyAdmin.

[akirk]

To fix the CORS errors you'll need #3172. You can do git cherry-pick 043a0233a62fc49b4490e33ad36d7a01b19509b8 locally.

[akirk]

Oh wait: Your network appears to be blocking this request (HTTP 200). That is another problem with the CORS proxy where it expects a header that it was proxied.

[akirk]

This snippet will help, maybe we should commit it.

diff --git i/packages/php-wasm/web/src/lib/fetch-with-cors-proxy.ts w/packages/php-wasm/web/src/lib/fetch-with-cors-proxy.ts
index ebb933071..13bbcbf61 100644
--- i/packages/php-wasm/web/src/lib/fetch-with-cors-proxy.ts
+++ w/packages/php-wasm/web/src/lib/fetch-with-cors-proxy.ts
@@ -68,7 +68,17 @@ export async function fetchWithCorsProxy(
 		// Check for firewall interference: if we got a response but it's
 		// missing the CORS proxy identification header, the response likely
 		// came from a network firewall rather than the actual CORS proxy.
-		if (!response.headers.has(CORS_PROXY_HEADER)) {
+		// Skip this check for localhost proxies since they're trusted.
+		// A relative URL (starts with /) means it's on the same origin.
+		const isRelativeUrl = corsProxyUrl.startsWith('/');
+		let isLocalhostProxy = isRelativeUrl;
+		if (!isRelativeUrl) {
+			const corsProxyUrlObj = new URL(corsProxyUrl);
+			isLocalhostProxy =
+				corsProxyUrlObj.hostname === 'localhost' ||
+				corsProxyUrlObj.hostname === '127.0.0.1';
+		}
+		if (!isLocalhostProxy && !response.headers.has(CORS_PROXY_HEADER)) {
 			throw new FirewallInterferenceError(
 				requestObject.url,
 				response.status,

[adamziel]

I'll merge since this at a very least fixes the fatal error

[JanJakes]

@akirk Thanks for the fix! I tried to keep this in mind when adding new APIs, but it seems I did so only for WP_PDO_MySQL_On_SQLite and forgot to add WP_PDO_Proxy_Statement as well: https://github.com/WordPress/sqlite-database-integration/blob/fe3db1021744ad9a2e2b67ae879390582da7a9fe/wp-includes/sqlite-ast/class-wp-sqlite-driver.php#L12

I'll fix this on the SQLite side as well.

There is also a recently added "loader" file in the SQLite repo so I'll prepare a PR to use that one instead.

[JanJakes]

The fix: WordPress/sqlite-database-integration#311