Static files run as PHP when path includes directory like `<some-dir>.php/`

[brandonpayton]

If a static file is under a directory tree where an ancestor directory has a name ending in ".php" (e.g., /root/some.php/assets/photo.jpeg), Playground will say that the file seems like a PHP file:

wordpress-playground/packages/php-wasm/universal/src/lib/php-request-handler.ts

Lines 595 to 597 in 7d62755

	function seemsLikeAPHPFile(path: string) {
	return path.endsWith('.php') || path.includes('.php/');
	}

And IIUC Playground will try to run such non-PHP files as PHP:

wordpress-playground/packages/php-wasm/universal/src/lib/php-request-handler.ts

Lines 315 to 321 in 7d62755

	if (!seemsLikeAPHPRequestHandlerPath(fsPath)) {
	return this.#serveStaticFile(
	await this.processManager.getPrimaryPhp(),
	fsPath
	);
	}
	return this.#spawnPHPAndDispatchRequest(request, requestedUrl);

Discovered when investigating #1332.

[adamziel]

I wonder what's the path resolution algorithm Apache of Nginx uses and can we do the same here. One complication in the web version of Playground is that some static files aren't shipped in the VFS but are fetch()-ed on demand from https://playground.wordpress.net/.

[brandonpayton]

@adamziel I am currently trying to work through this. Initially, I was going to create a PR to quickly communicate my thoughts but kept finding edge cases.

What is difficult is:

• We need to support requests for non-existent permalink paths
• Permalink paths may not end with an explicit / which indicates a directory
• Some static files do not exist on disk (as you mentioned)

I think it is probably OK in most cases to treat files without an extension (i.e., without a "." in them) as directories. That is probably a reasonable first pass. In addition, maybe we can only do this for WP source directories. That way, plugins that include requests for extension-less files do not break when we incorrectly guess their static file path points to a directory.

If we find we need to handle these decisions with more certainty within requests for WP core assets, perhaps the stripped-down WordPress builds could include an explicit listing of the static files that exist remotely.

[brandonpayton]

I think it is probably OK in most cases to treat files without an extension (i.e., without a "." in them) as directories. That is probably a reasonable first pass. In addition, maybe we can only do this for WP source directories. That way, plugins that include requests for extension-less files do not break when we incorrectly guess their static file path points to a directory.

I was mistaken. We can't easily treat Playground-provided asset paths in a special way because some of Playground's remote assets are under wp-content/(mu-plugins|plugins|themes) directories along with third-party code.

As a first pass, we can handle a path with PHP when any of the following are true:

• the path ends with .php
• the path is an existing directory
• the path ends with /
• the path does not exist in the FS and contains no . character in the base filename

The line

the path does not exist in the FS and contains no . character in the base filename

will probably work for most cases, but it will break if custom permalink structures contain . characters in the path. Third party code may also rely on such permalink delegation to implement other things like custom endpoints.

A couple options to solve this are:

1. Make a request for a remote asset. If there is a 404 response, delegate the request to WordPress.
2. Include a list of remote static asset paths with the stripped-down WP builds, so we can know exactly what paths are remote and which should be delegated to WordPress.

[brandonpayton]

I wonder what's the path resolution algorithm Apache of Nginx uses and can we do the same here.

@adamziel I got ahead of myself and forgot to answer directly. The nginx behavior is completely defined in the config, and we can use the WordPress.org nginx example for reference:

• Filenames ending in .php are run by PHP
• Certain static file types are served directly without forwarding non-existent file paths to WP
• Other paths are tried first as a file, then as a directory where index.php may be present, then delegated to WP's index.php

One complication in the web version of Playground is that some static files aren't shipped in the VFS but are fetch()-ed on demand from https://playground.wordpress.net/.

This is what makes the last rule

Other paths are tried first as a file, then as a directory where index.php may be present, then delegated to WP's index.php

hard to implement.

The first thing to try is whether a file exists at that path, but we cannot know that without additional info. So we either need to take a different approach as mentioned above or add metadata to the stripped WP builds so we know what files exist remotely.

After spelling out the above nginx config, I think we should just generate the metadata, use it, and be done with all the special cases. What do you think?

[adamziel]

Metadata sound great and could also help with building a PWA (unless we'll just use a non-minified build for that as it's easy to do and already enables fetch-less usage). Cc @bgrgicak

[bgrgicak]

Having a list of metadata would also help me in the case of this draft PR #1203. I wanted to add the list to it, but didn't have the time.

Similarly for offline support. We will need to download all files when the PWA is installed and this list is a requirement.

[brandonpayton]

Having a list of metadata would also help me in the case of this draft PR #1203. I wanted to add the list to it, but didn't have the time.

@bgrgicak, cool. 👍

OK, I am planning to work on this next.