Editor fails to load on Atomic sites when theme-styles capability over-reports availability

[jkmassel]

Summary

The block editor can fail to load on WP.com Atomic sites when the per-site theme-styles capability says "available" but the underlying wp-block-editor/v1/settings endpoint isn't actually reachable from the host GutenbergView uses. The editor stalls partway through initialisation; no recoverable error is surfaced.

Reproducible on automatticwidgets.wpcomstaging.com (WP.com Atomic, Storefront theme, no application password). The editor stalls at progress 81/100 and EditorHTTPClient logs a 404 fetching wp-block-editor/v1/settings from the direct host.

05-20 14:23:48.875 E/EditorHTTPClient: HTTP error fetching 
                                       https://automatticwidgets.wpcomstaging.com/wp-json/wp-block-editor/v1/settings: 404
05-20 14:23:48.877 E/WordPress-EDITOR: Failed to preload editor dependencies
05-20 14:23:48.877 E/WordPress-EDITOR: WPErrorResponse(error=WPError(code=rest_no_route, ...))

(Separately, the back button doesn't dismiss the stalled activity — see #22878.)

Why this happens

EditorSettingsRepository.fetchRouteSupport and GutenbergView's EditorHTTPClient don't talk to the same host for WP.com Atomic sites:

• Detection path: WpApiClientProvider.getWpApiClient(site) returns the WP.com client whenever site.isWPCom || site.isUsingWpComRestApi, so apiRoot() is queried via public-api.wordpress.com. Its route list is what hasRouteForEndpoint("/wp-block-editor/v1/settings", resolver) checks.
• Consumption path: GutenbergView uses the configured siteURL (the direct host) for its block-editor settings fetch, not siteApiRoot.

For Atomic sites without an application password those two hosts diverge. The proxy may advertise routes the direct host doesn't expose (or vice versa), and we end up confidently telling the editor "yes, theme styles is supported" right before the editor tries the direct host and gets a 404.

This is consistent with the project preference of talking directly to the remote site whenever we can — the detection layer just hasn't caught up to that yet.

Scope

The fix needs to live in capability detection (#22812 territory), not in the editor library or this PR's preloader. Specifically EditorSettingsRepository.fetchRouteSupport / WpApiClientProvider.getApiUrlResolver(site) for the WP.com-Atomic-without-app-password shape.

A few directions worth weighing:

1. Detect against the host the editor will use. For WP.com Atomic without an app password, probe apiRoot() against the direct host even though the data path normally routes through the proxy. Requires a way to construct an unauthenticated direct-host WpApiClient, or a one-off OkHttp call to ${siteUrl}/wp-json/?_locale=user.
2. Probe both, intersect. Persist siteSupportsEditorSettings = directHostHasRoute && proxyHasRoute. Conservative — closes the false-positive case but may close false-negatives we'd actually want to honor.
3. Have GBKit consume siteApiRoot for wp-block-editor/v1/settings. Library-side change. Aligns library behaviour with our detection, but the project intent ("direct to the site as much as possible") cuts the other way.

(1) feels closest to the stated intent. (2) is the easiest immediate guard if (1) is too invasive.

Repro

1. Add a WP.com Atomic site that doesn't expose wp-block-editor/v1/settings (a wpcomstaging.com Storefront-themed site works)
2. Open My Site for that site, let the dashboard settle (so the preloader and capability fetch run)
3. Open Site Settings — confirm "Use Theme Styles" is enabled
4. Create a new post

Expected: editor opens, dependencies load.

Actual: editor stalls at ~81/100 progress; logcat shows the 404 above; the preloader logs Failed to preload editor dependencies; the back button doesn't work (#22878).

Related

• Surfaced during testing of Integrate Gutenberg Preloading #22579 (Integrate Gutenberg Preloading).
• Capability detection introduced by Add EditorCapabilityResolver to centralize editor-capability gating #22812.
• The back-button hang on stall is tracked separately in Editor exit hangs indefinitely when GutenbergView never finishes loading #22878.

[dangermattic]

🚫 Please add a type label (e.g. [Type] Enhancement) and a feature label (e.g. Stats) to this issue.