Fix stale phpMyAdmin assets after Studio updates

[epeicher]

Related issues

• Fixes STU-1577

How AI was used in this PR

Used Claude to locate the root cause (the bundled phpMyAdmin refresh keyed off composer.json version), propose the fix (switch to size/mtime comparison, matching sibling asset helpers), and run the test/typecheck/lint loop. I reviewed the diff and verified the fix end-to-end in a running Studio instance before opening the PR.

Proposed Changes

• Replace the composer.json version comparison in copyBundledPhpMyAdmin with a size/mtime directory diff.
• The upstream phpMyAdmin composer.json "version" (5.2.3) rarely changes, but Studio injects Playground-specific files (e.g. DbiMysqli.php) at build time that do change across Studio releases. The version check was skipping the re-copy, leaving users with stale assets that still hard-coded wp-content/mu-plugins/sqlite-database-integration/wp-pdo-mysql-on-sqlite.php — a path that no longer exists in the current sqlite-database-integration layout.
• The new approach matches the pattern already used by copyBundledLanguagePacks and copyBundledAiInstructions.

Testing Instructions

Prerequisite: Export a Studio site to a .zip file and import it to a new site.

Before the fix, opening phpMyAdmin for that site shows:

Internal error in ./libraries/classes/Dbal/DbiMysqli.php#26
ErrorException: require_once(/wordpress/wp-content/mu-plugins/sqlite-database-integration/wp-pdo-mysql-on-sqlite.php): Failed to open stream: No such file or directory

With the fix:

1. Build the CLI: npm run cli:build
2. Start Studio: npm start
3. Open phpMyAdmin on the affected site (hard-refresh the tab if the error page was cached).
4. phpMyAdmin loads normally — no error.

To simulate the stale state for testing without needing a fresh install, overwrite ~/.studio/server-files/phpmyadmin/libraries/classes/Dbal/DbiMysqli.php with an older copy that still require_onces the legacy path, for example add the following line to line 26:

require_once('/wordpress/wp-content/mu-plugins/sqlite-database-integration/wp-pdo-mysql-on-sqlite.php');

then, run npm start in trunk and check you can reproduce the error. Then run npm start on this branch and check the error disappears when opening phpMyAdmin (remember to force refresh! cmd+shift+R)

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing efede44 vs trunk

app-size

Metric	trunk	efede44	Diff	Change
App Size (Mac)	1490.96 MB	1490.96 MB	0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	efede44	Diff	Change
load	1877 ms	1881 ms	+4 ms	⚪ 0.0%

site-startup

Metric	trunk	efede44	Diff	Change
siteCreation	8145 ms	10110 ms	+1965 ms	🔴 24.1%
siteStartup	4956 ms	5938 ms	+982 ms	🔴 19.8%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[wojtekn]

@epeicher, so Studio updated PhpMyAdmin to a new version, but didn't apply its patches because the modification check was too aggressive?

[katinthehatsite]

Prerequisite: Export a Studio site to a .zip file and import it to a new site.
Before the fix, opening phpMyAdmin for that site shows:
Internal error in ./libraries/classes/Dbal/DbiMysqli.php#26
ErrorException: require_once(/wordpress/wp-content/mu-plugins/sqlite-database-integration/wp-pdo-mysql-on-sqlite.php): Failed to open stream: No such file or directory

I followed these steps but for some reason, I was not able to see the error at all. Everything worked for me as expected even before the fix. Are there any specific requirements for the Studio site itself e.g. specific PHP or WordPress versions?

[wojtekn]

I followed these steps but for some reason, I was not able to see the error at all. Everything worked for me as expected even before the fix. Are there any specific requirements for the Studio site itself e.g. specific PHP or WordPress versions?

I think the steps with ZIP export are not enough - you might need to start the site before testing the fix to ensure phpMyAdmin gets updated, but patches are not getting applied.

[epeicher]

@katinthehatsite, @wojtekn, I have updated the test instructions, I was able to reproduce it initially, but probably because I had an old version of the phpmyadmin server-files.

The original issue seems to be what Wojtek describes, some files are injected by Playground, and they were ignored in the previous version of the code because the modification check was too aggressive.