Add multisite rewrite rules

[bgrgicak]

What is this PR doing?

This PR adds support for multisite URL rewrites.

What problem is it solving?

It ensures that all types of WordPress URLs work on Playground.

How is the problem addressed?

By adding support for rewrite rules in PHP WASM and adding a rule to resolve WordPress multisite URLs.

Testing Instructions

• Checkout this branch
• Start a new multisite (ensure playground.test proxy is running)
• Confirm that the subsite loaded
• Open WP-admin of that site and confirm that all assets loaded correctly

[adamziel]

Why does WordPress ship these .htaccess rules, though, if routing can be as easy as resolving the index.php file?

[bgrgicak]

Why does WordPress ship these .htaccess rules, though, if routing can be as easy as resolving the index.php file?

It's required to handle pretty permalinks. Otherwise, WordPress could work without it.
If a URL is site.com/something, Apache would attempt to load index.html in the something folder, this is where .htaccess ensures all requests end up on index.php in the root folder and get properly routed.

Not sure if this is the explanation you were searching for or is there something more complex?

[adamziel]

Why does WordPress ship these .htaccess rules, though, if routing can be as easy as resolving the index.php file?

It's required to handle pretty permalinks. Otherwise, WordPress could work without it. If a URL is site.com/something, Apache would attempt to load index.html in the something folder, this is where .htaccess ensures all requests end up on index.php in the root folder and get properly routed.

Not sure if this is the explanation you were searching for or is there something more complex?

Aha, thank you! Thinking about this more, I'm not sure. Say we're requesting either these URLs:

• /site-1/wp-content/plugins/testplugin/handler.php
• /site-1/wp-content/themes/twentytwentyfour/style.css

Without the rewrite rules, the .php request would be rewritten to the main index.php file while the style.css request would yield error 404. I think the only way to resolve these requests correctly is to implement these rewrite rules in the request handler:

RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]

[bgrgicak]

Looking at the code, this is where it fails to fetch static files.

The static file path is /wordpress/.... I'm not sure why the file doesn't exist when it's there.

[bgrgicak]

Multisite test url https://playground.test/website-server/#{%20%22landingPage%22:%20%22/test/%22,%20%22phpExtensionBundles%22:%20[%22kitchen-sink%22],%20%22features%22:%20{%20%22networking%22:%20true%20},%20%22steps%22:%20[%20{%20%22step%22:%20%22enableMultisite%22%20},%20{%20%22step%22:%20%22login%22%20},%20{%20%22step%22:%20%22runPHP%22,%20%22code%22:%20%22%3C?php%20require_once%20'wordpress/wp-load.php';%20global%20$playground_scope;%20wp_insert_site(array('path'=%3E%20'/scope:'.$playground_scope.'/test/',%20'domain'=%3E%20parse_url(%20get_site_url(),%20PHP_URL_HOST%20),%20'user_id'=%3E1));%20?%3E%22%20}%20]%20}

[bgrgicak]

I spent some time today working on this and have created a regex const multisiteRegex = /^\/(scope:([.0-9])+\/)?([_0-9a-zA-Z-]+\/)?(wp-(content|admin|includes).*)/g; that we can use to detect multisite URLs.

Now I'm trying to understand whats the best place to do there rewrites.

We want rewrites to happen in Playground, not PHP-wasm to avoid adding WP specific code to PHP-wasm.

I tested adding a regex rewrite to the request handler and it worked, but static files that aren't part of the filesystem would still break.

const multisiteRegex =
			/^\/(scope:([.0-9])+\/)?([_0-9a-zA-Z-]+\/)?(wp-(content|admin|includes).*)/g;
		if (multisiteRegex.test(requestedPath)) {
			const replaceRegex = /\/(wp-(content|admin|includes).*)/g;
			requestedPath = requestedPath.replace(
				requestedPath.replace(replaceRegex, ''),
				''
			);
		}

[bgrgicak]

@adamziel I'm close. The code is all in place and rewrites work, but I can't get it to work consistently.
On the first load static assets are loaded correctly, and on reload (press enter on the path input in the header) remote assets break while the page content loads correctly.

I'm probably not adding rewrite rules in all places or they are not added to WebPHP in all cases.

[adamziel]

Let's look into that on our call later today

[bgrgicak]

Here is the error I wasn't able to recreate yesterday.

URL

Screen.Recording.2024-03-13.at.12.14.05.mov

[adamziel]

404 on static assets looks like the browser tries to fetch() from https://playground.test/scope:0.7227214969914926/test/wp-content/themes/twentytwentyfour/assets/fonts/cardo/cardo italic 400.woff2, but vite dev server cannot find anything under that URL. If you add a bunch of console.log() statements in the service worker to see what the input URL is and how is it handled (routed to worker thread vs handled as fetch()), what would it say about those requests?

[bgrgicak]

I'm getting closer. There are now tests to confirm rewrites work.

There are still some issues with fetching remote assets that I need to resolve.

[bgrgicak]

@adamziel this PR is now ready for review. The failing unit test is the same as in #1095.

[bgrgicak]

Issue for the failing unit test #1112

[adamziel]

I merged the other PR and rebased this one, let's see if the tests pass.

[adamziel]

This looks great, thank you @bgrgicak! My last two asks would be:

• The 0-playground.php comment I left
• Updating the PR title and description to communicate what this PR does now

Thank you for your amazing work! 🎉

[adamziel]

Should this only match a single path segment? Or not? @bgrgicak

Suggested change

	match: /^\/(.*?)(\/wp-(content|admin|includes).*)/g,
	match: /^\/([^/]+?)(\/wp-(content|admin|includes).*)/g,

[bgrgicak]

No, this should work with single and multiple paths. For example /scope:0.1/subsite/ and /subsite/.

[adamziel]

👍 what about greedy vs non-greedy? E.g. how would this be handled /scope:03938/subsite/wp-content/plugins/myplugin/wp-content/image.jpg?

[bgrgicak]

E.g. how would this be handled /scope:03938/subsite/wp-content/plugins/myplugin/wp-content/image.jpg?

It would still work as expected and resolve as /wp-content/plugins/myplugin/wp-content/image.jpg.

[adamziel]

Awesome, thank you for your patience! :-)

[bgrgicak]

This has been a great learning experience for me. I finally feel comfortable with Regex.