Set the right expectation for the "latest" WordPress version setting

[gcsecsey]

Related issues

• Related to STU-2348

How AI was used in this PR

It was used to identify and solve the issue.

Proposed Changes

Settings surfaces were showing WordPress version as latest, while wp-admin asked the user to update WordPress, so the setting read as if it were wrong. latest is a mode, not a version: it means Studio turns WordPress core auto-updates on, and choosing any specific version pins the site and turns them off. WordPress then installs the update on its own schedule, so the admin notice can appear in the meantime.

This PR:

• Renames the option to Auto-update and shows the version when it's known eg. Auto-update (7.1), so the Overview and Settings tabs now show the same version
• Shows the Auto-update label for sites with pinned versions, and on the create-site form.
• Drops the Auto-updating group heading, which the option name now makes redundant.
• Applies one shared label across Classic and the agentic UI so translators see the phrasing once, and explains latest in the CLI --wp help.

This is wording only, no site behavior changes.

Testing Instructions

Agentic UI:

• Open an auto-updating site, go to Settings, and open the WordPress version dropdown. The first entry should read Auto-update (<version>), ungrouped, above Beta & Nightly and Stable Versions.
• Pin the site to a specific version and save, then reopen the dropdown. The first entry should now read Auto-update with no version.
• Open the create-site form. The option should read Auto-update, since there is no site yet.

Classic UI:

• Open a site's settings, and check the same dropdown.
• Pinning a version should still show the info tooltip beside the WordPress version label.

CLI:

• node apps/cli/dist/cli/main.mjs site create --help and node apps/cli/dist/cli/main.mjs config set --help should both explain that latest auto-updates.

To see a version that differs from the newest release, create a site with --wp 6.9, then set its isWpAutoUpdating back to true in ~/.studio/cli.json. That reproduces a site which has drifted behind, which is the case in the report.

State	Before	After
Options list
Agentic UI, New site form
Agentic UI, auto-updating
Agentic UI, pinned
Classic, New site form
Classic, auto-updating
Classic, pinned

Pre-merge Checklist

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

[Copilot]

Pull request overview

Updates the wording and labeling for the “latest” WordPress version setting across Studio’s Classic UI, agentic UI, and CLI so it’s understood as an auto-update mode (optionally annotated with the currently installed version) rather than a promise that the site is already on the newest release.

Changes:

• Introduces a shared getAutoUpdateVersionLabel() helper to consistently label the auto-update option as Auto-update or Auto-update (<installed>).
• Updates both UIs to present the auto-update option ungrouped at the top of the dropdown, and to omit the installed version when the site is pinned.
• Clarifies the CLI --wp help text to explain "latest" as enabling auto-updates (vs pinning a specific version), and updates/extends tests accordingly.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
packages/common/lib/wordpress-version-labels.ts	Adds shared translated label helper for auto-update option (with optional installed version).
apps/ui/src/components/site-settings-view/index.tsx	Passes installed version to field data only when the site is auto-updating.
apps/ui/src/components/site-overview-view/index.test.tsx	Updates expectations for the new Auto-update labeling and adds pinned-site coverage.
apps/ui/src/components/site-fields/wp-version-control.tsx	Renders the auto-update option ungrouped before optgroups (no “Auto-updating” heading).
apps/ui/src/components/site-fields/index.ts	Uses shared helper for auto-update option labels (including hidden fallback).
apps/ui/src/components/site-fields/index.test.ts	Adds unit tests for auto-update label formatting and grouping behavior.
apps/studio/src/modules/site-settings/tests/edit-site-details.test.tsx	Updates Classic UI tests for new auto-update label behavior.
apps/studio/src/modules/site-settings/edit-site-details.tsx	Passes installedVersion to the selector only for auto-updating sites.
apps/studio/src/modules/add-site/components/create-site-form.tsx	Updates create-site fallback option label to use Auto-update.
apps/studio/src/components/wp-version-selector/index.tsx	Updates selector UI to show Auto-update label and removes “Auto-updating” optgroup.
apps/cli/commands/site/create.ts	Clarifies --wp help text describing "latest" as auto-update mode.
apps/cli/commands/config/set.ts	Clarifies config --wp help text describing "latest" as auto-update mode.
.playwright-mcp/page-2026-08-27T10-42-54-487Z.yml	Adds an empty Playwright MCP artifact file (should not be committed).

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[wpmobilebot]

📊 Performance Test Results

Comparing 4fe0936 vs trunk

app-size

Metric	trunk	4fe0936	Diff	Change
App Size (Mac)	1425.05 MB	1425.05 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	4fe0936	Diff	Change
load	1217 ms	1177 ms	40 ms	⚪ 0.0%

site-startup

Metric	trunk	4fe0936	Diff	Change
siteCreation	7530 ms	7516 ms	14 ms	⚪ 0.0%
siteStartup	2867 ms	3392 ms	+525 ms	🔴 18.3%

---

Results are median values from multiple test runs.

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

[gavande1]

Thanks @gcsecsey for taking a bite at it. I have a concern that this does not fully resolve the issue, because Auto-update is still one entry in a list of version numbers, so it reads as a version rather than a mode. In Site Settings, I would prefer two dropdowns: the first one is Auto-update WordPress, and if the user selects Yes we keep the latest, otherwise we show a second dropdown to pin the version. I would love to see what others think. cc @shaunandrews

[gcsecsey]

Thanks @gcsecsey for taking a bite at it. I have a concern that this does not fully resolve the issue, because Auto-update is still one entry in a list of version numbers, so it reads as a version rather than a mode. In Site Settings, I would prefer two dropdowns: the first one is Auto-update WordPress, and if the user selects Yes we keep the latest, otherwise we show a second dropdown to pin the version. I would love to see what others think. cc @shaunandrews

Thanks @gavande1, that’s a good point that we could separate the controls for selecting a version and the auto-updates. I think splitting the control might not fix the original bug on its own though. The problem is that when you pick “latest”, site creation copies WordPress from a the cache folder that we refresh at most once a day. So a brand new site can still be behind and wp-admin can show the update notice.

Pinning is working fine either way, a pinned version downloads that exact zip.

I'll look into what we need to do to make the “latest” cache refresh before we create a site. I think that way we could ensure that we always show the correct version.

[gavande1]

The problem is that when you pick “latest”, site creation copies WordPress from a the cache folder that we refresh at most once a day. So a brand new site can still be behind and wp-admin can show the update notice.

If that is the case, could we wire the download latest WordPress version into the cache when a new site is created, if the cache does not already have the latest version?

[gcsecsey]

The problem is that when you pick “latest”, site creation copies WordPress from a the cache folder that we refresh at most once a day. So a brand new site can still be behind and wp-admin can show the update notice.

If that is the case, could we wire the download latest WordPress version into the cache when a new site is created, if the cache does not already have the latest version?

Yes, I was thinking about the same thing, and raised #4715 for this, the actual fix will most likely be invalidating the cache at site creation.

I think we can keep this PR open for any UI changes we might want to make, because I still think latest is a bit of a misnomer for auto-updates. I also really liked the separate controls you described @gavande1. @shaunandrews wdyt about something like this?