In order for WordPress to default to pretty permalinks during install, it has to make a successful request to the site while pretty permalinks are enabled. I suspect:

• the pretty permalink test requests are failing
• Playground may not be ready to handle subrequests when it is running the WordPress install in bootWordPress().

I've been looking at this a bit this evening. Ultimately, we need to be able to handle PHP subrequests before the WordPress installation process is invoked.

Can we enable pretty permalinks once WordPress is installed, though? Could be as a part of the boot protocol.

Can we enable pretty permalinks once WordPress is installed, though? Could be as a part of the boot protocol.

@adamziel yep, I think that is good in the short term at least.

I figured it would be good for WordPress installation to just work as usual in Playground by allowing subrequests during install, but if that is the only subrequest done during WP install, perhaps it is not worth it. I will look.

Hm Subrequests should still work during the installation, I'm not sure why they don't.

How can subrequests work if the PHP request handler hasn't been exposed outside of bootWordPress() yet?

Ooh that's such a good question @brandonpayton, it challenges some architectural ideas behind bootWordPress(). It sounds like installWordPress() needs access to:

• Networking
• The request handler
• The endpoint where WordPress is available

However, I vaguely remember disabling the networking in installWordPress made for a dramatic installation speedup in web browsers:

async function installWordPress(php: PHP) {
	// Disables networking for the installation wizard
	// to avoid loopback requests and also speed it up.
	await withPHPIniValues(
		php,
		{
			disable_functions: 'fsockopen',
			allow_url_fopen: '0',
		},

It would be nice and clean from the developer POV to support the same flow as we'd have with Apache/Nginx, so actually do the loopback during the installation. At the same time, it would be a worse user experience. Yeah, I'd say let's not support the actual loopback request for now in the name of faster boot/installation process.

Two workarounds I can think of are:

• Enable networking and mock the responses. My hunch is we won't be able to do that without PHP: Support http:// https:// and ssl:// stream wrappers #1093 as we seem to be dealing with fopen() and fsockopen() here, not our Fetch network transport. I might be wrong, though, and mocking the responses would open the door to having networking enabled by default.
• Run this PHP code at the end of installWordPress().

Now, some developers might really need to go through the same code paths – I'd open a new issue to gather feedback, and only act on it once we validate there's an actual demand.

@adamziel thanks for all your thoughts and background. I agree it probably makes sense to avoid slowing down Playground WP boot with a longer install process. And maybe we can revisit sometime in the future.

For now, I was thinking it might be as simple as updating the permalink_structure option at the end of installWordPress() like:
update_option( 'permalink_structure', '/%postname%/' );

Is there a reason we need to interact with the WP_Rewrite? It seems like WP should derive the correct rewrite rules from the permalink_structure at request time.

Either way, I'll grab this issue. It would be lovely to have permalink-dependent features working well out of the box.

Is there a reason we need to interact with the WP_Rewrite? It seems like WP should derive the correct rewrite rules from the permalink_structure at request time.

AFAIR WordPress caches the rewrite rules in the rewrite_rules and won't pick up the new ones without calling $wp_rewrite->flush_rules();