Add resolver-aware has_route_for_endpoint to WpApiDetails#1285
Merged
Add resolver-aware has_route_for_endpoint to WpApiDetails#1285
Conversation
WordPress.com API root responses use different route key formats than
WordPress.org — inserting `sites/{site_id}` after the namespace (e.g.
`/wp-block-editor/v1/sites/mobile.blog/settings` instead of
`/wp-block-editor/v1/settings`). The existing `has_route` method does a
direct key lookup, so it can't match the same canonical endpoint across
both site types.
`has_route_for_endpoint` accepts an `ApiUrlResolver` along with the
namespace and endpoint path, uses the resolver to construct the
site-specific route key, and looks that up in the routes map.
Captures a real API root response from mobiledotblog.wordpress.com and
uses it to verify `has_route_for_endpoint` works with actual WP.com
route key formats (e.g. `/wp-block-editor/v1/sites/{site_id}/settings`).
jkmassel
added a commit
to wordpress-mobile/WordPress-Android
that referenced
this pull request
Apr 15, 2026
Points at Automattic/wordpress-rs#1285 which fixes route discovery on WP.com simple sites so editor-assets and editor-settings routes appear in the API root response. Also adapts StatsDataSourceImpl to the new StatsUtmKeys API (String replaced with List<StatsUtmKey>).
Collaborator
XCFramework BuildThis PR's XCFramework is available for testing. Add to your .package(url: "https://github.com/automattic/wordpress-rs", branch: "pr-build/1285")Built from 0537aa3 |
jkmassel
added a commit
to wordpress-mobile/WordPress-Android
that referenced
this pull request
Apr 16, 2026
Points at Automattic/wordpress-rs#1285 which fixes route discovery on WP.com simple sites so editor-assets and editor-settings routes appear in the API root response. Also adapts StatsDataSourceImpl to the new StatsUtmKeys API (String replaced with List<StatsUtmKey>).
jkmassel
added a commit
to wordpress-mobile/WordPress-Android
that referenced
this pull request
Apr 16, 2026
Points at Automattic/wordpress-rs#1285 which fixes route discovery on WP.com simple sites so editor-assets and editor-settings routes appear in the API root response. Also adapts StatsDataSourceImpl to the new StatsUtmKeys API (String replaced with List<StatsUtmKey>).
jkmassel
added a commit
to wordpress-mobile/WordPress-Android
that referenced
this pull request
Apr 16, 2026
Points at Automattic/wordpress-rs#1285 which fixes route discovery on WP.com simple sites so editor-assets and editor-settings routes appear in the API root response. Also adapts StatsDataSourceImpl to the new StatsUtmKeys API (String replaced with List<StatsUtmKey>).
oguzkocer
approved these changes
Apr 17, 2026
…ver` The previous implementation of `has_route_for_endpoint` resolved a full URL and used `find(&namespace)` on the path to derive the route key. If the API root URL contained the namespace as a substring (e.g. `https://example.com/wp/v2/api/wp-json` with namespace `/wp/v2`), the substring search would match the wrong position and produce a bogus route key. Add a `route_path` method to `ApiUrlResolver` so each implementation constructs the route key directly, with no URL parsing or string searching. `has_route_for_endpoint` now just calls `route_path` and looks the result up in the routes map. Tests: - Add a regression test for the namespace-as-substring edge case. - Add consistency tests that fail if `route_path` and `resolve` ever drift (the route key returned by `route_path` must always be the tail of the URL path returned by `resolve`).
The fixture's value lay almost entirely in the route keys — the args,
descriptions, types, and defaults under each route weren't exercised by
any test (those are validated against test-case-03.json instead).
Replace each route value with a minimal stub `{namespace, methods: [],
endpoints: []}`. All 1,495 real WP.com route keys are preserved, the
top-level metadata is unchanged, and the parsing test still validates
the response shape. Drops the file from 1.85MB → 235KB.
Drops the static WP.com API root fixture and folds the route-shape
assertions into the existing `#[ignore]`d `test_fetching_wpcom_api_root`
integration test, which fetches a fresh response from `mobile.blog`. The
fixture was a 235KB blob that only existed to validate the WP.com route
key shape (`/sites/{site_id}/` insertion), which the live test now
covers without the maintenance overhead.
The previous home was a `#[ignore]`d test in `wp_api_integration_tests` that nothing in CI ever invoked. The `wp_com_e2e` harness already runs nightly via `.buildkite/pipeline.yml`, so add the API root fetch + `has_route_for_endpoint` assertions there as a new `api_root_tests` module — five trials covering the URL match, three known routes (`/wp/v2/posts`, `/wp/v2/media`, `/wp-block-editor/v1/settings`) and a negative case. The harness fetches once during collection and dispatches each assertion as its own trial. The endpoint is public, so this module builds its own unauthenticated `WpApiClient` rather than reusing the bearer-authed `ctx.client`.
oguzkocer
approved these changes
Apr 18, 2026
jkmassel
added a commit
to wordpress-mobile/WordPress-Android
that referenced
this pull request
Apr 22, 2026
Points at Automattic/wordpress-rs#1285 which fixes route discovery on WP.com simple sites so editor-assets and editor-settings routes appear in the API root response. Also adapts StatsDataSourceImpl to the new StatsUtmKeys API (String replaced with List<StatsUtmKey>).
jkmassel
added a commit
to wordpress-mobile/WordPress-Android
that referenced
this pull request
May 4, 2026
* Add site settings for third-party blocks and theme style gating
Add a new "Use Third-Party Blocks" toggle in Site Settings, gated
behind GutenbergKit and editor assets support. Enhance the existing
"Use Theme Styles" toggle with contextual warnings when the site
lacks editor settings support or uses a non-block theme.
Includes SiteSettingsProvider interface for injectable access to
site settings from the local DB, replacing static SiteUtils calls
for block editor default detection.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Address review feedback for third-party blocks toggle
Gate the "Use Third-Party Blocks" toggle behind the remote
gutenberg_kit_plugins feature flag in addition to the existing
GutenbergKit and editor assets checks. Also simplify the summary
string by removing "and styles" per reviewer feedback.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add ThemeRepository and EditorSettingsRepository for capability detection
Add ThemeRepository to fetch the active theme via WP API and determine
if it is a block theme. Add EditorSettingsRepository to discover
editor settings and editor assets route support via manifest/API root
queries. Wire SiteSettingsFragment to use EditorSettingsRepository for
gating theme styles and third-party blocks toggles.
Also adds manifest route fetching methods to WpApiClientProvider for
discovering available REST routes on WP.com and self-hosted sites.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Use WpApiClient apiRoot for route discovery instead of manifest fetching
Remove fetchWpComManifestRoutes and fetchSiteManifestRoutes from
WpApiClientProvider. EditorSettingsRepository now uses the standard
WpApiClient.request { it.apiRoot().get() } for all site types,
which already handles WP.com vs self-hosted URL resolution.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Fetch editor capabilities on My Site resume
Call `EditorSettingsRepository.fetchEditorCapabilitiesForSite` when
the user lands on My Site so the route-discovery and theme-detection
results are available by the time they open Site Settings.
On failure, a snackbar is shown and cached prefs retain their previous
values so settings degrade to disabled rather than crashing.
* Add EditorSettingsRepository tests
12 tests covering pref delegation, route discovery persistence,
theme detection, API errors, transport-level error isolation
(one fetch failing doesn't block the other), and the both-fail
case. Also fix MySiteViewModelTest for new constructor param.
* Update wordpress-rs to PR #1285
Points at Automattic/wordpress-rs#1285 which fixes route discovery
on WP.com simple sites so editor-assets and editor-settings routes
appear in the API root response.
Also adapts StatsDataSourceImpl to the new StatsUtmKeys API (String
replaced with List<StatsUtmKey>).
* Use hasRouteForEndpoint for WP.com route discovery
Switch from hasRoute (exact path match) to hasRouteForEndpoint
(namespace + endpoint) so that WP.com sites — whose route keys
include a sites/{site_id} prefix — are correctly detected.
Requires wordpress-rs PR #1285 which adds hasRouteForEndpoint
to WpApiDetails and the ApiUrlResolver parameter.
* Refresh editor capabilities on pull-to-refresh
Call fetchEditorCapabilitiesForSite during pull-to-refresh so
editor settings prefs stay current without requiring a full
screen resume. Show snackbar on failure in both paths.
* Update wordpress-rs to alpha-2026-04-20
* Merge duplicate KDoc on fetchEditorCapabilitiesForSite
Two consecutive KDoc blocks had been left above the function when its
return type changed from Unit to Boolean. Only the second was attached;
fold the return contract into the existing KDoc as @return.
* Don't eject from Site Settings on fetch failure
A failed remote fetch in onFetchError was calling getActivity().finish(),
kicking the user out of the screen. Cached settings are already loaded
earlier via mSiteSettings.init(false), so the screen remains usable —
just show the toast and stay put.
* Use isWPComSimpleSite() in SiteSettingsProviderImpl
site.isWPCom && !site.isWPComAtomic is exactly what
SiteModel#isWPComSimpleSite() returns. Use the named predicate so the
Simple-site definition stays in one place.
* Simplify fetchEditorCapabilitiesForSite with awaitAll
Replace supervisorScope + var bookkeeping with awaitAll over two
async blocks. Both helpers shield non-cancellation exceptions
themselves, so coroutineScope semantics (sibling-cancel-on-failure)
are equivalent here — no behavior change.
* Consolidate theme-fetch debug log fragments
The five-fragment split was harder to read than the underlying
sentence. Group the static prefix and put each labelled variable on
its own line.
* Tighten not-block-theme summary copy
The previous string was wordy and partially redundant with the summary
it gets concatenated with. Trim to three short sentences. Avoid "look
off" — it would clash with the toggle's off state.
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
WordPress.com API root responses use different route key formats than WordPress.org — the
sites/{site_id}segment is inserted after the namespace (e.g./wp-block-editor/v1/sites/mobile.blog/settingsinstead of/wp-block-editor/v1/settings). The existinghas_routedoes a direct key lookup, so it can't match the same canonical endpoint across both site types.Changes
has_route_for_endpointmethod toWpApiDetailsthat accepts anApiUrlResolver, namespace, and endpoint path/wp-json) by locating the namespace in the resolved URL path, then looks up the result in the routes mapTest plan
cargo test -p wp_api --lib— all 1357 tests passcargo clippy— no warningscargo fmt— no formatting issues