Skip to content

fix: resolve the REST index locally on namespaced sites - #617

Draft
dcalhoun wants to merge 1 commit into
trunkfrom
fix/skip-rest-index-on-namespaced-sites
Draft

fix: resolve the REST index locally on namespaced sites#617
dcalhoun wants to merge 1 commit into
trunkfrom
fix/skip-rest-index-on-namespaced-sites

Conversation

@dcalhoun

@dcalhoun dcalhoun commented Sep 2, 2026

Copy link
Copy Markdown
Member

What?

Resolve Gutenberg's REST API index request locally on namespaced sites instead of sending it to the API host's root.

Stacked atop #614; merge that first.

Why?

The editor fails a request on every launch for a namespaced site. Gutenberg's root/__unstableBase entity fetches the REST API index (/?_fields=...) during initialization. That path has no segments for apiPathModifierMiddleware to insert the namespace into, so the request targets the bare API host root, which serves no index. Over HTTP origins (the Vite dev server, Android) it fails CORS preflight; from file:// on iOS it follows a redirect to a docs page and fails JSON parsing.

The only unconditional consumer, useBlockEditorSettings, reads image sizes for client-side media processing, which GutenbergKit does not enable. The Site Title, Tagline, and Logo blocks read the site entity when the user can edit settings and only fall back to this record otherwise. No namespaced route serves the index, so there is nothing to redirect to.

How?

Add siteIndexMiddleware to configureApiFetch. For GET requests to / on a site with a configured API namespace, it resolves with home and url from the host's siteURL rather than calling next. Every other request passes through unchanged. It runs after the preloading middleware so a host-supplied index entry still takes precedence.

Testing Instructions

Tip

Use the bundled build rather than the Vite dev server for step 4. Some hosts answer the index request from a dev-server origin with a 429 that carries no CORS headers, which the browser reports as a CORS failure unrelated to this change.

  1. Run make build and launch the demo app against a namespaced site (e.g., WordPress.com Simple).
  2. Open Web Inspector's Network tab, filtered to XHR/Fetch.
  3. Confirm no request to the API host root (/?_fields=...) appears and the editor loads normally.
  4. Repeat against a self-hosted site and confirm the index request still goes to <siteApiRoot>/?_fields=... and succeeds.
  5. npm run test:unit -- src/utils/api-fetch.test.js

Example root /?_fields=... request:

image

Accessibility Testing Instructions

No UI changes.

🤖 Generated with Claude Code

https://claude.ai/code/session_017jPW5y3FrRywuHHn3gAHgu

@github-actions github-actions Bot added the [Type] Bug An existing feature does not function as intended label Sep 2, 2026
@wpmobilebot

wpmobilebot commented Sep 2, 2026

Copy link
Copy Markdown

XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/617")

Built from ef26163

Base automatically changed from fix/expose-wp-theme-global to trunk September 2, 2026 16:11
Gutenberg's `root`/`__unstableBase` entity requests the REST API index
(`/`) during editor initialization. On namespaced sites the path has no
segments for the namespace middleware to rewrite, so the request targets
the API host's root, which serves no index and fails. Resolve the entity
locally with the site URL the host already provides. The remaining
fields are either unavailable on namespaced sites or read from the
`site` entity by the blocks that use them.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017jPW5y3FrRywuHHn3gAHgu
@dcalhoun
dcalhoun force-pushed the fix/skip-rest-index-on-namespaced-sites branch from a1725eb to ef26163 Compare September 2, 2026 16:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Type] Bug An existing feature does not function as intended

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants