NGINX configuration equivalent to .htaccess

[eliot-akira]

Would be nice to document the config syntax for using NGINX.

Here's dist-web/.htaccess for Apache.

AddType application/wasm .wasm

RewriteEngine on
RewriteRule ^scope:.*?/(.*)$ $1 [NC]
RewriteRule ^plugin-proxy$ plugin-proxy.php [NC]

<FilesMatch "iframe-worker.html$">
  Header set Origin-Agent-Cluster: ?1
</FilesMatch>

Rough draft for NGINX config (untested).

types {
  application/wasm wasm;
}

location /scope:.*?/(.*) {
 rewrite ^scope:.*?/(.*)$ $1 last;
}

location /plugin-proxy {
 rewrite ^plugin-proxy$ plugin-proxy.php last;
}

location /iframe-worker.html {
  add_header Origin-Agent-Cluster ?1;
}

---

Reference

• NGINX documentation
• Scoped URL routing
  • Scoped WordPress instances to support multiple browser tabs  #31
  • Commit 5f03281 - Rewrite /scope:.+/<URL> to just <URL>
• Plugin proxy
  • Commit 228ccc3 - Make wordpress.html configurable via query params

[adamziel]

Love it, thank you for preparing it! I'm currently restructuring the repo to separate WordPress from PHP – let's get it in once that's done.

[eliot-akira]

I was able to deploy WordPress Playground on an NGINX server.

Here are the server directives confirmed to be working.

index wordpress.html;

location ~* .wasm$ {
  types {
    application/wasm wasm;
  }
}

location /scope:.*?/(.*) {
  rewrite ^scope:.*?/(.*)$ $1 last;
}

location /plugin-proxy {
  try_files plugin-proxy.php /plugin-proxy.php$is_args$args;
  include fastcgi_params;
  fastcgi_pass php;
}

location /iframe-worker.html {
  add_header Origin-Agent-Cluster ?1;
}

This config is copied also for the second subdomain serving the iframe contents. (Both domains point to the same directory where static files are deployed.)

---

Just to note down while my experience is fresh, some of the difficulties were:

• Two domains required, both with SSL certificates

• PHP required for plugin-proxy

  In any case, it seems a server-side language/component is necessary for the playground to have network access and maybe for persistence. Possibly in the future, there can be a WebSocket to TCP proxy like websockify (in Python) or equivalent in Node.js/Go/etc.

• How to set environment variables SERVICE_WORKER_ORIGIN (first domain) and WASM_WORKER_ORIGIN (second domain) for the build step

  I think this is not documented anywhere - I tried:

  WASM_WORKER_ORIGIN=https://second.domain npm run build
  env WASM_WORKER_ORIGIN=https://second.domain npm run build
  export WASM_WORKER_ORIGIN=https://second.domain && npm run build

  But none seemed to work, so in the end I just hard-coded the domains in esbuild.js. I'll try again later - all the above attempts look reasonable, so it could be that the variable is not being passed to the Gulp script.

  Edit: Solved with first method, just prepending env variables before NPM command. The reason why I thought it wasn't working was due to the cache issue below.

• How to clear stale cache

  This may be due to the specific domains I'm using, which have Cloudflare in front of them.

  Solved by editing src/php-wasm-browser/iframe-worker.html to add cache-busting query string:

  <script src="/worker-thread.js?2023011001" type="module"></script>

  ..and src/wordpress-playground/wordpress.html

  <script src="app.js?2023011001" type="module"></script>

  Perhaps it makes sense for the build script to do this to the HTML files, to make the URLs unique for every build, similar to the CACHE_BUSTER constant for the iframe/service worker URLs.

[eliot-akira]

On this last point, I found there was already logic to apply a cache-busting URL for HTML files, but the regular expression was missing type="module".

wordpress-playground/esbuild.js

Line 255 in 233c66d

/(<script[^>]+src=")([^"]+)("><\/script>)/,

..should be something like:

/(<script[^>]+src=")([^"]+)(" type="module"><\/script>)/

Edit: Addressed in pull request #108

[adamziel]

After #712, the only two remaining .htaccess rules are:

AddType application/wasm .wasm
AddType	application/octet-stream .data

I'd say that's as close as we can get here. I'm not aware of any .htaccess-like concept in NGINX, which means that any file we'd provide in the repo would serve as a documentation only. The NGINX configuration rules are already documented in a more visible place than an obscure path in the repo: https://wordpress.github.io/wordpress-playground/architecture/host-your-own-playground. I'll go ahead and close this issue.

What do you think @eliot-akira? I'm happy to reopen if needed.