Fix Studio site crashing when rotatePHPRuntime was executed

[sejas]

Related issues

• Fixes https://github.com/Automattic/dotcom-forge/issues/10569

Proposed Changes

• Remove default Hello wp-now "virtual" index.php
• Avoids remounting directories, which prevents PHP runtime crashes during rotation.

Why?
It seems in the past the rotatePHPRuntime was starting a fresh Playground that needed mounting the directories, and that's not the case anymore.

Testing Instructions

• Apply this diff to reduce the number of requests that produces a PHP runtime rotation.

diff --git a/vendor/wp-now/src/wp-now.ts b/vendor/wp-now/src/wp-now.ts
index b3e61cd1..0c0b3235 100644
--- a/vendor/wp-now/src/wp-now.ts
+++ b/vendor/wp-now/src/wp-now.ts
@@ -135,7 +135,7 @@ export default async function startWPNow(
 			await prepareWordPress( php, options );
 			return runtimeId;
 		},
-		maxRequests: 400,
+		maxRequests: 10,
 	} );
 
 	return {

• Run npm start
• Start a site
• Access wp-admin, index, and other pages/posts multiple times
• Observe the message Recreating and rotating PHP runtime every ~10 PHP requests.

I've also observed that the message Stopped watching for file changes but I confirm that the file changes are still working. I edited the main index.php and I saw the changes applied correctly in the browser.

Pre-merge Checklist

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

[ivan-ottinger]

After applying the proposed change, I cannot reproduce the issue anymore. 👌🏼 Nice! The correct index.php is preserved. Great investigation!

One thing to consider is that the sites that already have their index.php replaced with the default one won't get fixed automatically.

If this is not a widespread issue, we could let the affected users know how to get their index.php file back, or we could consider addressing that in the PR as well.

[sejas]

One thing to consider is that the sites that already have their index.php replaced with the default one won't get fixed automatically.

If this is not a widespread issue, we could let the affected users know how to get their index.php file back, or we could consider addressing that in the PR as well.

Good point. I think the safest approach is letting the user know and suggesting them to update the index.php file manually.