Run every site as a local environment, so Application Passwords can be tested

[zaerl]

Why

Every site the app sets up runs as a production environment, because nothing defines WP_ENVIRONMENT_TYPE and Core falls back to it. Core offers Application Passwords only over HTTPS or on a local site, and the dev server is plain http://127.0.0.1, so a contributor at WordCamp Rajasthan's Contributor Day could not test an Application Passwords ticket. They could not fix it either: Playground writes wp-config.php itself, and there is no file to edit.

What changes

Root cause: the only constants a site gets are the ones the app puts in the blueprint, and none of them said what kind of environment the site is.

• Every site now gets WP_ENVIRONMENT_TYPE = local, as Core's own Docker environment does by default.
• Every site gets a WP_DEVELOPMENT_MODE that follows from what it is: core for a Core checkout, plugin for Gutenberg, which is a plugin mounted into a stock WordPress.
• Both live in planServeConstants, beside the Gutenberg file locks, not in WP_DEBUG_CONSTANTS: they are strings, and that set is booleans only, by design and by test.
• Deliberately not in this PR: a setting for either. The mode is answered by the site type, and the environment type's other values only turn features off. A ticket that needs production behaviour can use Core's filters from an mu-plugin.

How to test this

Platforms: any. Nothing here touches paths, spawning or line endings.

Starting state: a Core site that has finished setup, with its dev server stopped, and a Gutenberg site if you have one.

1. Open the Core site and click Start development server, then log in to wp-admin.
2. Go to Users > Profile. An Application Passwords section appears near the bottom. On trunk there is none.
3. Enter a name and click Add Application Password. A new password is shown.
4. On a Gutenberg site, start the server and open Plugins. Gutenberg is active, and there is still no Delete link for it.

What must not have happened:

• Turning Report notices and deprecations (WP_DEBUG) off in Settings must still turn notices off after a server restart. local would default WP_DEBUG to on, but the app always defines it, so the setting still wins.
• The Gutenberg site's file locks must still be in place, so Plugins > Delete cannot reach the checkout.

The tests that cover this are the two new cases in tests/unit/playground-plan.test.cjs and the new assertions in tests/unit/runner-wiring.test.cjs. All four fail on trunk's code and pass here; I checked by restoring the old file and running them.

Risks and limitations

• A non-production type changes more than Application Passwords. Pingbacks and trackbacks are off, in and out, and Site Health skips its page cache, object cache and HTTPS tests and rates errors shown to visitors as recommended. Core's Docker environment behaves the same way, and the docs table says so, but a ticket about one of these now needs a filter to reproduce.
• plugin mode has no effect today. Neither Core nor Gutenberg reads it. It is set because it describes the site, and core would describe a checkout the Gutenberg site does not have.
• Review: 2 should-fix findings and 4 nits from a fresh-context review, all fixed except one stale comment left as a follow-up. Details below.

Related

Fixes #598

---

Design decisions and alternatives considered

• The issue proposed adding both to WP_DEBUG_CONSTANTS. I did not, because every value there is a boolean, and a test asserts it, to keep the string "false" out of a PHP constant. The serve plan is already where strategy-specific constants go, and the development mode depends on the strategy.
• The issue asked for a check for Gutenberg sites. That check became a value: plugin instead of core, since Core accepts core, plugin, theme and all.
• No setting. The two debug toggles in Settings exist because a ticket can be about a site's behaviour with them off. Neither of these meets that bar, and a four-value dropdown whose other options only remove features is easy for a newcomer to set wrong.

Review outcome (required — see AGENTS.md)

2 [fix here] should-fix · 4 [fix here] nits · 1 [follow-up] — all 6 [fix here] fixed.

• Fixed: the code comment and docs misdescribed what core mode does. It only skips the cached list of Core block stylesheets, not block.json or theme.json caches.

• Fixed: the comment said local changes little else. It now names pings and Site Health, and the docs row does too.

• Fixed, nits: the runner's comment on the last spread, the header line of planServeConstants, the docs sentence that introduces the table as debug constants, and a third test that only repeated the two exact-value tests.

• Deferred: the comment in src/settings.cjs saying every other constant comes from wp-debug-constants.js. It was already untrue on trunk, because of the SMTP constants and the Gutenberg locks, so it is not this change's to fix.

• Review: completed — separate agent context (Explore subagent) given the diff and the review standard; reviewed the uncommitted working tree on base 6d5f334; npm test 2083 pass, 0 fail; eslint and stylelint clean on this checkout. Outcome as above.

• Since review: the fixes listed above, committed as 1007778 with no other changes; affected suites and the full suite re-run, green.

Implementation notes

• Checked in a real Playground boot, on the app's own Electron as Node, with exactly the constants a site gets:

Run	Environment	Mode	Application Passwords
Without this change, Core	production	none	unavailable
With it, Core	local	core	available
With it, Gutenberg	local	plugin	available

• Core's Docker environment sets the same pair: LOCAL_WP_ENVIRONMENT_TYPE=local and LOCAL_WP_DEVELOPMENT_MODE=core in wordpress-develop's .env.example, written into wp-config.php by tools/local-env/scripts/install.js.
• Nothing in @wp-playground or @php-wasm defines either constant, so there is no clash with Playground's own wp-config.php.

Screenshots or recording

The app's own windows do not change. The visible difference is the Application Passwords section on WordPress's profile screen, which step 2 above shows.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Repository: WordPress/contributor-toolkit/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: d6ddf1fb-a5e5-43e5-b735-0ea1fca308b2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}