search

WordPress / wordpress-playground

Run WordPress in the browser via WebAssembly PHP
https://w.org/playground/
GNU General Public License v2.0
1.55k stars 210 forks source link

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

Open brandonpayton opened 3 weeks ago

brandonpayton commented 3 weeks ago

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: https://github.com/WordPress/wordpress-playground/blob/7d62755ef0c092c76c0a27dce93ae5e3474bc7b8/packages/php-wasm/universal/src/lib/php-request-handler.ts#L595-L597

And IIUC Playground will try to run such non-PHP files as PHP: https://github.com/WordPress/wordpress-playground/blob/7d62755ef0c092c76c0a27dce93ae5e3474bc7b8/packages/php-wasm/universal/src/lib/php-request-handler.ts#L315-L321

Discovered when investigating #1332.

adamziel commented 3 weeks ago

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 commented 3 weeks ago

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

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 commented 3 weeks ago

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 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 commented 3 weeks ago

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:

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 commented 3 weeks ago

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 commented 3 weeks ago

Having a list of metadata would also help me in the case of this draft PR https://github.com/WordPress/wordpress-playground/pull/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 commented 2 weeks ago

Having a list of metadata would also help me in the case of this draft PR https://github.com/WordPress/wordpress-playground/pull/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.

bgrgicak commented 2 weeks ago

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

brandonpayton commented 2 weeks ago

Thanks! Ping me for a review when it's ready and then I can use it in https://github.com/WordPress/wordpress-playground/pull/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: https://github.com/WordPress/wordpress-playground/blob/d72387ca7b15f330a6ad6fec2297a83ff238a4af/packages/playground/wordpress-builds/build/Dockerfile#L48-L58

brandonpayton commented 2 weeks ago

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.