Auto-mount host directories referenced in wp-config.php

[chubes4]

Summary

On a real WordPress server with MariaDB, if you define( 'MY_PATH', '/some/dir' ) in wp-config.php, PHP can just access that path. Studio's WASM sandbox only mounts the site folder at /wordpress, so any external path silently fails — file_exists() returns false, chmod() errors, scandir() breaks.

This PR makes Studio behave like a real server by auto-detecting host directories from wp-config.php and mounting them transparently.

How it works

1. Parses wp-config.php for define() calls with absolute path string values
2. Filters to paths that exist on disk and are outside the site folder
3. Skips sensitive system paths (/etc, /var, /proc, /sys, /dev)
4. Deduplicates
5. Mounts each path at its real host location inside WASM (e.g. /Users/me/Developer → /Users/me/Developer)

Zero configuration required. Developers write normal WordPress code and it works.

Use case

Plugins and developer tools that operate on files outside the WordPress site folder — git workspaces, shared asset directories, build output paths, data directories, AI agent memory stores. Example:

// wp-config.php
define( 'MY_WORKSPACE_PATH', '/Users/me/Developer' );

Before this PR: PHP gets file_exists() = false for that path.
After this PR: PHP can read/write/list that directory normally.

Changes

• New: tools/common/lib/wp-config-mounts.ts — getWpConfigMountPaths() utility
• New: tools/common/lib/tests/wp-config-mounts.test.ts — 11 tests covering edge cases
• Modified: apps/cli/wordpress-server-child.ts — auto-mounts in getBaseRunCLIArgs() (running server path)
• Modified: apps/cli/lib/run-wp-cli-command.ts — auto-mounts in runWpCliCommand() (standalone WP-CLI path)

Testing

Manually verified with a real site that has DATAMACHINE_WORKSPACE_PATH defined in wp-config.php:

Test	Production CLI	This PR
file_exists('/Users/me/Developer')	false	true ✅
scandir('/Users/me/Developer')	fails	lists 9 entries ✅
Running server path	false	true ✅
Standalone WP-CLI path	false	true ✅

Fixes #3082

[wpmobilebot]

📊 Performance Test Results

Comparing 6e6aa90 vs trunk

app-size

Metric	trunk	6e6aa90	Diff	Change
App Size (Mac)	1337.93 MB	1337.94 MB	+0.01 MB	⚪ 0.0%

site-editor

Metric	trunk	6e6aa90	Diff	Change
load	1789 ms	1746 ms	43 ms	⚪ 0.0%

site-startup

Metric	trunk	6e6aa90	Diff	Change
siteCreation	9754 ms	9034 ms	720 ms	🟢 -7.4%
siteStartup	4381 ms	4391 ms	+10 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

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

[chubes4]

Closing this as superseded by the native PHP runtime rollout.

I retested the original DMC workspace access failure with the Studio CLI using native PHP enabled and confirmed it succeeds without this PR:

STUDIO_RUNTIME=native-php node apps/cli/dist/cli/main.mjs wp --path /Users/chubes/Studio/intelligence-chubes4 datamachine-code workspace list --format=json

The same no-PR command under the default Playground/WASM runtime still fails because /Users/chubes/Developer is not visible from PHP:

Workspace path is not accessible from PHP: /Users/chubes/Developer (is_dir=false, is_readable=false, scandir=failed).

Given the native PHP launch plan says native PHP is expected to become the default runtime in Studio v1.11.0, this PR is no longer needed for the workflow it was carrying locally. Playground fallback parity would be the only remaining reason to keep it open.