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

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.

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/.

@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.

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:

Make a request for a remote asset. If there is a 404 response, delegate the request to WordPress.
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.

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?

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

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.

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.

Thanks! Ping me for a review when it's ready and then I can use it in #1203.

Thanks! Ping me for a review when it's ready and then I can use it in #1203.

Will do! I ended up spending most of today working on things related to the website migration but hope to work on this tomorrow.

It looks like this where we can save a list of remote static files which can be added to the stripped-down WP zip and read later:

wordpress-playground/packages/playground/wordpress-builds/build/Dockerfile

Lines 48 to 58 in d72387c

    
           # Separate WordPress static files 
        
           RUN cp -r wordpress wordpress-static && \ 
        
               cd wordpress-static && \ 
        
               find ./ -name '*.php' -delete && \ 
        
               # Keep only the static files inside the directories like wp-admin or wp-content: 
        
               find . -maxdepth 1 -type f -delete && \ 
        
               # Remove all empty directories 
        
               find . -type d -empty -delete 
        
           # Remove the sqlite database integration from the static files 
        
           RUN rm -rf wordpress-static/wp-content/mu-plugins

I made a draft PR for listing remote static asset paths so we can make better decisions in request handling: #1417

We also need to make a change to this line as a separate PR so we don't try to handle a static file under a some.php/ directory as PHP. Planning to work on that tomorrow.

This was fixed by #1539.

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

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

	# Separate WordPress static files
	RUN cp -r wordpress wordpress-static && \
	cd wordpress-static && \
	find ./ -name '*.php' -delete && \
	# Keep only the static files inside the directories like wp-admin or wp-content:
	find . -maxdepth 1 -type f -delete && \
	# Remove all empty directories
	find . -type d -empty -delete

	# Remove the sqlite database integration from the static files
	RUN rm -rf wordpress-static/wp-content/mu-plugins