Allow enableMultisite blueprint step

[bcotrim]

Related issues

• Fixes STU-831

Proposed Changes

Allow enableMultisite blueprint step

• Remove enableMultisite from the unsupported blueprint features list, allowing blueprints to configure WordPress multisite

Bump @wp-playground packages to 3.0.54

• Includes upstream fix for $_SERVER['HTTP_HOST'] handling in multisite, which fixes site restart failures

Add multisite validation (CLI + Desktop)

CLI: Error early when a blueprint contains enableMultisite but no --domain flag is provided. Multisite doesn't support custom ports, so a custom domain is required.

Desktop app: When a blueprint with enableMultisite is detected:

• Auto-enable the custom domain field and show advanced settings
• Lock the custom domain toggle so users can't disable it
• Show an info notice: "WordPress multisite requires a custom domain."

Shared utility

• Add blueprintHasMultisite() helper in common/lib/blueprint-settings.ts, used by both CLI and desktop

Testing Instructions

CLI

1. Create a blueprint JSON with an enableMultisite step
2. Run npm run cli:build && node dist/cli/main.js site create ~/test-multisite --blueprint /tmp/multisite.json
3. Verify it errors with a message about requiring --domain
4. Run again with --domain test.local — should proceed normally

Desktop

1. Open Studio, go to Add Site
2. Use a blueprint URL containing enableMultisite (e.g., via deeplink)
3. Verify advanced settings auto-open, custom domain is enabled and locked
4. Verify the info notice about multisite requiring a custom domain is shown

Tests

npm test -- common/lib/tests/blueprint-settings.test.ts cli/commands/site/tests/create.test.ts

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing eada47e vs trunk

site-editor

Metric	trunk	eada47e	Diff	Change
load	1761.00 ms	1790.00 ms	+29.00 ms	⚪ 0.0%

site-startup

Metric	trunk	eada47e	Diff	Change
siteCreation	7124.00 ms	7085.00 ms	-39.00 ms	⚪ 0.0%
siteStartup	3924.00 ms	3942.00 ms	+18.00 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[sejas]

I tested this PR and I confirm I was able to create a new site using a blueprint with enableMultisite step. Feature wise it behaves as described in the PR.
I have two concerns that could be raised by users once we make multisites easier to create.

1. AFAIK, Users won't be able to Push these sites to WordPress.com and only some Pressable sites support it. I wonder if we should at least keep a warning for this step.
2. There are some warnings visible in wp-admin:

Warning: file_get_contents(/wordpress/wp-content/plugins/{SQLITE_PLUGIN}): Failed to open stream: No such file or directory in /wordpress/wp-includes/functions.php on line 6910

Warning: file_get_contents(/wordpress/wp-content/plugins/sqlite-database-integration/load.php): Failed to open stream: No such file or directory in /wordpress/wp-includes/functions.php on line 6910

3. The assumption of a custom domain being required is false. I was able to setup a Multisite using localhost:8881 port.

Blueprint I used for testing: enableMultisite-blueprint.json

Step is allowed and the custom domain is forced:

wp-admin warnings:

Multisite using localhost

I noticed that the site created with the blueprint added this first line in the wp-config.php : $_SERVER['HTTP_HOST'] = json_decode(base64_decode('InRlc3QtbXUtc2l0ZS53cC5sb2NhbCI='), true);, so I used a similar setting in my localhost Multisite and worked great. I was able to restart the server without errors in Studio:

/* Multisite */
$_SERVER["HTTP_HOST"] = "localhost:8886";
define("WP_ALLOW_MULTISITE", true);
define("MULTISITE", true);
define("SUBDOMAIN_INSTALL", false);
define("DOMAIN_CURRENT_SITE", "localhost:8886");
define("PATH_CURRENT_SITE", "/");
define("SITE_ID_CURRENT_SITE", 1);
define("BLOG_ID_CURRENT_SITE", 1);

@bcotrim, should we allow users using localhost:port?

[wojtekn]

AFAIK, Users won't be able to Push these sites to WordPress.com and only some Pressable sites support it. I wonder if we should at least keep a warning for this step.

@sejas let's keep the UI clean, the purpose of this PR is to avoid blocking features that can work in Studio and to reduce the number of unnecessary warnings.

[bcotrim]

The assumption of a custom domain being required is false. I was able to setup a Multisite using localhost:8881 port.

Were you able to start a site in Playground CLI without a domain? I didn't introduce that restriction, on my tests, creating a multisite using Playground CLI blueprint would result in an error if a domain wasn't provided.

[katinthehatsite]

Some of the logic here is similar to the logic in use-blueprint-deeplink.ts . This is not specifically related to this PR but we could refactor it in some kind of shared helper. What do you think?

[katinthehatsite]

In terms of functionality, I did not find any issues: I was able to create another site from this site in My sites in wp-admin, and it worked great. Nothing crashed on my end 🤞

The only thing the I saw were the warning which I think it would be nice if they were resolved:

[katinthehatsite]

thanks for fixing the warnings @bcotrim - I no longer see them:

It would be nice if this notice had a background or so to stand out more but I think it is a minor design thing:

[bcotrim]

thanks for the review @katinthehatsite
I changed the notice from "info" to "warning" does this look better?

@sejas do you agree to land this with the domain restriction, or should we try to look more into it, and check with Playground if there's a way we can allow sites without a custom domain?

[sejas]

Sure! Let’s land the PR with the domain restriction. We can always remove it in the future if we find an easier way to handle it.

Currently, this approach hardcodes a constant in wp-config.php, which may cause issues in production, etc. But it’s a small thing, considering that multisites are not supported by many wp.cloud providers. I would suggest creating an issue to disable the publish and connect buttons for multisites.

[bcotrim]

Currently, this approach hardcodes a constant in wp-config.php, which may cause issues in production, etc. But it’s a small thing, considering that multisites are not supported by many wp.cloud providers. I would suggest creating an issue to disable the publish and connect buttons for multisites.

Done STU-1377, thank you!

[wojtekn]

@bcotrim what was the reason to define SQLITE_MAIN_FILE here? CC @JanJakes

[bcotrim]

it was to fix the errors reported by @katinthehatsite here #2470 (review)