GBK Plain Permalink Support

[jkmassel]

GutenbergKit's native REST URL builder assumes a path-based site API root, so it can't address a self-hosted WordPress site that uses plain permalinks — where the only REST root is the query form https://site/?rest_route=/.

Summary

• WordPressRESTURL.namespaced (iOS) and RestUrlBuilder.namespaced (Android) build every native REST URL by appending the endpoint to the path (apiRoot.appending(path:) / string concat).
• A plain-permalink site has no path-based REST root: /wp-json/ depends on the rewrite rules that plain permalinks disable, so WordPress advertises ?rest_route=/ as the site's REST root.
• Result: for such a site, every native REST URL is malformed — not just media uploads.
• WP.com sites are unaffected — they're reached through the path-based public-api.wordpress.com/ proxy (SitePreparationView.swift / SitePreparationViewModel.kt set siteApiRoot = https://public-api.wordpress.com/), which abstracts the underlying site's permalinks away.

Root cause

namespaced does apiRoot.appending(path:). Given siteApiRoot = https://site/?rest_route=/:

namespaced(root, "/wp-block-editor/v1/settings") → https://site/wp-block-editor/v1/settings?rest_route=/   → 404
namespaced(root, "/wp/v2/media")                 → https://site/wp/v2/media?rest_route=/                   → 404

The /wp/v2/… lands on the URL path (which doesn't route on a plain-permalink site) with a stray rest_route=/ query, instead of https://site/?rest_route=/wp/v2/media.

Impact

Every endpoint routed through namespaced — in RESTAPIRepository alone: editor settings, active theme, site settings, post types — plus the native media-upload endpoint. namespaced has no rest_route handling and its unit tests (both platforms) cover only path-based roots.

This is pre-existing — the logic was extracted from the prior buildNamespacedURL and carried the assumption forward. It surfaced while reviewing the native media-upload work (#561), whose mediaEndpointURL relies on namespaced.

Proposed fix

Teach namespaced (both platforms) to detect a rest_route query on the root and append the endpoint — and the site namespace — to the rest_route value rather than the URL path:

root = https://site/?rest_route=/
build /wp/v2/media → https://site/?rest_route=/wp/v2/media   ✓

Path-based roots keep today's behavior. Add the query-based-root tests the builders never had. This fixes all native endpoints at once, and the media upload's ?_embed=wp:featuredmedia query then merges correctly for free (there's a latent iOS/Android divergence in mediaEndpointURL's query append — percentEncodedQuery overwrite vs + concat — that's moot until the base is correct).

Open question

Reachability depends on whether the host apps (WordPress-iOS / Jetpack) actually connect to self-hosted plain-permalink sites and hand GutenbergKit a ?rest_route= root. Worth confirming before prioritizing — though a plain-permalink site has nothing else it could hand over.

[dcalhoun]

Implementation notes

Fixed in #573 (stacked on #572, a wordpress-rs bump). Four corrections to the description above:

1. namespaced alone isn't enough. Implemented as proposed, it fixes the RESTAPIRepository endpoints but leaves the editor-assets URLs broken on both platforms — EditorAssetLibrary.swift and both Android EditorAssetsLibrary classes build URLs without going through namespacing. So the fix went one layer down, into the join primitive every path bottoms out in (URL.appending(rawPath:) on iOS, a new String.appendingRestPath on Android). Namespacing transforms the path; query-root handling is a joining concern.

2. The named functions don't exist on trunk. WordPressRESTURL.namespaced / RestUrlBuilder.namespaced come from the unmerged #357; trunk still has buildNamespacedURL/buildNamespacedUrl. Nor is there a native mediaEndpointURL yet — #561 is a future consumer, not a current victim.

3. On iOS the failure was silent, not a 404. Verified against a live plain-permalink site, the old URLs returned 200 with the wrong resource:

GET /wp/v2/settings?rest_route=/   -> 200 {"name":…,"namespaces":[…]}   # REST API index
GET /?rest_route=/wp/v2/settings   -> 200 {"title":…,"date_format":…}   # actual settings

The trailing ?rest_route=/ routes to the API root and the path is ignored, so the editor consumed the wrong payload and failed later at decode time. Android did 404, but only on the two endpoints carrying their own query string.

4. The open question is answered — this is reachable. Both hosts pass the query-form root verbatim for app-password self-hosted sites: EditorConfiguration+Blog.swift:9 (blog.restApiRootURL) and GutenbergKitSettingsBuilder.kt:33 (site.wpApiRestUrl), both from wordpress-rs https://api.w.org/ Link-header discovery.

Found along the way, tracked separately:

• wordpress-rs had the same bug, fixed upstream in 2924e36b (shipped in 0.6.0, already used by WordPress-Android). Both demo apps were pinned to pre-fix builds, blocking the editor entirely — hence build: bump wordpress-rs to 0.6.0 in the demo apps #572.
• WordPress-iOS builds editorAssetsEndpoint itself with appendPathComponent (EditorConfiguration+Blog.swift:63-68) → https://site/wpcom/v2/editor-assets?rest_route=/. GBK can't fix this; the host passes it in pre-built. Needs a host-side PR.
• WordPressOrgRestApi.swift:52 asserts lastPathComponent == "wp-json", which would trip in debug builds for these sites.

The approach matches wordpress-rs and @wordpress/api-fetch, so all three layers now behave identically.