Skip to content

Set Playground runtime on reprint-pulled sites to fix startup DB error#3922

Closed
epeicher wants to merge 3 commits into
trunkfrom
fix-reprint-pull-runtime
Closed

Set Playground runtime on reprint-pulled sites to fix startup DB error#3922
epeicher wants to merge 3 commits into
trunkfrom
fix-reprint-pull-runtime

Conversation

@epeicher

@epeicher epeicher commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

Related issues

How AI was used in this PR

Claude Code diagnosed the failure from the Studio + daemon logs, reproduced the root cause with the bundled PHP binary, implemented the fix and a regression test, and verified it end-to-end with a real pull-reprint. I reviewed the diagnosis and change.

Proposed Changes

Sites imported with studio pull-reprint failed to start, dying with "Error establishing a database connection."

The bug: a reprint-pulled site's files are laid out for the Playground runtime — VFS mounts place wp-content (and its SQLite db.php drop-in) under /wordpress/wp-content. But the site was registered without a runtime, so it defaulted to native-php. On that runtime PHP resolves the symlinked layout to the real WordPress core path, WP_CONTENT_DIR no longer points at the SQLite drop-in, WordPress falls back to MySQL, and the connection fails.

The fix: register reprint-pulled sites with the Playground runtime (the runtime they're already built for and the one the command uses for the auto-login URL), so they start correctly.

Testing Instructions

  1. npm run cli:build
  2. node apps/cli/dist/cli/main.mjs pull-reprint --url <your-site>.wpcomstaging.com -y
  3. The site starts and serves HTTP 200.
  4. Stop it by running studio stop --path ... and start it by running studio start --path ...
  5. Verify it starts. On trunk the site does not start successfully

Pre-merge Checklist

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

@wojtekn

wojtekn commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

Is it the correct approach? What if we remove support for Playground?

@wpmobilebot

Copy link
Copy Markdown
Collaborator

📊 Performance Test Results

Comparing 5e96fad vs trunk

app-size

Metric trunk 5e96fad Diff Change
App Size (Mac) 2341.83 MB 2341.83 MB +0.00 MB ⚪ 0.0%

site-editor

Metric trunk 5e96fad Diff Change
load 1035 ms 1080 ms +45 ms ⚪ 0.0%

site-startup

Metric trunk 5e96fad Diff Change
siteCreation 6504 ms 6492 ms 12 ms ⚪ 0.0%
siteStartup 6991 ms 7497 ms +506 ms 🔴 7.2%

Results are median values from multiple test runs.

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

@epeicher

Copy link
Copy Markdown
Contributor Author

Is it the correct approach? What if we remove support for Playground?

Good catch! I came here to comment that this approach will be superseded by #3881 - comment here so I am closing this PR

@epeicher epeicher closed this Jun 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants