Default url rewrites to /index.php

[bgrgicak]

Fixes #1054

What is this PR doing?

If a requested file path can't be resolved (file or folder don't exist) the request file path is rewritten to /index.php.

What problem is it solving?

Ensures a response when requesting WordPress permalink URLs like /category/uncategorized/ using php.request.

How is the problem addressed?

The code assumed that a path which isn't a PHP file is a folder and requested the index.php file in that folder.
In the case of WordPress URLs the path might not be a folder so adding index.php would break a valid request.

To address this, index.php is added to the end of the path only if the path is a valid directory.
If not, the path is rewritten to index.php in the root folder.

Testing Instructions

• Confirm that tests pass

[bgrgicak]

@adamziel I found that the root cause of #1054 is in the way we modify the file path and not a problem with us not supporting WordPress permalinks so I didn't add another request handler.

[akirk]

Thains! My usecase is the export-translations URL on GlotPress and it uses URL parameters, so an example URL might be /glotpress/projects/local-plugins/friends/de/default/export-translations/?format=po&filters[user_login]=admin. Will it also work? What do you think about adding a unit test with GET parameters to be sure?

[bgrgicak]

It will work. This changes the PHP file that is requested, but the headers and globals like $_GET aren't changed.

I updated the tests to confirm that $_GET values are working.

[akirk]

Brilliant, thanks!

[adamziel]

@bgrgicak This solves the problem at hand and the tests pass so let's merge it. Nice!

My follow-up question would be: do we still need this code?

wordpress-playground/packages/playground/remote/service-worker.ts

Lines 51 to 64 in 454fec3

	if (workerResponse.status === 404) {
	for (const url of rewriteWordPressUrl(unscopedUrl, scope!)) {
	rewrittenUrlString = url.toString();
	workerResponse = await convertFetchEventToPHPRequest(
	await cloneFetchEvent(event, rewrittenUrlString)
	);
	if (
	workerResponse.status !== 404 ||
	workerResponse.headers.get('x-file-type') === 'static'
	) {
	break;
	}
	}
	}

If yes, then #1054 is still relevant and we'll still need to support that logic at the request handler level, otherwise the service worker will rewrite multisite URLs correctly, but other PHP.wasm consumers like WP-NOW and VS Code won't.

If not, then #1054 is indeed solved.